[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on client auth
Brian M. Thomas wrote:
>
> Peter@verisign said:
> > .................................. Common interfaces, modules, formats,
> > etc, but radically different ideas for infrastructure security
> > management, perhaps.
>
> I am a firm believer in using other people's code if it works; more people
> to look at it and find problems before and after implementation makes the
> implementor's and maintainer's jobs easier. That's what I'm looking for.
> If I could get you, or anyone, to demonstrate how this could work, thus
> allowing me to use shared standards of this sort, I would be at least halfway
> toward my goal.
I dont want to bias SPKI in any way other than the community
is happening to be going. SPKI set out to be an anything except
an X.509 community, so Im worried I'll change the culture by adressing
this, as I suspect I'd contradict the mythology. This
is not good, as we need diversity of security models in the Internet.
Im still hopeful, formats can indeed be shared. But lets
abandon this thread for now, and concentrate on simple concepts
v. formats.
X.509 AM (not X.509v3) is indeed overly complex model, and its profiling efforts
are only slowly advancing. The SPKI notions are evidently a
more-tailored system design, and I hope will progress
quickly. How we all standardize the systems formats, controls
and any interfaces, and then how one implements, is another matter!
I know my aim is to reuse the deployed X.509 modules and
protocol infrastructure from the SSL and S-HTTP areas, where we and others
facilitate an infrastructure demonstrating highly-structured
residential-oriented models of fully distributed and orgnizational-based
key management. I want to also facilitate the SDSI/SPKI telephone-system-company
managed models, where users may only control their name-delegation, and the AT&T
and Euro-PTTs uniquely control the authoritative cert infrastructures
(and rights to delegate authority) in a (mysterious) monolithic management
system.
Im very impressed by SDSI/SPKI! I want it to succeed. Dont
get me wrong.
>
> > admins configures in the trust point who s/he accepts as
> > serving the interests of the admin's users, on account
> > of the admin verifying the issuing policy and
> > the controls of the domain which reasonably ensure that
> > all parties/proxies will act in the way speicified despite autonomous
> > actions; some "trusted" control system (enacted in the
> > CPS) will enforce the delegation assumptions with
> > perhaps, but not always, the support of trusted software.
>
> If I read this right, the very act of "configuring in the trust point", and
> the mechanism, is the sticky bit for me. I see this as a use for a certificate.
> Nothing else will suffice. If I(speaking as the application entity) trusted the
> operating system root(and I don't see why I should have to), I could still only
> trust it on the machine I was running on, and my human administrator may not be
> represented on that machine - indeed may not even have access to it as a user.
> Therefore some secure means of getting this administrative directive to me is
> indicated. As I said, a certificate, securely and understandably representing
> some humanly-decided policy, could be that instrument.
It could be. but is not simple. The act is what matters, not the means.
We agree; configuring the trust point is the accountable action;
flexible cert technology may or may not help to audit/control the action, here.
>
> > This is human judgement, and then decision on appropriate
> > "delegation of authority", represented by a choice to shove a trusted
> > key into the key-domain key configuration file, or not. Practical,
> > and realistic, surely. Acountability passes to the human, who
> > delegates authority to decide to the proxy.
>
> Again, the action "shove a trusted key into the key-domain key configuration
> file" requires a mechanism. That mechanism is a certificate, a machine-readable,
> authenticated utterance of an authorizing statement. Merely putting the key
> into a list of trusted keys is insufficiently specific.
Here we disagree. Its the act which is accountable. Yes, the act
needs a very specific control process. This may or may not be mechanized using
technology. This act of establishing an authorized-domain is no more than than
used for over 40 years to install high-security symmetric device
configurations - which had not the flexbility of public-key
technology; however the controls process and result are identical.
Sure, perhaps cert technology for the control process could
be used. But is not necessary, nor simple, IMHO.
The specific authorization
> of what that key can do, and who (what key) so authorized it, must be communicated
> as well. The term "file" is also too imprecise here; its connotation is that
> of an operating-system managed storage location. But operating systems typically
> do not equate key-bearing principals with their authorization entities, or if they
> do, the means of doing that is not specified here. If they can do this, fine,
> but again, my application cannot know certainly that they do, whereas with a
> certificate supporting every assumption of fact or policy, it can. Some of my
> colleagues have characterised a truly wanton implementation of this kind of
> thing as little more than a secure rule base.
So long as the type of the rule, and its semantics are well expressed,
and the storage medium (however stored) protected from authorized modify
I dont care if the rules are mixed together, or in different
list.
Note, particularly, we were concerned in the previous paragraph with
the domain-based authority-delegation procedure. And it is
indeed the case that the act of changing such state, by
applying the controlled process, should be accountable to
only those subjects which have a priori authorization rights to effect that
change. Less abstractedly, only trusted personnel may
alter certain files which control security; there
are levels of required rights for security-relevant configuration
events.
(Such rights may well exploit a (separate) control
authority and keying domaim, and exploit certs as
their implementing technology in a private management
system. Perhaps see BBN/RSADSI Safekeyper for
such a design in practice; perhaps see VeriSign's
CSP for the practices used to proceduralize accoutnable
change in the manner described above, for this device. Note, as it
happens, certs and (physical authorization keys) from a
control-authority (or delegated trusted platform) are used
just as you suggest, along with other disaster-recovery controls!)
>
> > You are making a decision to relyon a cert! This is
> > why CAs have to be so careful, as they are therefore liable!
>
> Correct. *I* made the decision. I must now *securely* communicate that decision
> to my software agent, which is able to carry it out.
Of course. In the BBN box, you shove in your datakey, and arm
the unit. The physical datakey(s) is the security, the authorization
based on the capability of the stored keying material. Only the right datakeys
will arm certain trust point for issuing; one could
exploit exactly the same control for arming "enforcement"
for particular trust domains, only. Perhaps see DoD comsec
procedures and devices here, if you have access.
But its all rather expensive! Designers found it ok for
cert issuing controls, but too expensive for cert validation
systems. NT/Unix system security is used as substitute,
on the whole, for commercial systems.
>
> >
> > This is the entrust model for X.509. It makes no difference whether you or
> > your trusted CA "cerify" the public root. Obviously the more
> > local the trust deicison, the easier it is for you, perhaps.
> > but this is a choice. many residential users desire
> > ADMD organizations of telematic services, versus
> > their managing many PRMD interconnectivity graphs
> > which they cannt really handle. A mix of local choice
> > to configure trust in ADMDs is a nice compromise; nice to
> > see PGP gone down that line; Ive stopped
> > criticising PGP's inane previous-design now! I even
> > stuffed a PGP key in my directory entry; not
> > sure what it means though, yet.
>
> I must confess that, having been in this discipline for less than two full years,
> I am not familiar with the terminology. References to these would be appreciated.
ADMD is X.400 for telephone company style management of
telematic services; big swithches, millions of terminals.
PRMD is X.400 for organizational-based management of telematic services,
which may or may not use telephone companies (or similar) as value-adding intermediaries
switches; peer peer computing and comms, essentially.
Despite the irrelevance of X.400, the orgzniational terms sort
of stick around. In the case of X.500 naming the terms
ADDMD, and PRDMD are similarly defined for naming. In SDSI, one has as
ADDMD model of authoritative domain organization - few massive point entities
control authority and process for all elements in the domain. There can
be flexible naming domains, else paranoid domains. But that
control philosphy is uniformly a function of who is on top,
for all those domain members. Its the "Small number of big-guys" model.
>
> > ACL) allow you to have free drinks; who knows. The barman
> > assumes bouncer, and only checks the number, not
> > the card expiry date, for example.
>
> The barman assumes a perimeter which does not exist on an internet. Some
> people have yet to understand that perimeters (operating system hosts, networks,
> etc.) are no longer relevant, because even where they actually exist they
> cannot be assumed. I don't think that was your problem here; I just picked
> on the example because it was relevant to a continuing problem of awareness.
WE agree. Hallam-Baker tought me that the WEB is about users and resources,
and the Internet is actually irrelvant, just as the internet makes packet-switches
and hosts irrelevant.
So, the idea surely has to be for a simple infrastructure to link
uses, and resource, named as "users" and "resources". Hence
URNs and URIs.
See we are together, conceptually! a URN may have both
public-id, and resource-specific URI rights. I.E. a public
id-cert, and a service-speciifc authoritzation-cert
which is tailored to control whatever is special
about that service.
Simple model! Now to the decision on how to arm
the server, and what the SPKI world needs to
instrument that signature validation process
to achieve human-accountable controls.
>
> > I dont disagree with this underlying true condition; its however a fraction of the security
> > problem; as does not facilitate accountability for those enviornments
> > which demand individual accountability
> > [ etc ]
>
> I, or for tht matter Carl, or Blaze, or just about anybody, have never made
> the assertion that names (and name certs) are not necessary.
I agree SDSI is consistent, and your analysis a valid projection of
that infrastructure onto security enforcement on
real systems concerned with saying yes or no to access
based on authentication and authorization, implicit
or explicit, in some combination.
I really did believe howver that Carl, in his philosophy had
asserted we only need keys, authoirity notions and some minimal
date timers; names are bad, bad, bad, says Carl.
I would tend to agree that Ive heard noone else suggest
the same. But im new on the list...
I will make more
> of that below, but your example of accountability and auditing is one of the
> major reasons that my security organization wouldn't let me get away with it.
> The name certificate stands as one of the main bulwarks of human policymaking
> [BF&L included], which results in the issuance of key-privilege certificates.
> If we can get past this, or every time we mention it, just have some code word
> to stand for all the standard assertions about how we're not arguing over syntax,
code phrase is henceforth "gagme on ASN.1". I anticipate using it with
about 6 IETF grandees about 12 times a year.
...
It was when the issue of authorization came up, and all
> of the work that I have already done to implement it, that it occurred
> to me that it could be much simpler than we had designed it.
And this is why Im still on the list! Its a fine notion to
work on.
>
> Again, I think I'll refrain from quoting, which has some disadvantages, but
> I find it hard to place my comments effectively within the quotes. I think
> that there is still a fundamental misunderstanding here. What you mean, for
> example, by "an autonomous responder seeking to take human-style accountable
> decisions", is not completely clear to me, mostly because in the ensuing
> language I get completely lost. What I would mean by that term, had I used
> it, is a typical server in an ordinary distributed application framework.
> The server's job is, then, to decide whether a particular request should be
> honored. The server is in no way capable of making a judgement, only of
> enacting the judgement which its human administrator has made. That
> predetermined judgement must be securely communicated to the running instance
> of the program; this is the use of a certificate that I suggest.
This is fine. I call this arming the security module, whereby human
delegates to machine decision making ability. What the decision is, and
enacting rules are, is possibly part of the instrument whereby
human arms machine. See control framework, expressed above,
which we use here to arm issuing authorities. It need not be used,
but can be. Perhaps, in simpler designs, the enacted
rules are hard-coded, just awaiting "pure" arming so that
the machine is accouantbly approved to operate. Such a device
is obviously less flexible, but simpler.
We are in 100% agreement on the framework, and the need
for the control authority in arming and facilitating
a human delegating to the machine authority to operate
some control-rule (implcit, explicit) automonously upon
which the entire security depends. And that comes
down to configuring the point(s) of trust
in a safe, trusted and secure manner into the
security module which uses them. Several FIPS 141-1
criteria come in to play here, IMHO.
>
> The mechanism for making the judgement is not discussed here; names and their
> meanings are certainly involved, and name certificates could, and probably must,
> be relied on. That is why, in your export violation above, you *could* prove
> that you had taken due care, because the Syrian national had presented you a name
> certificate, issued by the Commerce Department, certifying that the presented
> key belonged to someone for whom the export restrictions did not apply, and
> upon which basis *you* executed the certificate authorising the release of
> the restricted material, which the program could honor with indemnity.
>
> Enough for now. It's taken me a long time to get this far, and I don't think
> that a lot of the rest was particularly useful to comment on as long as I felt
> that some of my assertions are not yet understood, and besides, I'll never get
> this message posted.
I hope my replay is conformant with your model. this is my goal. I have
now a model, which is self-consistent, which at least attempts
to embrace the control objective that I believe you to be expressing.
>
> I enjoy this discussion, even though it gives me a headache trying to understand
> other people and make them understand me. Moreover, the fact that this is more
> or less in public means that there are lots of people who will hear the debates
> and make up their own minds, and the art is advanced.
I think this is all excellent. We are getting to the
heart of what "simple" requirement we are after.
Carl has a notion that a Simple cert; means a simple
infrastructure, means simple secuiryt model. I think
its the other way around. Ill design a cert profile once
I now what the simple control objective is.
This I do believe we have identified: the simple
notion for SPKI is one in which all security depends upon
a safe mechanism for configuring trust points
at the cert evaluation agent. And we need
a cert-based control authority mechanism to manage
this process so as to provide a priori human accountability
in the process of proxied verification and
validation of trust chains. The cert issued
by the control authority is precislely
a mixed id/aithorization cert.
I dont disagree about this being one essential,
if not asbolute need of, a PKI. It had never occured to me that
the SPKI was based on the need for the Interrnet to automate
this particular process. I have heard Micheal Baum here describe
exactly the same need, from a legalistic perpsective;
but we could only wave our hands in the air as to
means of facilitating the procedure. Now we have something
to work on for the transactional components
of the VeriSign CPS document.
>
> Yours for light and heat,
>
> brian
>
> Brian Thomas - Distributed Systems Architect bt0008@entropy.sbc.com
> Southwestern Bell bthomas@cdmnet.com(or primary.net)
> One Bell Center, Room 23Q1 Tel: 314 235 3141
> St. Louis, MO 63101 Fax: 314 331 2755
References: