Subject: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-10.txt

From: [email-masked]
Date: Fri, 06 Feb 2015 07:43:01 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF.

        Title           : A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for SAML
        Authors         : Josh Howlett
                          Sam Hartman
                          Alejandro Perez-Mendez
	Filename        : draft-ietf-abfab-aaa-saml-10.txt
	Pages           : 24
	Date            : 2015-02-06

Abstract:
   This document describes the use of the Security Assertion Mark-up
   Language (SAML) with RADIUS in the context of the ABFAB architecture.
   It defines two RADIUS attributes, a SAML binding, a SAML name
   identifier format, two SAML profiles, and two SAML confirmation
   methods.  The RADIUS attributes permit encapsulation of SAML
   assertions and protocol messages within RADIUS, allowing SAML
   entities to communicate using the binding.  The two profiles describe
   the application of this binding for ABFAB authentication and
   assertion query/request, enabling a Relying Party to request
   authentication of, or assertions for, users or machines (Clients).
   These Clients may be named using a NAI name identifier format.
   Finally, the subject confirmation methods allow requests and queries
   to be issued for a previously authenticated user or machine without
   needing to explicitly identify them as the subject.  These artifacts
   have been defined to permit application in AAA scenarios other than
   ABFAB, such as network access.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-abfab-aaa-saml/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-abfab-aaa-saml-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-abfab-aaa-saml-10

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Fri, 06 Feb 2015 17:00:01 +0100

Dear all,

we have generated a new version of the draft including the following 
changes:

  * General editorial work (typo correction and wordsmithing)  on the
    document.
  * Addressing of the editorial comments provided by Troy Shields.
  * Made terminology more consistent with ABFAB. Everything now is
    explained in terms of Clients, RPs, and IdPs.
  * Extended description of the SAML-Message and SAML-Assertion
    attributes (following the typical procedure with the figure and the
    description of each field).
  * Changes to the Privacy and the Security Considerations sections.
  * Changes to the IANA Considerations section dealing with the
    registration of the new attributes.
  * Completed the Acknowledgement section.

Best regards,
Alejandro

> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 09 Feb 2015 12:44:31 +0100

Dear all,

with the submission of the updated version of the aaa-saml 
(draft-ietf-abfab-aaa-saml-10), we consider the document is now ready 
for a Last Call.

Best regards,
Alejandro

El 06/02/15 a las 17:00, Alejandro Perez Mendez escribió:
>     attributes (following the typical procedure with the figure and
>     the description of each field).

---

From: Leif Johansson <[email-masked]>
Date: Sun, 15 Feb 2015 12:56:20 +0100

> (draft-ietf-abfab-aaa-saml-10), we consider the document is now ready

Hmm, I'd feel more comfortable if we'd had one or two reviewers...

---

From: Leif Johansson <[email-masked]>
Date: Tue, 17 Feb 2015 09:43:44 +0100

> Hmm, I'd feel more comfortable if we'd had one or two reviewers...

In case somebody missed the hint...  that was a call for volunteers :-)

---

From: Stefan Paetow <[email-masked]>
Date: Tue, 17 Feb 2015 18:59:06 +0000

> > (draft-ietf-abfab-aaa-saml-10), we consider the document is now ready

[...]
> Hmm, I'd feel more comfortable if we'd had one or two reviewers...

Ok, mostly grammatical and syntax nits:

1. Introduction:

Two sets of bullets in the introduction. The first set ends each
bullet with a full-stop. The second doesn't. Thus the corrected text
is:

   o  A URI that uniquely identifies the protocol binding or profile.

   o  Postal or electronic contact information for the author.

   o  A reference to previously defined bindings or profiles that the
      new binding updates or obsoletes.

   o  In the case of a profile, any SAML confirmation method identifiers
      defined and/or utilized by the profile.

2. Section 4.3.2:

Missing full-stop after <entityId>. Thus the corrected text is (in
keeping with the later Relying Parties paragraph):

   Identity Providers MAY apply policy based on the Relying Party's SAML
   <entityId>. In such cases, at least one of the following methods is
   required in order to establish a relation between the SAML name and
   the AAA name of the Relying Party:

3. Section 4.3.4:

Is a comma missing after 'provide policy' in the last sentence of this
section, i.e:

   RADIUS configuration is used to provide policy, including
   which attributes are accepted from a Relying Party and which
   attributes are sent by an Identity Provider.

4. Section 6.2:

Again a missing comma, this time after 'this scenario', i.e:

   To implement this scenario, a profile of the SAML Authentication
   Request protocol is used in conjunction with the SAML RADIUS binding
   defined in Section 4.

5. Finally, Section 9:

Is that a Relaying or a Relying Party in the first sentence of the
first paragraph in this section? Based on the remainder of the text,
it should be 'Relying'? Corrected text:

   The profiles defined in this document allow a Relying Party to
   request specific information about the Client, and allow an IdP to
   disclose information about that Client.

I haven't spotted anything else... feel free to tell me I'm wrong :-)

With Regards

Stefan

---

From: Stefan Paetow <[email-masked]>
Date: Wed, 18 Feb 2015 16:49:53 +0000

[...]
> Hmm, I'd feel more comfortable if we'd had one or two reviewers...

Hi, 

I read through the draft and have a couple of nits that you're welcome to tell me to go away with:

- Introduction:

The introduction contains two bulleted lists. The first terminates each bullet with a fullstop. The second doesn't. Elsewhere in the document, other bulleted lists follow the format of the first. For consistency, the second list in the introduction should follow the same format:

- Section 4.3.2:

A fullstop is missing after the <entityId> in the first paragraph. It should be:

- Section 4.3.4:

A missing comma in the last sentence of this section. It should be:

   [...] RADIUS configuration is used to provide policy, including
   which attributes are accepted from a Relying Party and which
   attributes are sent by an Identity Provider.

- Section 6.2: 

A missing comma in the first sentence of this section. It should be:

- Section 9:

The first sentence refers to a 'Relaying Party', while the remainder of this section refers to a 'Relying Party'. I can only assume that 'Relaying' should actually be 'Relying'. Corrected text:

   The profiles defined in this document allow a Relying Party to
   request specific information about the Client, and allow an IdP to
   disclose information about that Client. [...]

>   o  Assume that the Client's identifier implied by a SAML <Subject>
>         element, if present, takes precedence over an identifier
>         implied
>               by the RADIUS User-Name attribute.
> 
> 
> *what*?!  This flies in the face of 4.3.1.

Does 4.3.1 refer to the outer identity of a request (I assume so)? AFAIK, 4.3.1 refers only to the NAI realm (the RP doesn't have access to the full identity). 6.4.2 specifies that if the IdP issues an assertion, the assertion's <Subject> may refer to the actual user (I assume that's the inner?), in which case, 6.4.3 makes sense where the <Subject>, if it exists, overrides whatever was in the original request's User-Name attribute? Or am I mixing things up? Just a question... :-)

Stefan Paetow
Moonshot Industry & Research Liaison Coordinator

t: +44 (0)1235 822 125
gpg: 0x3FCE5142
xmpp: [email-masked]
skype: stefan.paetow.janet
Lumen House, Library Avenue, Harwell Oxford, Didcot, OX11 0SG

jisc.ac.uk
 
Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 19 Feb 2015 08:07:45 +0100

Hi Stefan,

thanks for the review. I will apply the changes for the next version.

Regards,
Alejandro

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 19 Feb 2015 09:06:50 +0100

Hi Stefan,

thanks again for the review. See my comments below.

>     disclose information about that Client. [...]

Thanks for these. I will include them for the next version.

> Does 4.3.1 refer to the outer identity of a request (I assume so)? AFAIK, 4.3.1 refers only to the NAI realm (the RP doesn't have access to the full identity). 6.4.2 specifies that if the IdP issue…

Actually, 4.3.1 does not refer to Client's identity, but RP's and IdP's 
identities, whereas 6.4.3 does refer to Client's identity.

Regards,
Alejandro