Re: [kitten] I-D Action: draft-ietf-kitten-iakerb-00.txt

[Benjamin Kaduk <[e-mail]>]

On Wed, 10 Apr 2013, [e-mail] wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF.
>
> 	Title           : Initial and Pass Through Authentication Using Kerberos V5 and the GSS- API (IAKERB)
> 	Author(s)       : Jim Schaad
>                          Larry Zhu
>                          Jeffery Altman
> 	Filename        : draft-ietf-kitten-iakerb-00.txt
> 	Pages           : 9
> 	Date            : 2013-04-10
>
> Abstract:
>   This document defines extensions to the Kerberos protocol and the
>   GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to
>   exchange messages with the KDC using the GSS-API acceptor as the
>   proxy, by encapsulating the Kerberos messages inside GSS-API tokens.
>   With these extensions a client can obtain Kerberos tickets for
>   services where the KDC is not accessible to the client, but is
>   accessible to the application server.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-kitten-iakerb
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-kitten-iakerb-00

I have reviewed this document.  There are many small fixes which could be 
made, but I don't have any structural objections to the present text.  The 
text for the GSS_EXTS_FINISHED extension will need review when it gets 
brought in, of course.

The source XML should use <rfc updates="4120,4121" ...> to indicate that 
multiple documents are being updated.

In the abstract, "using the GSS-API acceptor as the proxy" should read 
"using the GSS-API acceptor as a proxy" (s/the/a/).  A similar text 
appears in the introduction and should get patched there, too.

In section 3, "All context establishment token" should have "tokens" 
plural.

The next paragraph starts out rather curiously ("The client starts [...] 
to establish the context.").  In addition to being quite long, this 
sentence does not seem to make much sense.  Perhaps the client constructs 
the ticket request "*as if* the ticket request is being made to the KDC."? 
(Note the full stop ending the sentence there.)  Then the next sentence 
could continue "Instead of contacting the KDC directly, the client 
encapsulates [...]".
The diagram here could benefit from an extra line indicating the causality 
-- the message from the proxy back to the client cannot occur until the 
KDC has replied to the proxy.

Right at the top of page 3, the document refers to an "innerToken" 
described in RFC2743, but that string (case-insensitive, with or without 
an intervening space) does not appear in RFC2743.  RFC2743 has 
innerContextToken and innerMsgToken, but it is RFC4121 that has 
innerToken.

Looking up the TOK_ID for IAKERB_PROXY (or rather, how assignments of such 
values are performed) reveals that the IANA registry for token types is 
incomplete(!). 
http://www.iana.org/assignments/kerberos-v-gss-api/kerberos-v-gss-api.xhtml#token-types 
lists only 0100, 0200, 0300, 0404, 0504, 0601, and 0602 as assigned, but 
0101, 0201, and 0102 are documented in RFC1964.
Unfortunately, I still don't have an understanding of the rationale behind 
TOK_ID assignments; the current set seems quite sparse.

The statement "The content of the IAKERB_PROXY message is defined as an 
IAKERB-HEADER structure immediately followed by a Kerberos message." does 
not really indicate that the Kerberos message can be omitted, a case 
described later on for enabling referrals.

This section makes reference to "IAKERB client", "IAKERB proxy", "GSS-API 
server", and "GSS-API acceptor", which could probably be rearchitected to 
be more consistent.

The first sentence of the last paragraph of page 4 ("When obtaining [...] 
Kerberos realm.") is hard to parse.  I think the intent is that the client 
has no realm information at all, not even a default realm for the the 
machine from which the client is acting.  If so, "When obtaining [...] 
name type and no realm information." seems like it would be more clear. 
The following sentence seems to be describing standard (non-IAKERB) 
behavior and should probably be indicated as such.  Then, "In this case" 
would be "When the IAKERB client does not have any realm information 
available".

It seems like it would be wise to explicitly say that after the client 
obtains a service ticket, the subsequent token is of type 
KRB_AP_REQ (not IAKERB_PROXY), instead of just saying "an KRB_AP_REQ 
message".

If I remember correctly, we decided to pull the GSS_EXTS_FINISHED bits 
from PKU2U and include them inline in this document.  I don't, however, 
remember whether Jim was going to do this on his own or who was going to 
help him.  Jim?  (That should probably be in a new section/subsection.)

In the last paragraph of section 3, I might say "Implementations SHOULD 
utilize" instead of "Implementations SHOULD provide" [the AS_REQ 
armoring...].

In the second paragraph of page 6, I think "firewall filters can be 
applied to allow from which hosts the client requests can be proxied" 
would be better as "firewall filters can be applied to restrict from which 
hosts the client requests may be proxied".

-Ben