Subject: draft-ietf-krb-wg-anon-03 review

From: Shawn M Emery <[email-masked]>
Date: Tue, 27 Mar 2007 23:01:55 -0600

Here is my review of draft-ietf-krb-wg-anon-03:

3. Definitions
The name-type field is incorrectly specified for principals, this should 
be KRB_NT_WELLKNOWN, not KRB_NT_RESRVED.

4. Protocol Description
The segment starting with "and this rule MUST..." should be a separate 
sentence and reworded for readability purposes.

For this concept:
"A server accepting an anonymous service ticket may assume that 
subsequent requests using the same ticket originate from the same client."

could be a bad assumption, since you would be dependent on other 
information, such as a time stamp.  When spread across multiple machines 
and users this could be a larger assumption than normal.

You should mention that applications can detect if anonymity is 
supported by the mechanism by checking the GSS-API's ret_flags.

Shawn.
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 28 Mar 2007 10:39:42 -0400

On Tuesday, March 27, 2007 11:01:55 PM -0600 Shawn M Emery 
<[email-masked]> wrote:

> information, such as a time stamp.

How so?  The presumption is that any given ticket is issued only to a 
single client, and in fact this is necessary to securly authenticate the 
server's identity, since anyone who knows the session key in a ticket could 
impersonate the server.

-- Jeff

---

From: Olga Kornievskaia <[email-masked]>
Date: Thu, 29 Mar 2007 15:25:08 -0400

Here some additional comments&questions based on my reading of 
draft-ietf-krb-wg-anon-03:

1. What's the advantage of allowing user to request an anonymous TGT 
based on a normal TGT from the TGS instead of just getting an anonymous 
TGT from the AS?

2. Somewhere in Section 4 has the following:

	However, in all cases,
   the client name and the client realm in the EncKDCRepPart of the
   reply [RFC4120] MUST match with the corresponding client name and the
   client realm of the anonymous ticket in the reply.  The client MUST
   use the client name and the client realm returned in the
   EncKDCRepPart in subsequent message exchanges when using the obtained
   anonymous ticket.

EncKDCRepPart *does not* have client name and client realm, KDC-REP 
does. Below are the 3 structures  from rfc4120 that mentioned by the 
above text:

KDC-REP         ::= SEQUENCE {
        pvno            [0] INTEGER (5),
        msg-type        [1] INTEGER (11 -- AS -- | 13 -- TGS --),
        padata          [2] SEQUENCE OF PA-DATA OPTIONAL
                                -- NOTE: not empty --,
        crealm          [3] Realm,
        cname           [4] PrincipalName,
        ticket          [5] Ticket,
        enc-part        [6] EncryptedData
                                -- EncASRepPart or EncTGSRepPart,
                                -- as appropriate
}

EncKDCRepPart   ::= SEQUENCE {
        key             [0] EncryptionKey,
        last-req        [1] LastReq,
        nonce           [2] UInt32,
        key-expiration  [3] KerberosTime OPTIONAL,
        flags           [4] TicketFlags,
        authtime        [5] KerberosTime,
        starttime       [6] KerberosTime OPTIONAL,
        endtime         [7] KerberosTime,
        renew-till      [8] KerberosTime OPTIONAL,
        srealm          [9] Realm,
        sname           [10] PrincipalName,
        caddr           [11] HostAddresses OPTIONAL
}

Ticket          ::= [APPLICATION 1] SEQUENCE {
        tkt-vno         [0] INTEGER (5),
        realm           [1] Realm,
        sname           [2] PrincipalName,
        enc-part        [3] EncryptedData -- EncTicketPart
}

My question is what should the client be matching? Ticket's unencrypted 
part doesn't have the client's name. EncKDCRepPart doesn't have it. 
Client can check KDC-REP has anonymous crealm and cname. I don't see 
this as a matching process but more of verification process.

3. Later on in Section 4:

   If the client is anonymous and the KDC does not have a key to encrypt
   the reply (this can happen when, for example, the KDC does not
   support PKINIT [RFC4556]), the KDC MUST return an error message with
   the code KDC_ERR_NULL_KEY [RFC4120] and there is no accompanying
   e-data defined in this document.

This paragraph that states if KDC doesn't support PKINIT it should fail 
the request for an anonymous ticket contradicts an earlier paragraph:

	If the KDC does not have an asymmetric key
   pair, it MAY reply anonymously or reject the authentication attempt.
   If the KDC replies anonymously, both the signerInfos field and the
   certificates field of the SignedData [RFC3852] of PA_PK_AS_REP in the
   reply are empty.  The server name in the anonymous KDC reply contains
   the name of the TGS.

4. I found the section on propagation of authorization data unreadable.

Shawn M Emery wrote:
> The name-type field is incorrectly specified for principals, this 
> should be KRB_NT_WELLKNOWN, not KRB_NT_RESRVED.
>
> 4. Protocol Description
> information, such as a time stamp.  When spread across multiple 
> machines and users this could be a larger assumption than normal.
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 29 Mar 2007 23:07:57 -0400

> based on a normal TGT from the TGS instead of just getting an anonymous

(a) The AS may not be willing to grant an anonymous ticket.
(b) A user with a non-anonymous TGT may want to use anonymous tickets with 
some services; clients for these services may even be configured to do so 
automatically.  This is a lot less painful if the user (or rather, an 
application client acting on his behalf) can use his existing TGT to obtain 
anonymous tickets.

> EncKDCRepPart *does not* have client name and client realm, KDC-REP does.

I suspect EncTicketPart is what is meant here.  In other words, the name 
the KDC tells the client must be the same as the name it gives to the 
service.  This is necessary if the AP-REQ/AP-REP exchange is going to work.

Of course, the client can't see inside the EncTicketPart, so it has to use 
the unencrypted name and realm in the KDC-REP.

So, clearly this text needs to be cleaned up to refer to the correct types.

> Client can check KDC-REP has anonymous crealm and cname. I don't see this
> as a matching process but more of verification process.

The text doesn't say the client should be matching anything.  It requires 
the two copies to be the same; it doesn't require the client to verify that 
they are.

> the request

That's not what it says.  The text you quote says the KDC must fail the 
request if it does not have any way to encrypt the reply, which is really 
just common sense.  The interesting thing here is that that is considerably 
more likely to be true if the client is anonymous.  The parenthetical text 
comments that this _can_ happen when the KDC doesn't support PKINIT, which 
doesn't mean it is guaranteed to happen in that case.

BTW, as long as we're looking at this paragraph, I don't think it's 
necessary to say "and there is no accompanying e-data defined in this 
document".  Since the error code in question is not defined in this 
document, there really is no reason to talk about what it's e-data may or 
may not be.

> for an anonymous ticket contradicts an earlier paragraph:
>

This does not appear to me to be a contradiction in any case.  This 
paragraph is talking about the case where a KDC does not have a public key 
pair with which to prove its identity to the client.  In this case, the 
quoted paragraph allows the KDC to send an unauthenticated reply.  I don't 
see a problem here, though I'm not sure what purpose it serves.

> 4. I found the section on propagation of authorization data unreadable.

Yeah, that section needs a lot of work.  The intent is to try to achieve 
two contradictory goals:

(a) Avoid disclosing the client's identity to the application service.
(b) Avoid removing authorization data which may contain restrictions on
    what the client is permitted to do.

So, the KDC needs to remove enough AD to satisfy (a), but not so much that 
it fails to satisfy (b).  Of course, that may be impossible, as there may 
be a single AD item which both discloses the user's identity and contains a 
restriction; one example of this is the Windows PAC, which contains group 
membership information that may be used by some servicse to deny access.

This is made harder by the fact that there may be AD present that the KDC 
doesn't understand.  The section you had trouble following attempts to 
describe how to do this, but doesn't succeed very well.

I'd very much like to see someone contribute text that says something 
useful here, in a way that is understandable.

-- Jeff

---

From: Shawn M Emery <[email-masked]>
Date: Thu, 29 Mar 2007 23:41:14 -0600

Jeffrey Hutzelman wrote:
> single client, and in fact this is necessary to securly authenticate 
> the server's identity, since anyone who knows the session key in a 
> ticket could impersonate the server.
I was looking at this from the server's perspective for replay 
detection.  If the client element is removed then it is more likely for 
authenticator collision.

Shawn.
--