RE: Draft Charter

[Black_David@xxxxxxx]

Frank,

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

There may be some confusion about who/what is being authenticated/
authorized.  The point of the Trust Store Anchor (TSA) is to authorize
the Trust Anchor Administrator (TAA) to manage the local store of trust
anchors.  Note that the local client/user does not need to be
authenticated as part of authorizing this management - the local
authentication is only needed to bootstrap the trust store authorization
mechanism.  Once the authorization is in place, only the TAA's identity
has to be verified in order to determine whether to permit or deny trust
anchor management operations.

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

I disagree with both "less efficient" and "less secure".  If the client
(holder of the password, OTP, etc.) has to be authenticated as part of
every trust anchor management action performed by the TAA, I would
agree with you.  That's not the situation here - the installation
of the TAA's public key as a TSA is an enrollment-like scenario - it
only needs to be done once, after which it is not necessary to
re-authenticate the client.

There are two important consequences:
(1) Once the TAA's public key is installed, a secure channel to the TAA
	is no longer needed to perform trust anchor management - the TAA
	can sign the ops and not have to worry about how they're
delivered.
	This may be an efficiency gain (one digital signature vs. all
the
	work in setting up and using a secure channel).  It may also be
a
	security gain, as the TAA can have its signing key offline with
	respect to the trust anchor management operations - in contrast,
	whatever is used to authenticate a secure channel has to be
online
	with respect to setup of that channel.
(2) Loss of the client's authentication credentials does not expose the
	trust store as long as no TSA change has been made using the
	compromised credentials.  In particular, if the client has no
	ability to change TSAs (makes sense in an enterprise scenario),
	then the trust store depends only on the TAA's private key,
which
	was not lost when the client lost her authentication
credentials,
	and that's probably a security gain.
For Kerberos, I see no problem in using a principal, because I expect
the client to always have that infrastructure set up for other reasons,
and because Kerberos isolates the password (vs. having to use it every
time for everything).

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

If I take that argument to its logical conclusion, there's no point in
using TSAs at all, as the local trust store is at the client's mercy,
but there are scenarios in which that is definitely *not* the case.
The definition of trust anchor management operations (unsigned) might
be useful in the absence of TSAs, but also see the above discussion of
one-time installation of a public key as a TSA vs. relying on client
authentication every time.

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