Subject: [abfab] Comments on draft-ietf-abfab-gss-eap-02.txt

From: Alexey Melnikov <[email-masked]>
Date: Sun, 18 Sep 2011 09:33:25 +0100

My general feeling is that the document is close to being done, modulo 
some XXX-style comments in several places.
Some specific comments (mostly nits) below.

General comment: the document is using terminology for multiple technologies
(EAP, GSS-API and even SASL). While I think the document is correct and
it explains most of the terms used, some additional references on first
use would be very helpful in order to improve readability.
In particular I am thinking about Section 1 and its subsections, e.g. 
Section 1.2.

In Section 1, 5th paragraph:

   The goal of this specification is to combine GSS-API's support for
   application protocols with EAP/AAA's support for common credential
   types and for authenticating to a server without requiring that
   server to specifically support the authentication method in use.  In
   addition, this specification supports thearchitecture goal of

Missing space, should be "the architecture".

   transporting attributes about subjects to relying parties.  Together
   this combination will provide federated authentication and
   authorisation for GSS-API applications.

3.  EAP Channel Binding and Naming

   EAP authenticates a realm.

The whole realm? I thought a realm is a collection of user and service 
accounts.

   The peer knows that it has exchanged
   authentication with an EAP server in a given realm.

3.1.  Mechanism Name Format

   The string representation of the GSS-EAP mechanism name has the
   following ABNF [RFC5234] representation:

          ; Define name-string to handle escaping and prevent / and @

I was about to ask where is it defined.

          empty =

This is going to fail ABNF validation. Use something like 0"blah".

          user-or-service = name-string
          host = empty/name-string

Can host really be empty? If yes, this can result in the following name:

   user-or-service "/" "@" realm

Is it going to be valid?
If not, you might be missing an extra pair of [] in the definition
of <name> below:

          realm = name-string
          service-specific = name-string
          service-specifics = service-specific 0*('/' service-specifics)
          name = user-or-service '/' host [ '/' service-specifics] [ '@'
                  realm ]

Also change a single quote to double quote, otherwise this is not a 
correct ABNF.

   The user-or-service component is the portion of a network access
   identifier (NAI) before the '@' symbol for initiator names

NAI syntax needs a reference.

   and the
   service name from the registry of GSS-API host-based services in the
   case of acceptor names [GSS-IANA].

   If the null name type or the GSS_EAP_NT_EAP_NAME (oid XXX) is

Yes, this needs to be defined :-).

   imported, then the string representation above should be directly
   imported.  Mechanisms MAY support the GSS_KRB5_NT_KRB5_PRINCIPAL_NAME
   name form with the OID {iso(1) member-body(2) United States(840)
   mit(113554) infosys(1) gssapi(2) krb5(2) krb5_name(1)}.

3.4.  Proxy Verification of Acceptor Name

This section is empty.

5.1.  Mechanisms and Encryption Types

   This mechanism family uses the security services of the Kerberos
   cryptographic framework [RFC3961].  As such, a particular encryption
   type needs to be chosen.  By convention, there is a single object
   identifier arc for the EAP family of GSS-API mechanisms.  A specific
   mechanism is chosen by adding the numeric Kerberos encryption type
   number to the root of this arc.  However, in order to register the
   SASL name, the specific usage with a given encryption type needs to
   be registered.  This document defines the eap-aes128-cts-hmac-sha1-96
   GSS-API mechanism.  XXX define an OID for that and use the right
   language to get that into the appropriate SASL registry.

Yes :-).

5.2.  Processing received tokens

   Implementations of this mechanism maintain a state machine for the
   context establishment process.  Both the initiator and acceptor start
   out in the initial state; see Section 5.4 for a description of this
   state.  Associated with each state are a set of subtoken types that
   are processed in that state and rules for processing these subtoken
   types.  The reciever examines the subtokens in order, processing any
   that are appropriate for the current state.

What happens to the subtokens which are not appropriate for the current 
state?

5.4.2.  Acceptor Name Request

   The acceptor name request token is sent from the initiator to the
   acceptor indicating that the initiator wishes a particular acceptor
   name.  This is similar to TLS Server Name Indication.

This needs an Informative Reference.

In Section 5.5:

   o  If the acceptor receives an EAP failure, then the acceptor sends
      this in the Eap Request subtoken type.  If the initiator receives
      an EAP Failure, it returns GSS failure.

Can you expand on what you mean here. "receive" doesn't mean receive 
over the wire here, right?
Also, what does it mean to return a "GSS failure"?

5.6.2.  Channel Bindings Subtoken

   Again, only the application data is sent in the channel binding.  The
   initiator and acceptor addresses are ignored.

I am not entirely clear on what you mean here by "addresses are ignored".

In 5.6.3:

   The input to GSS_GetMIC is as follows:

   1.  The DER-encoded object identifier of the mechanism in use; this
       value starts with 0x06 (the tag for object identifier).  When
       encoded in an RFC 2743 context token, the object identifier is
       preceeded by the tag and length for [Application 0] SEQUENCE.
       This tag and the length of the overall token is not inclded; only
       the tag, length and value of the object identifier itself.

   2.  A 16-bit token type in network byte order of the RFC 4121 token
       identifier (0x0601 for initiator, 0x0602 for acceptor).

   3.  For each subtoken other than the MIC subtoken itself:

What is the order of subtokens?
Does this cover all subtokens sent during the extension phase?
Does this cover only subtokens sent by the initiator/acceptor respectively?

       1.  A four octet subtoken type in network byte order

       2.  A four byte length in network byte order

       3.  Length octets of value from that subtoken

6.  Acceptor Services

   The CRK is derived from the GMSK using the following procedur

Typo: procedure

   Tn = pseudo-random(KMSK, n || "rfc4121-gss-eap")

How is "n" respresented, in particular how many bytes are used to 
represent it?

   CRK = truncate(L, T1 || T2 || .. || Tn)
   L = output RFC 3961 key size

In Section 6.1:

   In this mechanism an extension option of type 0 with the critical bit

I am a bit confused here: what is "an extension option".

   set is sent from the initiator to the acceptor.  This option contains
   a GSS_Wrap token of the channel binding data passed into
   GSS_Init_sec_context.

8.1.  RFC 4121 Token Identifiers

   A new top level registry titled "Kerberos GSS-API Mechanism
   Parameters," should be created.  This registry should be separate
   from the existing "Kerberos Parameters" registry.

   In this registry is a subregistry called "Kerberos GSS-API Token
   Identifiers"; the overall reference for this subregistry is section
   4.1 of RFC 4121.

What is the IANA registration procedure here?

8.4.  GSS EAP Errors

   A new subregistry is created in the GSS EAP parameters registry
   titled "Error Codes".  XXX fill in minor statuses.

What is the IANA registration procedure here?