Subject: [abfab] Comments on draft-ietf-abfab-aaa-saml-05

From: "Jim Schaad" <[email-masked]>
Date: Tue, 26 Feb 2013 11:26:15 -0800

Josh and Sam,

This looks much more like the discussion that we had after the last IETF
meeting so I am generally happy.

1.   I think inserting a paragraph start at "The name identifier..." will
make it clearer which artifacts are designed to be used in ABFAB scenarios
and which are designed for more universal usage.

2.  In section 2  for the last bullet point in the first list - should this
be the subject of an assertion or the subject of a protocol message?  I am
always very unclear about SAML naming of items.  However this confirmation
method can be in both a SAML assertion and in a query (i.e. AttributeQuery).

3. In section 5.2 - I am not happy with the single reference to RADSEC as
being the required.  I would be more happy if the profile required either
TLS/UDP or TLS/TCP as required.  Either that or TLS/TCP should be
recommended.  I am worried that without this there might be an issue with
people thinking it is restricted to UDP.

Note that for longer messages you probably really want to require the
TLS/TCP version not the DTLS/UDP version.

4.  In section 5.2 - I have probably said this before, I am not really a big
fan of the use of language such as "MAY transmit a SAML request".  If you
don't do the request how can one say that you are acting as a SAML
requester.  A similar statement is also made for the second item.  Just say
"returns a  SAML protocol message" and then talk about reasons that you
might not wish to do so.

5.  In section 5.2 - s/responder MAY also return/responder MAY return/ - it
might be read as saying you could return two even though that is explicitly
forbidden.

6.  In section 5.2 - I think we should probably add the following paragraph:

SAML responders SHOULD return a RADIUS state attribute as part of the
Access-Accept message so that future SAML queries can be run against the
same context of an authentication exchange.

7.  In section 6 - update the reference for NAI to draft-ietf-radext-nai

8.  In section 7.3.3 - I am not sure that the dependence on the abfab
document at the end of the section makes sense.  For example, why should the
EAP method support channel binding in order to return a SAML response?  I
think that one can restrict the requirements to those in the AuthnRequest
and those necessitated by the application (whatever the application).  You
probably just missed this in the general ABFAB removal.

9.  In section 7.4.1 - I think the second paragraph can be removed and
placed in section 7.4.2.  It is not related to the AuthnRequest but to the
Response.

10.  In section 7.4.2 - I think we might need to make a statement about
returning no subject identifier and the correct interaction with the
AllowCreate attribute.  If the IdP is not going to return a name, but is
just returning a subject conformation that says - the user associated with
this conversation - is this to be considered a "new identity" for the user?

11.  In section 7.4.2 - I have a problem with the last bullet point.  I
would be happier if the text looked more like:

Other conditions MAY be included as requested by the Relying Party or at the
discretion of the Identity Provider.  The Identity Provider is not obligated
to honor the requested set of conditions in the <samlp:AuthnRequest>, if
any.  If the Identity Provider does not honor the requested set of
conditions is MUST either not return a <samlp:Response> message or return a
<samlp:Response> message with an error.

12.  In section 9.  I think in this case it would be useful to have an
informational reference to TEAP about mapping these from an EAP method to
the URIs specified.

s/artefacts/artifacts/

---

From: Josh Howlett <[email-masked]>
Date: Thu, 28 Feb 2013 09:33:00 +0000

Jim,

>meeting so I am generally happy.

Glad to hear that.

>and which are designed for more universal usage.

Agreed. In fact I'm thinking of re-structuring the entire document to make
that distinction more obvious to the reader (but not sure if it's worth
the pain).

>method can be in both a SAML assertion and in a query (i.e.

In SAML, only assertions and their requests have Subjects; framing PDUs do
not. I'll try to make this more obvious in that bullet.

>TLS/TCP version not the DTLS/UDP version.

Good point, I'll clarify.

>"returns a  SAML protocol message" and then talk about reasons that you

Yes, you did mention that before but I failed to follow through. I will do
so on the next iteration.

>might be read as saying you could return two even though that is

Ok.

>same context of an authentication exchange.

Good idea.

>7.  In section 6 - update the reference for NAI to draft-ietf-radext-nai

Ok -- I had no idea the NAI was being updated (again).

(I note that the new doc talks of "confederations", which I consider a
synonym for "federation" in this context. Possibly the author of that doc
might want to refer to ABFAB, by way of an example?)

>probably just missed this in the general ABFAB removal.

Correct; I'll remove.

>placed in section 7.4.2.  It is not related to the AuthnRequest but to the

Ok.

>this conversation - is this to be considered a "new identity" for the

I need to think about this; I will propose a form of words.

><samlp:Response> message with an error.

The conditions included by the RP in the request are (SAMLCore section
3.4.1) "intended as input to the process of constructing the assertion,
rather than as conditions on the use of the request itself". An assertion
that include these conditions can always be discarded by the RP, so I am
unclear what value the new sentence adds?

>informational reference to TEAP about mapping these from an EAP method to

I'm not sure if we want to explicitly map the TEAP concepts of user and
machine, although I admit that I don't have a strong argument against
this. I suppose have a vague concern that in creating this linkage we
might inadvertently constrain ourselves to TEAP's definition of 'user' or
'machine', or guide implementors/deployers towards use of a specific EAP
method (I suppose that informative usage guards against this to some
extent, but I could imagine an over-zealous interpretations of this).

>s/artefacts/artifacts/

Thanks again for the review.

Josh.

Janet(UK) is a trading name of Jisc Collections and Janet Limited, a 
not-for-profit company which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 28 Feb 2013 15:12:16 +0000

On 2/28/13 4:33 AM, "Josh Howlett" <[email-masked]> wrote:
>
>>2.  In section 2  for the last bullet point in the first list - should
>>this be the subject of an assertion or the subject of a protocol
>>message?  I am

Queries have subjects. I think the bullet's context would apply to both.

>I need to think about this; I will propose a form of words.

AllowCreate is an evil little gnome of a feature, but I think to address
Jim's point, it only applies to identifiers, period. If there's no
identifier asserted, it's irrelevant from a processing standpoint.

>unclear what value the new sentence adds?

I suppose it would be to limit the processing by the IdP if the RP knows
it's going to throw away the result anyway.

-- Scott

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 28 Feb 2013 07:52:35 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Josh Howlett

> >Other conditions MAY be included as requested by the Relying Party or
> >at the discretion of the Identity Provider.  The Identity Provider is
> >not obligated to honor the requested set of conditions in the
> ><samlp:AuthnRequest>, if any.  If the Identity Provider does not honor
> >the requested set of conditions is MUST either not return a
> ><samlp:Response> message or return a <samlp:Response> message with
> an
> >error.
> 
rather
> than as conditions on the use of the request itself". An assertion that
include
> these conditions can always be discarded by the RP, so I am unclear what
> value the new sentence adds?
> 

To me current text says the following.  The RP says please do this.  The IdP
does not do this.  The IdP returns an assertion.  

How does the RP know that the IdP did not do this.  The new sentences says.
If the IdP is not going to do this - error.

Jim

---

From: Josh Howlett <[email-masked]>
Date: Thu, 28 Feb 2013 16:14:47 +0000

>How does the RP know that the IdP did not do this.

It parses the assertion. The requested conditions are either present, or
not.

These conditions are not instructions to the IdP as to how it should
process the request. They are instructions from the IdP to the SP
describing the circumstances in which the assertion can be considered
valid.

Josh.