Subject: [abfab] Last Call: <draft-ietf-abfab-gss-eap-naming-05.txt> (Name Attributes for the GSS-API EAP mechanism) to Proposed Standard

From: The IESG <[email-masked]>
Date: Thu, 20 Sep 2012 07:17:17 -0700

The IESG has received a request from the Application Bridging for
Federated Access Beyond web WG (abfab) to consider the following
document:
- 'Name Attributes for the GSS-API EAP mechanism'
  <draft-ietf-abfab-gss-eap-naming-05.txt> 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
[email-masked] mailing lists by 2012-10-04. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   The naming extensions to the Generic Security Services Application
   Programming interface provide a mechanism for applications to
   discover authorization and personalization information associated
   with GSS-API names.  The Extensible Authentication Protocol GSS-API
   mechanism allows an Authentication/Authorization/Accounting peer to
   provide authorization attributes along side an authentication
   response.  It also provides mechanisms to process Security Assertion
   Markup Language (SAML) messages provided in the AAA response.  This
   document describes the necessary information to use the naming
   extensions API to access that information.

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

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

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

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 21 Sep 2012 00:15:16 +0200

I found no major issues with this document.  I support publishing it if
the minor issues below are resolved.  The document is written in a
rather information dense style, but I can't come up with any easy way to
make it more accessible.  More examples and illustrations would help,
but I don't see this as sufficient reason to not move forward.

/Simon

Minor issues:

   The naming extensions [I-D.ietf-kitten-gssapi-naming-exts]to the
                                                             ^
insert SPC

   mechanism allows an Authentication/Authorization/Accounting peer to
                                                              ^
...
   [I-D.ietf-abfab-gss-eap] allows an Authentication/Authorization/
   Accounting peer to provide authorization attributes along side an
             ^
add '(AAA)'.  Otherwise the AAA acronym is not expanded.

   The first is a URI describing the format of the name.  The second
                  ^^^
Expand acronym on first use.

   The first is a URN indicating that the name is a SAML attribute and
                  ^^^
Expand acronym on first use.

   context Section 4 are issued by the same party performing the
          ^         ^
I believe parenthesis should be inserted here.

   information is combined from AAA and SAML sources.  The SAML IDP and
                                                                ^^^
Expand acronym on first use.

   GSS_S_COMPLETE.  Attributes MAy be absent or values MAY change in
                                 ^
Typo.

   value of this attribute would first wait until GSS-
                                                  ^^^^
   _Accept_sec_Context returned GSS_S_COMPLETE.  Then the application
   ^^^^^^^^^^^^^^^^^^^
Typo, should be 'GSS_Accept_sec_context'.  Check this throughout the
document, there are more incorrect uses.

   GSS_Get_Name_attribute passing this name and an attribute of
           ^
Typo, should be 'GSS_Get_name_attribute'.  Check this throughout the
document, there are more incorrect uses.

   This attribute is returned with the authenticatedoutput of
                                                    ^
Typo.

   assertion, then An attribute with the name
                   ^
Typo.

   "urn:ietf:params:gss:federated-saml-attribute
   urn:oasis:names:tc:SAML:2.0:attrname-format:uri
   urn:oid:1.3.6.1.4.1.5923.1.1.1.7 " could be returned from
                                   ^
Should there really be a SPC at the end?  It is also not clear that
there is a SPC between the parts since they terminate the line.

   GSS_Inquire_Name.  If an application calls GSS_Get_Name_attribute
               ^
Typo, 'GSS_Inquire_name' (and 'GSS_Get_name_attribute'...).

   If the value is not simple or is empty, then the raw value(s) of the
   GSS name attribute MUST be the well-formed serialization of the
   <saml:AttributeValue> element(s) encoded as UTF-8.  The "display"
   values are implementation-defined.

Question: what serialization is intended here?  An example here would
make this more clear.

   mechanisms are permitted to perform local policy checks on SAML
   ^
Typo, capitalize to 'M'.

   choices for non-IETf work.  Expert review is permitted mainly to
                      ^
Typo.