GSS-API and libkrb5 behavior for Anonymous tickets

[Nicolas Williams]

On Tue, Nov 03, 2009 at 12:37:47PM -0500, Sam Hartman wrote:
> >>>>> "Greg" == Greg Hudson <ghudson at MIT.EDU> writes:
>     Greg> Finally: it's my understanding (though I haven't read the
>     Greg> anonymous pkinit spec) that it is valid to do anonymous
>     Greg> pkinit to a realm you can't verify the certificate of, and
>     Greg> that this may be valuable in obtaining a FAST armor
>     Greg> ticket--with the proviso that your armor is then vulnerable
>     Greg> to a man-in-the-middle attack.  It sounds like your
>     Greg> implementation is not going to allow that case at first, but
>     Greg> the interface should keep that case in mind as a future
>     Greg> possibility.
> 
> I agree the libkrb5 interface should keep that in mind.  I'm not sure
> this matches the GSS-API model well enough to support there.
> 
> In particular, take a look at the requirements in
> draft-ietf-krb-wg-anon-10 for the anonymous KDC case.  The text seems
> to place a fairly strong requirement that you verify the KDC before
> using the ticket.  So, I'm not sure it would be permitted to use it in
> a normal ap exchange.  If we ignore that, then it would perhaps be
> permissible to use such a ticket in gss-api with the mutual
> authentication flag cleared, although you would get very different
> security guarantees than you typically do with Kerberos especially if
> you use per-message protection.  I'm not sure if that's OK or not.

The GSS-API very explicitly contemplates, and allows, for security
contexts with anonymous initiator and acceptor names.

Clearly such security contexts are, practiclaly by definition, subject
to MITM attacks.  But the API allows them.  One supposes that by using
extended naming APIs one could extract a realm's KDC's certificate and
then use that for SSH-style leap-of-faith authentication.  But mostly I
think this is useless.

I'm happy to have the mechanism support this, or not.  The only good
reason to not support it is that it would be wasting your time on a
useless feature (I don't see the draft-ietf-krb-wg-anon-10 requirement
as applicable to the GSS-API mechanism -- it shouldn't be, in any case).
And I see no good reasons to support it other than completeness.

(Maybe some day we'll have a reasonable use case fo SSH-style leap-of-
faith as described above.  Someone can implement this then.)

Nico
--