Re: choosing principal names

On Oct 5, 2011, at 4:10 PM, Nico Williams wrote:

>> Should (does?) Kerberos support functionality which is not defined for GSSAPI?  (Level of Assurance is required sometimes and you can't really do it with GSSAPI.  Of course the Kerberos solutions are ugly, proprietary, and maybe both.)
> 
> Perhaps the only thing in Kerberos which the GSS-API did not -but
> should have- exposed is the notion of "realm".  With naming extensions
> we'll be able to get at this in a truly mechanism-agnostic way, but
> for now apps that need to can just inspect the principal name (since
> they'll get the raw form) even though doing so makes them less
> mechanism-agnostic.
> 
> As for cryptographic algorithm suite policies... the GSS-API is badly
> broken in this respect :(  I've written about this many times on
> KITTEN WG's list.

I chose LoA for my example because in the US Gov't space it implies a lot of things besides "use AES".  The level implies things about how the user's identity was verified before being entered into the system, for example.  The level also implies required cryptographic properties, like maybe "nonrepudiation".  Passwords (even ones that aren't sent over the wire) are prohibited at the higher levels.

Using GSSAPI puts you at one more remove from the control you may need to enforce a genuinely, cryptographically rigorous LoA.  The NIST documents are written assuming that PKI is the only way to gain the higher levels, but that's mainly because the authors don't seem to know about the PKINIT, FAST, and OTP protocol extensions.

Of course exercising that control may require a completely separate realm for each LoA in which case you're better off using GSSAPI.  ;-)

Excuse the topic drift.  I'm just indulging in a fun thought experiment.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email protected], or [email protected]