[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Draft Charter



Your "translation" sounds good ;-)

I just don't understand your concern about tls with pre-shared secret -
kerberos' security would be enhanced when it would deploy that for it's
password-based authN+keyexchange - it seems to me like a better authN
protocol to use for any password/OTP-based mechanism...


Your solution:

> 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.

is less efficient and less secure (one more unnecessary chain) than
simply using the already established security context to provision the
client...

-Frank.

PS. Note that any of these online-PKIs which is derived/bootstrapped
from another primary authN mechanism is less "trusted/secure" than that
primary authN mechanism - it's up to the  organization's policy whether
that is "secure enough" for their deployment (...and in most cases it is).



Black_David@xxxxxxx wrote:
>> 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
>>
>>
>>
> 

-- 
Frank Siebenlist               franks@xxxxxxxxxxx
The Globus Alliance - Argonne National Laboratory