[OpenAFS-devel] openafs - proposed cache security improvement

[Marcus Watts]

Jeffrey Altman <jaltman@columbia.edu> writes:
> Marcus Watts wrote:
> > Jeffrey Hutzelman <jhutz@cmu.edu> writes:
> >>> Incidentally, the particular problem Marcus posits here is one we
> >>> considered, and for which rxgk has an obvious solution in the form of its
> >>> combine-tokens operation.  I do not think it would be appropriate at this
> >>> point in time to attempt to add this functionality to rxkad.
> >> Oh, BTW, this approach lends itself quite easily to situations in which the 
> >> individual client hosts do not have keys, by giving the server a public key 
> >> and authenticating rxgk token establishment with PKU2U instead of GSS-krb5.
> > 
> > Is this
> > 	draft-zhu-pku2u-01.txt ?
> > 
> > If so, besides the obvious problems, this seems to depend on
> > x509 certificates on both sides.  So far, nobody else here has
> > sounded at all enthusiastic about x509 certificates for either side.
> > 
> > 				-Marcus Watts
> 
> PKU2U uses Krb5 PK-INIT and PK-INIT does not require the use of X.509
> certificates; it can also support raw public/private key pairs.
> 
> Jeffrey Altman

RFC 4556 and draft-zhu-pku2u-01.txt don't talk about RSA keys that
aren't associated with names.  RFC 4556 gives 2 cases; either the RSA
key is bound with a kerberos 5 principal (presumably stored in its
principal database), or the name is contained in the certificate itself
[on page 16].  draft-zhu-pku2u-01.txt makes a fairly big point about
validating names and doesn't talk about use with plain RSA keys at
all.  It uses the word MUST a lot in connection with this.
Note that for the purpose we're talking about here, securing
AFS cache access, the cache manager's identify isn't useful, so
a good part of the purpose people intend for kerberos isn't relevant.

As best I can tell, RFC 4556 doesn't actually define the use of
straight RSA keys.  It does talk about the use of "other certificates",
but explicitly does not specify how they work.  Which additional rfc's
or other standards actually define this?

RFC 4556 appears to be new, and it references one set of
implementations which it admits do not completely match the standard.
So far as I know, that implementation is not open source and is not
likely to become so.  There appear to be several other implementations
that will be certain (or likely) to be opensource that are in the
process of happening.  Looks like citi has one for MIT which I gather
isn't part of a release yet.
	http://www.citi.umich.edu/projects/pkinit/
Citi's implementation is supposed to be using pkcs#11 to talk to a
smartcard, which means you are invested in PKI if you use this.  So
when you envision that this will be generally and dependably available
especially on linux?  How likely do you think it is that support for
raw public/private key pairs will be present?

					-Marcus Watts