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

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 25 Nov 2007 00:03:44 -0500 (EST)

The following are my last-call comments on draft-ietf-krb-wg-anon-04.txt.
I had a total of 8 comments.  Naturally, I'd like to see them all
addressed, but particularly I believe that the items mentioned in
comments 1, 4, and 6 should be addressed before moving forward, and
the items mentioned in comments 5, 7, and 8 are essential.

On a related note, I'd like to hear from implementors who are planning on
including this feature, and from anyone who expects to make use of it.

-- Jeff

[JTH.1] (Section 1)  This section contains the statement "These extensions
provide Kerberos with functional equivalence to TLS".  Don't say that; the
extensions in this document provide Kerberos with a feature that TLS has,
but that's not the same as "functional equivalence".  This statement should
be dropped entirely, along with the reference to RFC4346 (which is not
normative in any case).

[JTH.2] (throughout)  This document contains no fewer than 29 mentions of
RFC4120, sometimes two or three times in a single sentence.  It can be
assumed that the reader, having once read RFC4120, will be aware that it is
the source of definitions of Kerberos PDU's.  Thus, it is not necessary to
cite RFC4120 every time a field from a Kerberos PDU is mentioned.  The same
goes for the PDU's themselves and for error codes.

[JTH.3] (throughout)  Since the presence and format of error-data is based
solely on the error code and not on the particular situation or reason for
which it was generated, it is not necessary when specifying the reuse of
existing error codes to say "and there is no accompanying e-data defined in
this document" -- no e-data _can_ be defined for an existing error code
which is already specified not to include any.  Reserve language of this
sort for when you are introducing a new error code.

[JTH.4] (Section 4, Page 7, 4th graf)  This paragraph describes how the KDC
should compute the authtime field for an anonymous ticket.  This seems to
be identical to the method prescribed by RFC4120 for all other tickets,
except that for initial ticket (returned in an AS exchange), the present
document uses the vague phrase "the request time" where RFC4120 specifies
"the current time on the Kerberos server".  It seems to me that for the
present document to address this is neither necessary nor adviseable; I
recommend dropping the paragraph entirely.

[JTH.5] (Section 6)  Plenty of attention is given to the need for clients
to take care to avoid revealing their identity.  However, there is no
mention made of the need for application servers to avoid accepting
anonymous credentials in situations where they must record the client's
identity; for example, when there must be an audit trail.

[JTH.6] (Section 7)  My name is spelled J-E-F-F-R-E-Y, not ---E-R-Y.  I
believe Jeff Altman uses the same spelling.  Check with Love on the correct
spelling of his name in US-ASCII; I'm pretty sure 'Aestrand' is not
correct.

[JTH.7] (Section 4)  Olga Kornievskaia made the following comment back in
March:

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

I replied:
> 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.

But this has not been done -- the paragraph in question still refers to
the client name and client realm in the EncKDCRepPart, which does not
contain these fields.

[JTH.8] Per http://www.ietf.org/ID-Checklist.html Section 3.1 (D), the
abstract should mention that this document updates RFC4120; this is in
addition to the "Updates: RFC4120" in the header.

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 25 Nov 2007 00:06:53 -0500 (EST)

> addition to the "Updates: RFC4120" in the header.

It turns out that this also affects draft-ietf-krb-wg-naming-04.txt, which
I will be asking Sam to take to the IESG very soon.  In the case of that
document, I think we can address the issue with a note to the RFC Editor,
if there are no other issues raised that call for a new draft.

-- Jeff