Subject: [Ietf-krb-wg] comments on draft-ietf-krb-wg-anon-05.txt

From: Paul Leach <[email-masked]>
Date: Mon, 3 Mar 2008 15:28:48 -0800

So, even though I'm a co-author, I've haven't been following this draft for a while; I apologize. I have some comments.

1. It seems very unfortunate that the client's realm is always exposed to the server (in the transited realm field). This makes a being truly completely anonymous to the server difficult unless the initiator randomly chooses a realm and uses the anonymous AS_REQ feature. Why must the anonymous realm not be used in transited realm field?

Also, the fact that the client's realm is always exposed should probably be noted in the security considerations.

2. Given 1, why is policy needed on the KDC to decide whether the crealm in a service ticket is the anonymous realm or the realm of the KDC? It seems pretty pointless.

3. In fact, why is it necessary to have three ways to specify the crealm in an anonymous ticket? This then costs an extra (rather obtuse) paragraph to say that both instances of the cname/crealm in certain messages must be of the same form.

3. It appears that there are many different usage modes for the anonymous request.
a. Client discloses its identity to the KDC, but not the server
b. Client discloses its identity to neither the KDC nor the server
c,d. Either of the above, with use of client realm as crealm in the ticket

There isn't much motivation of the need all these forms. Reading the abstract, their existence isn't even hinted at; one has to deduce that this was the intent of the specification (and I may have deduced incorrectly). Can a compliant implementation support just the first one? (It is much simpler to implement.) Being explicit about the modes, and separating section 4 into two sub-sections, one for processing anonymous AS_REQs and one for processing TGS_REQs that specify the anonymous flag in KDCOptions would help.

If the policy option mentioned in #2 above,

4. In section 2, paragraph 2, I suggest changing
        "if the client wishes to authenticate the KDC anonymously"
To
        "If the client does not wish to disclose its identity to the KDC, yet still authenticate the KDC"

5. Why is it interesting to want to remove AD-INITIAL-VERIFIED-CAS from an anonymous ticket? It would be good to include such motivation.

6. (Re: section 5.) If an anonymous TGT was obtained, should the client Kerberos library always set the anonymous flag in the KDC options of a TGS request, even if the client application does not assert the anonymous flag when calling GSS_Init_Sec_Context? The client application may not even be aware that its TGT is anonymous.

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