Subject: [Ietf-krb-wg] Last Call Comments: draft-ietf-krb-wg-anon-05

From: Ken Raeburn <[email-masked]>
Date: Mon, 7 Apr 2008 19:00:17 -0400

As Sam indicated, we've been looking at the possibility of  
implementing part of draft-ietf-krb-wg-anon-05.txt, and a couple  
issues have come up relating to GSS-API.

First, the GSS-API concept of anonymous session establishment seems to  
be that the client isn't authenticated at all.  In the WELLKNOWN/ 
ANONYMOUS@SOME-REALM case, *if* anonymous AS requests can only use WK/ 
A@WELLKNOWN:ANONYMOUS as the client name (see Sam's email), then we're  
giving the server information about the identity of the client.  Maybe  
not the client's full identity, but at least the realm name.  Should  
it be treated as anonymous authentication at the GSS-API layer  
(GSS_C_ANON_FLAG, NT-ANONYMOUS), or not?  The text in krb-wg-anon does  
imply that realm names may be included in NT-ANONYMOUS names, when  
discussing the exported name format, but does this match the GSS-API  
concept of anonymous security context establishment?

Should importing an anonymous Kerberos principal name and calling  
display_name get NT-ANONYMOUS back as the type, or should NT-ANONYMOUS  
names only be generated by accept_sec_context?

The next question revolves around gss_display_name, though it's not  
really specific to this draft, or the Kerberos mechanism in  
particular.  In RFC 2744 (C Bindings), section 4.4, says that the  
display-name form of anonymous names must be "syntactically  
distinguishable from any valid principal name supported by the  
implementation"; it specifically doesn't say it has to be  
distinguishable only from other names returned by the mechanism in  
use.  In a mechglue type environment, where mechanisms may be  
dynamically loaded at run time and provided by a third party, without  
tight coordination, this gets tricky unless you use some kind of  
quoting or prefix scheme; any fixed string potentially could be used  
for a real, non-anonymous identity by some mechanism that surfaces  
next week.  So if I pick "<anonymous>" for WK/A@WK:A, and  
"<anonymous>@REALM" for WK/A@REALM, and some other mech allows  
"<anonymous>" to be picked as the name of an actual registered  
identity, I need to distinguish them somehow.

If the anonymous name can carry information (like the initial Kerberos  
realm), it would be logical to preserve that information on the  
acceptor side.  So I assume for WK/A@REALM it would be desirable to  
have the display_name output include REALM.  Which implies that in a  
mechglue-style implementation (a generic GSS-API library that can  
dynamically load arbitrary mechanisms provided by other parties, all  
implementing GSS-API themselves), the mechglue layer should call the  
mechanism-specific display_name function and incorporate the result.

Together, these imply that the result of display_name on an anonymous  
name may include both a mechanism-generated string, syntactically  
distinguishable from anything the mechanism can output for non- 
anonymous names, and something added by mechglue to make it  
syntactically distinguishable from anything that could be returned  
through the mechglue layer for non-anonymous names.  That could get  
messy fast.

The question: Are we really expected to meet this specification as  
written, or is it asking for too much?  (Do other implementations that  
support anonymous sessions do it?)  Note that this requirement does  
*not* appear on RFC 2743, the GSS-API v2u1 spec, only in the C and  
Java bindings; is it really the place of the language bindings to  
specify such things?

Oh, yeah: One little nit in the anon-05 draft: In the first paragraph  
of section 3, "WELLKNOWN:ANONYMOUS" has a line break after the colon.   
I assume it was intended to not have any whitespace inserted there,  
but from the .txt file as distributed it's slightly ambiguous.

Ken
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Martin Rex <[email-masked]>
Date: Tue, 8 Apr 2008 17:57:27 +0200 (MEST)

Sorry for this long message ...

> issues have come up relating to GSS-API.

I'm not aware of an installed base of gssapi mechanism that implements
support for anonymity (at the gssapi level), and certainly not back
then, when the gssapi v2 specs were finalized.  Whatever is there in
the spec is more logical guessing than implementation-backed experience.

The problems you're facing are not unusal for something that was
designed in theory but not actually implemented.

If we had continued with GSS-API v2 on the standards track
(i.e. draft standard), we probably would have had to strip features
for which independent interoperable implementations weren't
demonstrated or things that had not been implemented at all.
IMHO that would have included anonymity support...

I think it would be best if those that are trying to really implement
support anonymity would come up with and discuss a sensible an consistent
proposal for how to do it, and then to adjust/update the anonymity
support in GSS-API v2.

The anonymity support in GSS-API should provide a clear guidance
for portable applications how to reliably request this by the initiator
and guidance how to detect it and not confuse it with regular
authentication on the acceptor side.

The situation may be less clear in user<->user or peer<->peer scenarios,
something which Kerberos >gssapi< is notoriously bad at (because of
the traditional implication that a target_name must be provided
to gss_init_sec_context and the assumption that this name can be
and will be derived/composed from the network endpoint address of
the acceptor.  In that respect DCE was much cleaner, in that
it implied a service directory where to look up two very distinct
pieces of information:  the network location where a service can
be reached and the security identity as which it will authenticate.

(btw. in GSS-API v2, the (unconditional) requirement for passing
a target_name to gss_init_sec_context() was replaced with a caveat
that some gssapi mechanisms are designed in a way that they
desperately need a target_name and fail without.

Issues that should be solved (or at least be sufficiently addressed)
with anonymity support in GSS-API--something that the current wording
tries, but not necessarily achieves:

  - provide a clear guidance for portable applications (initiator)
    to request and use anonymity for gssapi protected communication

  - provide a clear guidance for porable applications (acceptor)
    to recognize anonymous authentication so that it is not confused
    with existing identity-revealing authentication

The original idea was that anonymity is a simple context attribute
which the initiator may assert when calling gss_init_sec_context().
(GSS-API v2 does not allow the acceptor to assert any context flags).

Thinking about it, it was realized that providing anonymity with
an identity-based (explicit) credential passed to gss_init_sec_context()
might not be possible, so the concept of an anonymous credential
was introduced.

The concept of anonymity itself is still quite vage: what is anonymity?
Are there several different levels of anonymity, and at what level
do we stop calling it anonymity?

IMHO, anonymity is the concept of "blending within a group", and the
different levels of anonymity determine how large that group really is.
If there is no "blending", because each individual in the group
repeatedly appears with the same distinct tag, then this is *NOT*
anonymity, it is at best pseudonymity.  If implemented correctly,
anonymity will reliably preclude accountablilty below the group level --
if it doesn't provide that, it doesn't provide anonymity.

Is there a serious problem with not providing accountability?
Personally, I don't think so.  SSL/TLS without SSL-client certs
has been in use for over 10 years and the world hasn't come to
an end.  The fact that the SSL/TLS protocol provides anonymity
(at least if you disable session caching on your client) doesn't
mean that *EVERYTHING* that is protected SSL/TLS without client certs
is suddenly and entirely anonymous.  SSL/TLS is primarily used to 
provide an encrypted and integrity protected communication channel,
and the vast majority of communication inside is quite revealing
about the communicating entities--in particular in HTTP/HTML
scenarios with cookies, HTTP-Referers, app-level authentication, etc.

One means to narrow down a group might be a Kerberos Realm.
Anonymity is lost if all principals in a realm belong to one
single user, but other than that, it looks like a group to me.
A unique tag for every principal, no matter how secret
the mapping between real-world individuals and unique tags is,
precludes anonymity.  It doesn't matter how esoteric the procedure
is to reveal the original identity, the point is that it is possible
at all--and in reality, determining the identity is usually MUCH
easier as the official disclosing procedure suggests.

The most common pitfall of allegedly secret pseudonymity is that
the unique tags are used for more than one authentication.
Almost as bad as re-using a random pad for XOR-encryption.
It's amazing how quickly the designed pseudonymity disclosure scheme
can be bypassed by aggregating information.  An anonymous
authentication scheme that uses credentials more than once
in a recipient-recognizable fashion is fatally flawed.
(Similar to an Office suite that sticks the
same unique GUID (or worse, names of editors) in every
document it creates...).

Which different "levels of anonymity" can Kerberos provide
(is there more than one?)  Certainly it would be possible to
introduce artificial levels, something like "group-A@realm",
"group-B@realm", etc.  However, gssapi so far does not provide 
means to distinguish different "levels of anonymity".  At the
Kerberos level the initiator should probably steer the behaviour
through conscious selection of an adequeate credential for
each desired "level of anonymity".  The reuse of a (Kerberos)
service ticket for additional authentications is a problem
for anonymity.

For the "server" (recipient of an anonymous authentication)
the anonymous authentication of userA now should be as indistinguishable
from another anonymous authentication of userA in 5 minutes as
from an anonymous authentication of userB now or an anonymous
authentication of userA in two months from now.

Persisting server state on the client across different authentication
also breaks anonymity -- and I expect a lot of applications to get
this completely wrong.  WWW is an environment where anonymity will
work poorly with common server and client configurations.

Support for anonymity might be much harder to add at the protocol
level for certain existing PKI-based gssapi mechanisms.
Conceptually, it could be done like in SSL/TLS: unidirectional
authentication without SSL client cert, i.e. *no* client credential.

When designing support for anonymity for a Kerberos gssapi mechanism,
think about how this (or something very similar) could be implemented
with an SSL/TLS-based gssapi mechanism.  If it works fine for both,
then it might be sufficiently portable for the "generic" spec level.

-Martin