[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Draft Charter
> 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.
If this is primarily about bootstrapping, it concerns only the
TSAs (Trust Store Anchors), and it looks like Frank would like
it to be possible for them to be something other than public
keys, while the actual application trust anchors provisioned
into the trust stores would be public keys.
In all the scenarios
Frank outlines, the trust anchor management has to be online -
the trust anchor operations have to come down the secure channel
that was authenticated by non-PKI means (i.e., store and forward
via something like a USB key is a non-starter - digital signatures
are needed for that sort of scenario). With this restriction, I
could envision a TSA being a Kerberos realm and principal.
OTOH, I'm not enthusiastic about pre-shared secret (e.g., for
TLS) and pluggable authentication because the notion of identity
of the TSA is unclear. I think requiring the TAA to have a
public/private key pair is reasonable, and then the bootstrapping
mechanism for these cases would be:
1) Set up a secure channel authenticated by some means
(sneaker-net if necessary).
2) Get the TAA's public key and install that as the TSA.
Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
black_david@xxxxxxx Mobile: +1 (978) 394-7754
----------------------------------------------------
> -----Original Message-----
> From: owner-ietf-trust-anchor@xxxxxxxxxxxxx
> [mailto:owner-ietf-trust-anchor@xxxxxxxxxxxxx] On Behalf Of
> Frank Siebenlist
> Sent: Tuesday, August 21, 2007 6:25 PM
> To: Santosh Chokhani
> Cc: ietf-trust-anchor@xxxxxxxx
> Subject: Re: Draft Charter
>
>
> 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:franks@xxxxxxxxxxx]
> > Sent: Tuesday, August 21, 2007 11:12 AM
> > To: Santosh Chokhani
> > Cc: ietf-trust-anchor@xxxxxxxx
> > 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: owner-ietf-trust-anchor@xxxxxxxxxxxxx
> >> [mailto:owner-ietf-trust-anchor@xxxxxxxxxxxxx] On Behalf Of Frank
> >> Siebenlist
> >> Sent: Tuesday, August 21, 2007 1:40 AM
> >> To: Paul Hoffman
> >> Cc: Stephen Kent; Carl Wallace; ietf-trust-anchor@xxxxxxxx
> >> 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 franks@xxxxxxxxxxx
> The Globus Alliance - Argonne National Laboratory
>
>
>