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

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 6 Aug 2013 16:23:02 -0400 (EDT)

On Wed, 10 Apr 2013, [email-masked] 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

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 6 Aug 2013 16:43:53 -0400 (EDT)

> TOK_ID assignments; the current set seems quite sparse.

What is the mechanism to get IANA to update the registry with the 
additional values from RFC 1964?

-Ben

---

From: Tom Yu <[email-masked]>
Date: Tue, 06 Aug 2013 17:17:14 -0400

Benjamin Kaduk <[email-masked]> writes:

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

It seems like GSS-EAP establishes the registry:

    http://tools.ietf.org/html/draft-ietf-abfab-gss-eap-09

and the allocation procedure for TOK_ID values is expert review.  I'm
also noticing that the RFC 4121 reserved values for 6000 through 60ff
(see section 4.4) are not marked as reserved in the registry for some
reason.

---

From: [email-masked] (Martin Rex)
Date: Wed, 7 Aug 2013 00:35:53 +0200 (CEST)

> >> but 0101, 0201, and 0102 are documented in RFC1964.

Glancing over the archives, I see the following TOK_IDs in
Kerberos-specific specifications:

  rfc1964 defines
http://tools.ietf.org/html/rfc1964#page-2
     0100  KRB_AP_REQ                       (page  2)
     0200  KRB_AP_REP                       (page  2)
     0300  KRB_ERROR                        (page  2)

     0101  gss_get_mic() token              (page  7)
     0201  gss_wrap() token                 (page 10)
     0102  gss_delete_sec_context() token   (page 12)

  rfc4121 adds
http://tools.ietf.org/html/rfc4121#section-4.2.6.1
     0404  gss_get_mic() token without generic framing
     0504  gss_wrap() token without generic framing

> (see section 4.4) are not marked as reserved in the registry for some

     6000-60ff reserved to determine if generic GSS-API framing is present
               on per-message tokens just by looking at the first two bytes
               of the token

http://tools.ietf.org/html/draft-swift-win2k-krb-user2user-03
   0400   KERB-TGT-REQUEST
   0401   KERB-TGT-REPLY

http://tools.ietf.org/html/draft-ietf-krb-wg-iakerb-02
   0501   IAKERB_PROXY

plus something "else":

http://tools.ietf.org/html/draft-ietf-abfab-gss-eap-08#page-17

   0601   Initiator->Acceptor Token
   0602   Acceptor->Initiator Token

-Martin

---

From: Luke Howard <[email-masked]>
Date: Wed, 7 Aug 2013 09:49:45 +1000

Also http://tools.ietf.org/html/draft-howard-gss-browserid-04 section 4:

         +---------+----------+-------+--------------------------+
         | Section | Token ID | ASCII |        Description       |
         +---------+----------+-------+--------------------------+
         |  4.1.1  |  0x632C  |   c,  |  Initiator context token |
         |         |          |       |                          |
         |  4.1.2  |  0x432C  |   C,  |  Acceptor context token  |
         |         |          |       |                          |
         |         |  0x442C  |   D,  |  Context deletion token  |
         |         |          |       |                          |
         |  4.2.4  |  0x6D2C  |   m,  | Initiator metadata token |
         |         |          |       |                          |
         |  4.2.4  |  0x4D2C  |   M,  |  Acceptor metadata token |
         +---------+----------+-------+--------------------------+

-- Luke

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 6 Aug 2013 20:28:14 -0400 (EDT)

Martin, Luke, thanks for looking these up, it saved a bunch of time.

I see that draft-ietf-krb-wg-gssapi-cfx-02 (which became RFC4121) had 0405 
for the context deletion token, but this was removed in the -03 in favor 
of not emitting such tokens.

That's the only value in the MIT krb5 tree (that I see) that hasn't been 
mentioned so far.  Heimdal doesn't seem to use defined constants for 
these, so checking is a bit harder; grepping for _gsskrb5_make_header 
doesn't find anything particularly exciting.

I'll tabulate these and send mail to [email-masked] in a few days unless 
alternate advice materializes.
https://datatracker.ietf.org/doc/draft-ietf-abfab-gss-eap/ indicates that 
the IESG has sent it to the RFC editor, so it may be a bit late to get it 
to include the additional RFC 1964 token types.

-Ben

---

From: [email-masked] (Martin Rex)
Date: Wed, 7 Aug 2013 20:53:58 +0200 (CEST)

> of not emitting such tokens.

I just found another one:

  http://tools.ietf.org/html/rfc2743#page-84

  04 01   exported name (token) created by gss_export_name()

In case that anyone is wondering what "per-message token without
generic framing" means:

GSS-API defines a mechanism-independent Token Format in
rfc-2743, section 3.1
   http://tools.ietf.org/html/rfc2743#page-81

(originally in GSS-API v1, rfc-1508, Appendix B)
   http://tools.ietf.org/html/rfc1508#page-48

which must be used for the _initial_context_token_,
This "generic framing" is originally defined as ASN.1, but
the description in rfc2743, section 3.1 also describes that
framing as bits-on-the-wire, so that it can be implemented
without ASN.1 tools.

There is _no_ requirement in the base gssapi specification
for mechanisms what framing or format to use for others but the
initia context token (i.e. the 1st token from Initiator to Acceptor)
or for per-message tokens.

The Kerberos gssapi mechanism (rfc1964) decided to use the generic
framing for _all_ context tokens, and in addition, for _all_ per message
tokens as well.

The update of the Kerberos gssapi mechanism (rfc4121) dropped the
generic framing on the per-message tokens, making the TOKEN_ID the
fist two octets to appear in rfc4121 per-message tokens.

-Martin

---

From: Luke Howard <[email-masked]>
Date: Thu, 8 Aug 2013 09:45:28 +1000

>  04 01   exported name (token) created by gss_export_name()

Ah yes, then you also need RFC 6680 s.7.8:

04 02  exported composite name(token) created by gss_export_name_composite()

-- Luke