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

From: Larry Zhu <[email-masked]>
Date: Wed, 9 Apr 2008 13:19:13 -0700

I am not at all pleased by the fact Paul was confused when reading the draft. Throwing out an excuse that the draft took a long while to get where we are today is not good enough for me.

More specfically, here are the responses:

>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.

Although the understanding is incorrect, I propose to make it clear this is not the case earlier in the draft (instead of deducing it out on page 4 and finding it out in section 4). I would propose the following clarification on page 3.

150c150,152

<    the transited field of a ticket.
---
>    the transited field of a ticket.  However, as specified in Section 4,
>    the true name of the realm that issued the anonymous ticket MAY be
>    present in the transited field of a ticket.

I will skip the comments based on this understanding.

>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.

The comment is somewhat related to the strayed understanding but I would propose the following clarification:

183,184c184,187
<       the realm that issued the initial ticket for the client principal,
<       or the anonymous realm name.
---
>       the realm that issued the initial ticket for the client principal
>       (when the anonymous ticket is obtained using anonymous PKINIT from
>       a Kerberos realm other than that of the client as described in
>       Section 4), or the anonymous realm name.

Or the full text.
   o  The crealm field contains the client's realm name, or the name of
      the realm that issued the initial ticket for the client principal
      (when the anonymous ticket is obtained using anonymous PKINIT from
      a Kerberos realm other than that of the client as described in
      Section 4), or the anonymous realm name.

> 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"

Agreed.

> 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.

How about the following:

---
>    The AD-INITIAL-VERIFIED-CAS authorization data as defined in
>    [RFC4556] contains the issuer name of the client certificate.  If
>    such information about the client identity is not desired to be
>    revealed, the AD-INITIAL-VERIFIED-CAS authorization data MAY be
341,347c353,359
<    The TGS MUST add the name of the previous realm according to Section
<    3.3.3.2 of [RFC4120].  If the client's realm is the anonymous realm,
<    the abbreviation forms that build on the preceding name cannot be
<    used at the start of the transited encoding.  The null-subfield form
<    (e.g., encoding ending with ",") could not be used next to the
<    anonymous realm that can potentially be at the beginning where the
<    client realm is filled in.

> 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.

This is invalid, see the text in section 4 below:

   If the ticket in the PA-TGS-REQ of the TGS request is anonymous, or
   if the client in the AS request is anonymous, the anonymous KDC
   option MUST be set in the request.  Otherwise, the KDC MUST return a
   KRB-ERROR message with the code KDC_ERR_BADOPTION.

Let me know if there is any outstanding issue.

--larry
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Leach
Sent: Monday, March 03, 2008 3:29 PM
To: [email-masked]
Subject: [Ietf-krb-wg] comments on draft-ietf-krb-wg-anon-05.txt

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
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Larry Zhu <[email-masked]>
Date: Wed, 9 Apr 2008 23:54:13 -0700

Larry Zhu wrote:
> Paul Leach wrote:

> Agreed.

Sigh. Actually the suggested change subtly changed the meaning of the original sentence.

The sentence should just say instead "If the client wishes to authenticate to the KDC anonymously,". Note that the word "to" is added after the verb "authenticate". This is because the proposed change suggests that the client is motivated by the attempt to authenticate the KDC, such line of reasoning seems misplaced. The reason that the client sends a AS_REQ to the KDC is to authenticate the server, not to authenticate the KDC.

--larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Larry Zhu
Sent: Wednesday, April 09, 2008 1:19 PM
To: Paul Leach; [email-masked]
Subject: Re: [Ietf-krb-wg] comments on draft-ietf-krb-wg-anon-05.txt

150c150,152

183,184c184,187

Or the full text.

Agreed.

How about the following:

---
341,347c353,359

--larry

---

From: Sam Hartman <[email-masked]>
Date: Fri, 11 Apr 2008 14:37:37 -0400

>>>>> "Larry" == Larry Zhu <[email-masked]> writes:

    >> 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.

    Larry> The comment is somewhat related to the strayed
    Larry> understanding but I would propose the following
    Larry> clarification:

    Larry> 183,184c184,187 < the realm that issued the initial ticket
    Larry> for the client principal, < or the anonymous realm name.
    Larry> ---
    >> the realm that issued the initial ticket for the client
    >> principal (when the anonymous ticket is obtained using
    >> anonymous PKINIT from a Kerberos realm other than that of the
    >> client as described in Section 4), or the anonymous realm name.

Hmm.  What controls whether you end up with the wellknown anonymous
realm or something else?

---

From: Larry Zhu <[email-masked]>
Date: Fri, 11 Apr 2008 11:43:34 -0700

It is based on local policy on the KDC. Whether the realm name part is disclosed or not is controlled by the issuing KDC, not by the client in this protocol. The KDC policy could be on the per-client basis however.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 11 Apr 2008 15:06:48 -0400

>>>>> "Larry" == Larry Zhu <[email-masked]> writes:

    Larry> It is based on local policy on the KDC. Whether the realm
    Larry> name part is disclosed or not is controlled by the issuing
    Larry> KDC, not by the client in this protocol. The KDC policy
    Larry> could be on the per-client basis however.  -----

OK.  That's entirely unclear from the document.
I had interpreted the document to mean:

* if you use pkinit in as-req, then you always get the well known realm name.

* If you use anonymous against your local kdc in TGS then you get that realm

* If you use anonymous against a remote KDC in TGS then you either get your client realm or that KDC's realm.

I'm concerned that making this a local policy issue interacts badly
with GSS-API.

---

From: Larry Zhu <[email-masked]>
Date: Fri, 11 Apr 2008 12:18:49 -0700

On page 6, section 4 it says:

   When policy allows, the KDC issues an anonymous ticket.  Based on
   local policy, the client realm in the anonymous ticket can be the
   anonymous realm name or the realm of the KDC.

If we were to allow the client to control the release of realm part of not, the client would need to securely know what is the realm name that the KDC ends up giving the client. Currently that only be accomplished by bringing in kerb-fast, or we could introduce yet another ticket flag for this.

Your interpretations turn out be what the protocol allows.

The interaction with GSS-API is no worse than what the Kerberos referrals ID gives us. Essentially the KDC determines what the client's name is in this case, and in the referrals case.