A GSS-API Mechanism for the Extensible Authentication Protocol
draft-ietf-abfab-gss-eap-09

[Ballot comment]
Just one small thing about the IANA Considerations: The reference to "section 4.1 of RFC 4121" makes it clear, but it would be useful if one detail of the registry in 7.2 were specified here... the "ID" field is two octets, specified in hex in big-endian order.  Having that bit here will make it easier for IANA to see that IDs have been specified correctly, without their having to go look in RFC 4121.

[Ballot comment]
Only nits:

1) abstract: expand GS2.

2) s1: First sentence reads a little odd: The architecture describes an architecture.  Maybe the following is a little better:

OLD:

The ABFAB architecture [I-D.ietf-abfab-arch] describes an
architecture for providing federated access management to
…

NEW:

ABFAB [I-D.ietf-abfab-arch] describes an
architecture for providing federated access management to

3) s1: Maybe r/backend authentication server/backend authentication, authorization, and accounting (AAA) server
that way AAA is expanded and introduced.

4) s3.1: r/mechanism.The/mechanism. The

5) s3.4: r/name.All/name. All

6) s5: r/and body must be present/and body MUST be present

7) s5.1: r/[RFC3961]is/[RFC3961] is

8) s5.5.1 & s5.5.2 : r/required/REQUIRED

9) s6: r/l bits of its input/L bits of its input  - ought to match the notation later which is uppercase L

10) s10.2: There are some outdated references:

== Outdated reference: A later version (-03) exists of
  draft-ietf-abfab-arch-02

== Outdated reference: draft-ietf-krb-wg-gss-cb-hash-agility has been
  published as RFC 6542

== Outdated reference: A later version (-06) exists of
  draft-ietf-radext-radius-extensions-05

== Outdated reference: draft-ietf-radext-radsec has been published as RFC
  6614

IANA has reviewed draft-ietf-abfab-gss-eap-08 and has the following
comments:

IANA understands that, upon approval of this document, there are
seven IANA actions which must be completed.

First, in the Network Management Parameters registry located at:

http://www.iana.org/assignments/smi-numbers

a new subregistry will be created called: "Object Identifiers for Application
Bridging for federated Access".  The registration policy for the new
subregistry is IETF Review or IESG approval as defined by RFC 5226. 
Early allocation in this subregistry is permitted.  The reference for
the root of this OID delegation will be updated to point to the newly
created registry.

There are initial registrations in this new subregistry as follows:

Prefix: iso.org.dod.internet.security.mechanisms.abfab (1.3.6.1.5.5.15)

Decimal  Name          Description                          References
-------  ----          ------------------------------------  ----------
      0  Reserved      Reserved
      1  mechanisms    A sub-arc containing ABFAB mechanisms
      2  nametypes    A sub-arc containing ABFAB GSS-API Name Types

Prefix: iso.org.dod.internet.security.mechanisms.abfab.mechanisms
        (1.3.6.1.5.5.15.1)

Decimal  Name          Description                          References
-------  ----          ------------------------------------  ----------
      0  Reserved      Reserved
      1  gss-eap-v1    The GSS-EAP mechanism              [ RFC-to-be ]


Prefix: iso.org.dod.internet.security.mechanisms.abfab.nametypes
        (1.3.6.1.5.5.15.2)

Decimal  Name          Description                          References
-------  ----          ------------------------------------  ----------
      0  Reserved      Reserved
      1  GSS_EAP_NT_EAP_NAME                              [ RFC-to-be ]

Second, a new, top-level registry will be created and linked from the IANA
matrix page located at:

http://www.iana.org/protocols/

the new registry will be called the "Kerberos V GSS-API Mechanism Parameters"
registry.  This registry will be separate from the existing "Kerberos
Parameters" registry.

In the new registry created in this task, a new sub-registry called "Kerberos
GSS-API Token Type Identifiers" is created.  The reference for the registry will
be RFC 4121.  The allocation procedure for the new subregistry will be expert
review as defined in RFC 5226.

There are initial registrations in this new subregistry as follows:

+-------+---------------------------------+-----------------------+
| ID    | Description                    | Reference            |
+-------+---------------------------------+-----------------------+
| 01 00 | KRB_AP_REQ                      | RFC 4121 sect 4.1    |
|      |                                |                      |
| 02 00 | KRB_AP_REP                      | RFC 4121 sect 4.1    |
|      |                                |                      |
| 03 00 | KRB_ERROR                      | RFC 4121 sect 4.1    |
|      |                                |                      |
| 04 04 | MIC tokens                      | RFC 4121 sect 4.2.6.1 |
|      |                                |                      |
| 05 04 | wrap tokens                    | RFC 4121 sect 4.2.6.2 |
|      |                                |                      |
| 06 01 | GSS-EAP initiator context token | Section 5            |
|      |                                |                      |
| 06 02 | GSS EAP acceptor context token  | Section 5            |
+-------+---------------------------------+-----------------------+

In the last two registrations, the reference will include [ RFC-to-be ].


Third, a new, top-level registry will be created and linked from
the IANA matrix page located at:

http://www.iana.org/protocols/

the new registry will be called the "The Extensible Authentication Protocol
Mechanism for the Generic Security Services Application Programming Interface
(GSS-EAP) Parameters".  In any short form of that name, including any URI for
this registry, the string GSS will come before the string EAP.

In this new registry a new subregistry called the "GSS EAP Subtoken Types"
subregistry will be created.  The allocation procedure for the new subregistry
will be expert review as defined in RFC 5226.

There are initial registrations in this new subregistry as follows:

+------------+--------------------------+---------------+
| Type      | Description              | Reference    |
+------------+--------------------------+---------------+
| 0x00000001 | Error                    | Section 5.3  |
|                                      |              |
| 0x0000000B | Vendor                  | Section 5.4.1 |
|            |                          |              |
| 0x00000002 | Acceptor name request    | Section 5.4.2 |
|            |                          |              |
| 0x00000003 | Acceptor name response  | Section 5.4.3 |
|            |                          |              |
| 0x00000005 | EAP request              | Section 5.5.1 |
|            |                          |              |
| 0x00000004 | EAP response            | Section 5.5.2 |
|            |                          |              |
| 0x0000000C | Flags                    | Section 5.6.1 |
|            |                          |              |
| 0x00000006 | GSS-API channel bindings | Section 5.6.2 |
|            |                          |              |
| 0x0000000D | Initiator MIC            | Section 5.6.3 |
|            |                          |              |
| 0x0000000E | Acceptor MIC            | Section 5.6.3 |
+------------+--------------------------+---------------+

In all of these registrations, the reference will include [ RFC-to-be ].

Fourth, in the RADIUS attribute type value subregistry of the RADIUS Types
registry located at:

http://www.iana.org/assignments/radius-types/radius-types.xml

four new RADIUS attribute types will be added as follows:

+--------------------------------+-----------+----------------------+
| Name                          | Attribute | Description          |
+--------------------------------+-----------+----------------------+
| GSS-Acceptor-Service-Name      | TBD1      | user-or-service      |
|                                |          | portion of name      |
|                                |          |                      |
| GSS-Acceptor-Host-Name        | TBD2      | host portion of name |
|                                |          |                      |
| GSS-Acceptor-Service-specifics | TBD3      | service-specifics    |
|                                |          | portion of name      |
|                                |          |                      |
| GSS-Acceptor-Realm-Name        | TBD4      | Realm portion of    |
|                                |          | name                |
+--------------------------------+-----------+----------------------+

In each of the four registrations above, the reference will be [ RFC-to-be ].

Fifth, in the SASL Mechanisms registry located at:

http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xml

two new SASL mechanisms will be registered as follows:

Mechanism: EAP-AES128
Usage: Common
Reference: [ RFC-to-be ]
Owner: IESG

Mechanism: EAP-AES128-PLUS
Usage: Common
Reference: [ RFC-to-be ]
Owner: IESG

Sixth, in the new GSS EAP registry created in step three of these IANA
actions, a new subregistry will be created called "Error Codes."

The error codes in this registry are unsigned 32-bit numbers. 

Values less than or equal to 127 are assigned by standards action. 
Values 128 through 255 are assigned with the specification required assignment
policy. 
Values greater than 255 are reserved.

There are initial registrations in this new subregistry:

+-------+----------------------------------------------------+
| Value | Description                                        |
+-------+----------------------------------------------------+
| 0    | Reserved                                          |
|      |                                                    |
| 1    | Buffer is incorrect size                          |
|      |                                                    |
| 2    | Incorrect mechanism OID                            |
|      |                                                    |
| 3    | Token is corrupted                                |
|      |                                                    |
| 4    | Token is truncated                                |
|      |                                                    |
| 5    | Packet received by direction that sent it          |
|      |                                                    |
| 6    | Incorrect token type identifier                    |
|      |                                                    |
| 7    | Unhandled critical subtoken received              |
|      |                                                    |
| 8    | Missing required subtoken                          |
|      |                                                    |
| 9    | Duplicate subtoken type                            |
|      |                                                    |
| 10    | Received unexpected subtoken for current state xxx |
|      |                                                    |
| 11    | EAP did not produce a key                          |
|      |                                                    |
| 12    | EAP key too short                                  |
|      |                                                    |
| 13    | Authentication rejected                            |
|      |                                                    |
| 14    | AAA returned an unexpected message type            |
|      |                                                    |
| 15    | AAA response did not include EAP request          |
|      |                                                    |
| 16    | Generic AAA failure                                |
+-------+----------------------------------------------------+

In each of these cases the reference for the initial registrations will
be [ RFC-to-be ].

Seventh, in the new GSS EAP registry created in step three of these IANA
actions, a new subregistry will be created called "Context Flags."

The registration policy for the new subregistry is IETF review or IESG approval.

There are 32 flag bits available for registration represented as hexadecimal
numbers from the most-significant bit 0x80000000 to the least significant bit 0x1.

There is an initial registration in the new subregistry as follows:

+------+-------------------+---------------+
| Flag | Name              | Reference    |
+------+-------------------+---------------+
| 0x2  | GSS_C_MUTUAL_FLAG | Section 5.6.1 |
+------+-------------------+---------------+

The reference for the initial registration will be [ RFC-to-be ].

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (A GSS-API Mechanism for the Extensible Authentication Protocol) to Proposed Standard


The IESG has received a request from the Application Bridging for
Federated Access Beyond web WG (abfab) to consider the following
document:
- 'A GSS-API Mechanism for the Extensible Authentication Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-07-10. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines protocols, procedures, and conventions to be
  employed by peers implementing the Generic Security Service
  Application Program Interface (GSS-API) when using the EAP mechanism.
  Through the GS2 family of mechanisms, these protocols also define how
  Simple Authentication and Security Layer (SASL, RFC 4422)
  applications use the Extensible Authentication Protocol.

The normative reference to the IANA registry [GSS-IANA] might be
considered a downref.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-abfab-gss-eap/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-abfab-gss-eap/ballot/


No IPR declarations have been submitted directly on this I-D.