Two scenarios: * Kerberos is already deployed, which implies that any all principals can communicate securely with each other. Through a Kerberized Certificate Authority, a user can obtain short-lived certs. It could also obtain all the trust root info from another kerberized service, including all the root CAs that can be trusted outside of that domain (not implemented yet...). No need for any pre-configured public key on the clients, and no need for dsig. (kx509/KCA; http://www.citi.umich.edu/projects/kerb_pki/)
* Use TLS with a pre-shared secret and key-exchange authentication protocol, which doesn't require any server cert or pre-configured public key for the mutually-authenticated trust establishment. Use this primary authN mechanism to front-end an online-CA and trust-root provisioning service, and again no need for any pre-configured public key, and no need for dsig. http://www.rfc-zone.org/rfc4279.html (or the SRP/AuthA equivalent) Myproxy is a good example of a credential issuing service that can work as an online-CA, has a pluggable primary authentication (no pre-shared secret support yet...), and transparent provisioning capabilities. (http://grid.ncsa.uiuc.edu/myproxy/) Another example is caBIG's Grid Trust Service (GTS), which is such a trust-root provisioning service that relies on a pre-configured public-key/x509cert (but we plan/dream to enhance it in the future to support other bootstrapping mechanisms) (http://www.cagrid.org/mwiki/index.php?title=GTS:Main) In all cases, we would like to standardize the trust root provisioning protocol without having to mandate any boots-trapping public key. Just having the message exchange protocol with standardized formats for the trust-anchor info including meta-data for the anchor's issuing constraints would be great. The security mechanism to use relies on the pre-configured shared-secrets/OTP/Kerberos/password/public-key, and should not be mandated IMHO. Hope that explains. -Frank. Santosh Chokhani wrote: > Frank, > > In your scenario, it seems you do not need trust anchor albeit it is not > clear how communication to online CA is secured and how trust is > extended beyond on-line CA. > > You say, "In those cases, there already are ways to establish a secure > authenticated communication context with a trust-anchor provisioning > service". What is this trust-anchor provisioning service; what is trust > anchor contents in your context; Is the trust anchor local, enterprise > wide or covers multiple enterprises; and how do you (I assume meaning > client or relying parties) establish secure authenticated communication > with the trust-anchor provisioning service. > > -----Original Message----- > From: Frank Siebenlist [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 21, 2007 11:12 AM > To: Santosh Chokhani > Cc: ietf-trust-anchor@vpnc.org > Subject: Re: Draft Charter > > In our deployments, we see more and more that PKI is not the primary > authentication mechanism and that online-CAs are used to obtain > pk-credentials, which means that this pki-trust is derived from other > already pre-configured primary authentication mechanisms, like shared > secrets, username/password, kerberos, OTP, etc. > > In those cases, there already are ways to establish a secure > authenticated communication context with a trust-anchor provisioning > service, and the requirement to use only public key and dsig is not very > "helpful" in those scenarios. > > -FS. > > > Santosh Chokhani wrote: >> Frank, >> >> I agree with Steve. I will be willing to expand the notion a bit. > But, >> in my thinking this deals with cryptographic protocols. These > protocols >> require a public or secret key to establish the trust for > authentication >> and integrity checks. Thus, it must be a key. As it so happens, we >> have been dealing with PKI related matters and hence the starting key >> for authentication and integrity is a public key. >> >> In short, any idea for trust anchor that does not deal with a crypto > key >> is a loser from crypto viewpoint. >> >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Frank >> Siebenlist >> Sent: Tuesday, August 21, 2007 1:40 AM >> To: Paul Hoffman >> Cc: Stephen Kent; Carl Wallace; ietf-trust-anchor@vpnc.org >> Subject: Re: Draft Charter >> >> >> Too bad as in general the overall policy enforcement requires other >> "trust anchors", "roots of trust", "assertion authorities", to be >> pre-configured, like attribute- and authorization authorities. >> >> Furthermore, it also would disallow the use of other authentication > and >> key exchange mechanism to bootstrap from, like >> secure-password/shared-secret protocols with online CAs, in which case >> there would be no need for any trust-anchor's public key and no > digital >> signature. >> >> Just to support x509/pkix style identity certs based on only public > keys >> and only dsigs makes it just as "useful" as x509/pkix... maybe this >> trust-anchor protocol shouldn't deserve its own wg and should instead > be >> used to "revive" pkix as it clearly deals with a deficiency not >> addressed in pkix's gazillion rfcs ;-) >> >> -FS. >> >> >> >> Paul Hoffman wrote: >>> At 9:26 PM -0400 8/20/07, Stephen Kent wrote: >>>> The notion of trust anchors has been, for the last 15 years or so, a >>>> purely public key notion. So yes, I would argue that if we want to >>>> work on what it going to be called a trust anchor management >> protocol, >>>> it needs to be based on public keys and signature validation. If >>>> folks want to do something else, make up a new name, this one is >> taken >>>> :-). >>> I agree with Steve. Everyone involved so far has been talking about >>> public keys, which if nothing else shows that this is the common >> theme. >>> --Paul Hoffman, Director >>> --VPN Consortium >>> > -- Frank Siebenlist [EMAIL PROTECTED] The Globus Alliance - Argonne National Laboratory
