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

From: [email-masked]
Date: Mon, 12 Mar 2012 04:59:35 -0700

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 and Profiles for SAML
	Author(s)       : Josh Howlett
                          Sam Hartman
	Filename        : draft-ietf-abfab-aaa-saml-03.txt
	Pages           : 15
	Date            : 2012-03-12

   This document specifies a RADIUS attribute, a binding and two
   profiles for the Security Assertion Mark-up Language (SAML).  The
   attribute provides RADIUS encapsulation of SAML protocol messages,
   while the binding describes the transport of this attribute, and the
   SAML protocol messages within, using RADIUS.  The profiles describe
   the application of this binding for Abfab authentication and
   assertion query/request.  The SAML RADIUS attribute and binding are
   defined generically to permit application in other scenarios, such as
   network access.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-abfab-aaa-saml-03.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-abfab-aaa-saml-03.txt

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 14 Mar 2012 22:39:23 -0700

Comments on the current version of the document.

First let me say that overall I am very happy with the state of this
document.  It is slightly repetitive, but is very clear about what happens
when and where.  I believe that I now have a clear understanding of how I
would go about using SAML statements in Plasma by starting with using the
Authentication Profile and then following it up with generic queries using
the identity that was returned in the Authentication response.

Jim

Major

1.  Do we have any other examples where we might have a SAML
requester/responder other than the case of the RP/IdP?  If so, it might be
wise to mention at least one other case in the introductory paragraph in
section 1.  Otherwise it might be easier to just say that we are sending
messages between the RP and the IdP and not generalize it.  Can anybody see
a reason that one might want to reverse the endpoints?  So that the RP
becomes the server and the IdP the client???

2. In section 3, I would suggest adding the text "There MUST be at most one
SAML-Message Attribute in either a RADIUS request or response message."

3.  In section 4.1 and 5.1, the Identification will require an IANA action.
I think we are looking at urn:ietf:params:xml:ns:abfab:<something goes here>
I think that something probably looks like SAML:binding:RADIUS-binding in
section 4.1.  The contact information should be [email-masked].  I don't see
any requirement that the binding should be specific to the RADIUS transport
- do you?

4.  In section 4.2 item #2 - If the SAML responder is going to response to a
SAML request, is there a requirement that the responder MUST response no
later than the Access-Accept or Access-Reject message?  Also what other
currently defined packets is the element permitted in - for example can I
include it in an Access-Challenge packet?

5.  In section 5.2 - Section on Responses: - I am confused when I read this
text.  It first says that you must return exactly one authentication
statement.  It then says that the IdP can return other statements in the
assertion.  Are these other assertions allowed to be authentication
statements or are they some other type of statement?  

6.  The last sentence in section 5.2 makes no sense to me.    I believe the
sentence should finish "to a Relying Part without step 2 occurring."  Doing
it without having the EAP protocol run in section 3 would be bad news.
Ditto the last paragraph in section 5.3 - I think it should just say that
"The Request in section 5.3.2 is omitted from the process."

7.  In section 5.3.4 - I would like to see a statement that in this profile,
if the <samlp:AuthnRequest> is marked as fail then the EAP should also
return fail.  That is there should not be difference in the returned value
for the SAML request and the EAP dialog.

8.  In section 5.4.1 paragraph 3 - I am not sure how this section interacts
with the ability of an IdP to return a Pseudonymous identifier.  Are you
stating that the identifier must already exist, or just that the policy for
creating the identifier must already exist in the case AllowCreate is set to
"false".  

9.  In section 5.4.1 last paragraph - I think we should make some type of
statement about what happens if either the request is not signed, or the
signature on the request cannot be validated by the IdP.  I think that both
of these cases are going to be more likely that the case of it is signed and
the IdP happens to be able to validate the signature.

10.  I believe that a discussion of what is expected to happen as these
messages cross federation boundaries is probably in order.

Nits

1.  We need to get a consistent method of doing Abfab or ABFAB.  I have
always used all upper case, this document is doing mixed case.  We should be
consistent and I think the all upper case is the normal way.  Please change.

2.  I object to the capitalization in the following sentence "The NAI SHOULD
be used to route the
       message towards the SAML responder, which MAY be more than one
       RADIUS hop distant."  How are these requirements on the binding that
is being produced?  Are these not intrinsic properties that are true just by
saying that we are using RAIDUS?

3. There is an extraneous period in the last sentence of section 5.3.3

4.  Bad grammar /confirmation as the processing as defined in/  I don't know
what this should be.

5.  Please add http links to your SAML references so I don't have to search
for them - I am very lazy.

6.  Can we move some of the references out of normative?  For example I
think that 3575 could be informative since it affects only the document
writer and not the implementer.    The same is probably true for some of the
other references.

s/reponse/response/
s/Consequently here exists/Consequently there exists/
s/unsolicited responser/unsolicited response/
s/disgression/discretion/

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 15 Mar 2012 09:05:15 +0100

> SAML-Message Attribute in either a RADIUS request or response message."

It is almost impossible to fit a entire SAML message into a single 
SAML-Message attribute (253 bytes), so almost always there will be more 
than on SAML-Message attribute in both, RADIUS requests and responses 
when transporting SAML data. All these attributes are part of the same 
extended fragmented attribute, but section 3 is talking about the basic 
RADIUS attribute. Note that this draft has not yet adopted extended 
attributes format.

If your intention was to suggest that no more than 1 SAML Message MUST 
be included per RADIUS packet, I'm not sure to agree either. At least, I 
do not see a clear motivation for such limitation.

> include it in an Access-Challenge packet?

That's an interesting question. In a previous discussion we were 
thinking on moving all the authorization data retrieval exchanges 
_after_ the Access-Accept exchange. I think Josh already shown interest 
on changing to that kind of flow, though I guess until 
radius-fragmentation draft moves a little forward this need to be hold on.

The basic idea would be to perform the EAP authentication without SAML 
exchanges. Within the Access-Accept, the RADIUS server provides a State 
attribute and the service-type would be Authorize-Only, indicationg 
further authorization need to be performed. Then the RP sends the SAML 
Authn Req and the IdP provides the SAML Assertion. This way both 
authentication and attribute retrieval follow the same exchange pattern.

> statements or are they some other type of statement?

Other type of statement, for example, attribute statement.

> if the<samlp:AuthnRequest>  is marked as fail then the EAP should also

IMO this is not required. EAP is meant to provide authentication, while 
SAML is intended to provide authorization. A principal may be succesfuly 
authenticated, but fail to obtain authorization information. One process 
should not interfere in the other. Think that a RP may not issue the 
AuthnReq. Besides, if the RADIUS server and the IdP are not collocated, 
I do not think it is a good idea to trick the EAP stack in the RADIUS 
server to force an EAP failure if the IdP replies with an SAML error.

> the IdP happens to be able to validate the signature.

I think a general statement must be included saying that if SAML 
messages/assertion are not singed, authenticity and integrity protection 
are implicitly provided by the AAA infrastructure. If signatures are 
provided, they have precedence.

> consistent and I think the all upper case is the normal way.  Please change.
Agree

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 15 Mar 2012 08:52:05 -0400

>>>>> "Alejandro" == Alejandro Perez Mendez <[email-masked]> writes:

 item #2 - If the SAML responder is going to
    >> response to a SAML request, is there a requirement that the
    >> responder MUST response no later than the Access-Accept or
    >> Access-Reject message?  Also what other currently defined packets
    >> is the element permitted in - for example can I include it in an
    >> Access-Challenge packet?

    Alejandro> That's an interesting question. In a previous discussion
    Alejandro> we were thinking on moving all the authorization data
    Alejandro> retrieval exchanges _after_ the Access-Accept exchange. I
    Alejandro> think Josh already shown interest on changing to that
    Alejandro> kind of flow, though I guess until radius-fragmentation
    Alejandro> draft moves a little forward this need to be hold on.

I do not support moving to that flow all the time.
I think if the message fits in the access-accept it should be sent
there.
Also true for access-reject.

    >> 
    >> 6.  The last sentence in section 5.2 makes no sense to me.  I
    >> believe the sentence should finish "to a Relying Part without
    >> step 2 occurring."  Doing it without having the EAP protocol run
    >> in section 3 would be bad news.  Ditto the last paragraph in
    >> section 5.3 - I think it should just say that "The Request in
    >> section 5.3.2 is omitted from the process."
    >> 
    >> 7.  In section 5.3.4 - I would like to see a statement that in
    >> this profile, if the<samlp:AuthnRequest> is marked as fail then
    >> the EAP should also return fail.  That is there should not be
    >> difference in the returned value for the SAML request and the EAP
    >> dialog.

    Alejandro> IMO this is not required. EAP is meant to provide
    Alejandro> authentication, while SAML is intended to provide
    Alejandro> authorization. A principal may be succesfuly
    Alejandro> authenticated, but fail to obtain authorization
    Alejandro> information. One process should not interfere in the
    Alejandro> other. Think that a RP may not issue the
    Alejandro> AuthnReq. Besides, if the RADIUS server and the IdP are
    Alejandro> not collocated, I do not think it is a good idea to trick
    Alejandro> the EAP stack in the RADIUS server to force an EAP
    Alejandro> failure if the IdP replies with an SAML error.

Typically a RADIUS access-accept implies both authorization and
authentication.

I don't particularly care if the saml and EAP results are consistent,
but I don't think it's appropriate to include a SAML failure in an
access accept.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 15 Mar 2012 14:07:10 +0100

El 15/03/12 13:52, Sam Hartman escribió:
>>>>>> "Alejandro" == Alejandro Perez Mendez<[email-masked]>  writes:

I didn't mean that a RADIUS Access-Accept should be sent if a SAML 
failure occurs. I was just talking about EAP, not RADIUS.

I mean, we are using RADIUS to transport both EAP and SAML. If the 
conjunction of a SAML failure and a EAP success should have the result 
of denial of access (because of the failure in the authorization), then 
an Access-Reject should be sent. Now, I have to admint that I don't 
really know if it is possible to send an EAP-Success packet within an 
Access-Reject RADIUS message. But tricking the EAP stack to force the 
EAP method to fail even when the method was actually successful does not 
sound very well either. What do you think?

Regards,
Alejandro

---

From: Sam Hartman <[email-masked]>
Date: Thu, 15 Mar 2012 10:28:30 -0400

>>>>> "Alejandro" == Alejandro Perez Mendez <[email-masked]> writes:

I think we're in general agreement.

    Alejandro> I mean, we are using RADIUS to transport both EAP and
    Alejandro> SAML. If the conjunction of a SAML failure and a EAP
    Alejandro> success should have the result of denial of access
    Alejandro> (because of the failure in the authorization), then an
    Alejandro> Access-Reject should be sent. Now, I have to admint that
    Alejandro> I don't really know if it is possible to send an
    Alejandro> EAP-Success packet within an Access-Reject RADIUS
    Alejandro> message. But tricking the EAP stack to force the EAP
    Alejandro> method to fail even when the method was actually
    Alejandro> successful does not sound very well either. What do you
    Alejandro> think?

In this case my preference would be to send no EAP message back at all
but only to send an access-reject possibly with the SAML failure.

--Sam

---

From: Gabriel López <[email-masked]>
Date: Thu, 15 Mar 2012 15:33:13 +0100

> but only to send an access-reject possibly with the SAML failure.
I agree

Regards, Gabi.

-- 
----------------------------------------------------------------
Gabriel Lpez Milln
Departamento de Ingeniera de la Informacin y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [email-masked]

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 15 Mar 2012 14:57:47 +0000

> messages between the RP and the IdP and not generalize it.  Can anybody
> see a reason that one might want to reverse the endpoints?  So that the RP

Any binding should be left generically defined as SAML requester and responder, even if you don't specifically have a use case to hand. It's just the right layering. But aside from that, I can at least point to some protocols that could be useful and would reverse the flows. NameID mgmt, ID mapping, and the Oracle Change-Notify proposal would all be possible flows that reverse the roles.

But whether that's possible in ABFAB I don't know.

> creating the identifier must already exist in the case AllowCreate is set to

That text is probably somewhat ill-advised. It most likely got copied from the original browser SSO profile, and I never wanted it there either. It's repeating SAML core rules, and I don't like repeating spec language. But to answer your question, for more ill-advised reasons, there's a flag in SAML with a very poor default that's used to specifically limit the IdP from manufacturing an identifier for a user if the identifier doesn't already exist. If AllowCreate is false, the IdP is supposed to fail rather than mint new state between itself and the SP.
 
-- Scott

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 15 Mar 2012 15:59:22 +0100

>> but only to send an access-reject possibly with the SAML failure.

I think that is a reasonable solution.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 15 Mar 2012 11:32:00 -0400

>>>>> "Cantor," == Cantor, Scott <[email-masked]> writes:

    >> requester/responder other than the case of the RP/IdP?  If so, it
    >> might be wise to mention at least one other case in the
    >> introductory paragraph in section 1.  Otherwise it might be
    >> easier to just say that we are sending messages between the RP
    >> and the IdP and not generalize it.  Can anybody see a reason that
    >> one might want to reverse the endpoints?  So that the RP becomes
    >> the server and the IdP the client???

    Cantor,> Any binding should be left generically defined as SAML
    Cantor,> requester and responder, even if you don't specifically
    Cantor,> have a use case to hand. It's just the right layering. 

Conceptually I agree that defining things in terms of requester and
responder are desirable.
If we do that, thought, it seems like we need to describe how to
identify and route things at the AAA layer.
Routing to IDP associated with that AAA server is easy.
However going beyond that is tricky at the RADIUS layer.

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 15 Mar 2012 08:59:05 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Alejandro Perez Mendez
> Sent: Thursday, March 15, 2012 1:05 AM
> To: [email-masked]
> Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt
> 
> 
> > document.  It is slightly repetitive, but is very clear about what
> > happens when and where.  I believe that I now have a clear
> > understanding of how I would go about using SAML statements in Plasma
> > by starting with using the Authentication Profile and then following
> > it up with generic queries using the identity that was returned in the
> Authentication response.
> >
> > Jim
> >
> >
> > Major
> >
> > might be wise to mention at least one other case in the introductory
> > paragraph in section 1.  Otherwise it might be easier to just say that
> > we are sending messages between the RP and the IdP and not generalize
> > it.  Can anybody see a reason that one might want to reverse the
> > endpoints?  So that the RP becomes the server and the IdP the client???
> >
> > 2. In section 3, I would suggest adding the text "There MUST be at
> > most one SAML-Message Attribute in either a RADIUS request or response
> message."
> 
> It is almost impossible to fit a entire SAML message into a single SAML-
> Message attribute (253 bytes), so almost always there will be more than on
> SAML-Message attribute in both, RADIUS requests and responses when
> transporting SAML data. All these attributes are part of the same extended
> fragmented attribute, but section 3 is talking about the basic RADIUS
> attribute. Note that this draft has not yet adopted extended attributes
> format.
> 
do not
> see a clear motivation for such limitation.

My intent was to say that there was at most one SAML Assertion in a RADIUS
request or response message.  If this is not true then we need to find a way
to say that assertion #1 has ended and we are now dealing with assertion #2.

> Other type of statement, for example, attribute statement.

Ok the text could be clearer.

> server to force an EAP failure if the IdP replies with an SAML error.

Allowing for different answers makes more sense if the flow changes as
above.  Otherwise I don't see that this is necessarily true.  We have
already stated that the AuthnRequest can and should in some cases affect how
the EAP is performed.  Are you talking about failing because you are not
going to return some attributes or because you are going to say that yes I
know who they are, but they are not supposed to talk to you.  In this case
ABFAB has already said you are supposed to fail the EAP conversation as
well.  Under what circumstances do you think this would occur.

> > always used all upper case, this document is doing mixed case.  We
should
> be

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 15 Mar 2012 12:48:44 -0700

> From: Cantor, Scott [mailto:[email-masked]]
> Sent: Thursday, March 15, 2012 7:58 AM
> To: Jim Schaad; Sam Hartman; [email-masked]
> Cc: [email-masked]
> Subject: RE: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt
> 
> Any binding should be left generically defined as SAML requester and
> responder, even if you don't specifically have a use case to hand. It's
just the
> right layering. But aside from that, I can at least point to some
protocols that
> could be useful and would reverse the flows. NameID mgmt, ID mapping,
> and the Oracle Change-Notify proposal would all be possible flows that
> reverse the roles.
> 
> > 8.  In section 5.4.1 paragraph 3 - I am not sure how this section
> > interacts with the ability of an IdP to return a Pseudonymous
> > identifier.  Are you stating that the identifier must already exist,
> > or just that the policy for creating the identifier must already exist
> > in the case AllowCreate is set to "false".
> 
> That text is probably somewhat ill-advised. It most likely got copied from
the
> original browser SSO profile, and I never wanted it there either. It's
repeating
> SAML core rules, and I don't like repeating spec language. But to answer
your
> question, for more ill-advised reasons, there's a flag in SAML with a very
poor
> default that's used to specifically limit the IdP from manufacturing an
> identifier for a user if the identifier doesn't already exist. If
AllowCreate is
> false, the IdP is supposed to fail rather than mint new state between
itself
> and the SP.

Based on this would you be in favor of adding the statement that AllowCreate
SHOULD be set to true?

Jim

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 15 Mar 2012 20:57:32 +0000

> Based on this would you be in favor of adding the statement that
> AllowCreate SHOULD be set to true?

I wouldn't be against it particularly, but we've treated that more as a deployment profile sort of thing, rather than something to bake into technical profiles for software to implement.

-- Scott

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Fri, 16 Mar 2012 08:54:12 +0100

> to say that assertion #1 has ended and we are now dealing with assertion #2.

Extended attributes already deal with this situation thanks to the M 
flag. Last fragment of an attribute is not marked with M flag. Hence you 
know when SAML message #1 ends, and thus a different one starts if you 
find another SAML-Message attribute. that

> well.  Under what circumstances do you think this would occur.

I think this has already been solved by Sam in a previous message.

Regards,
Alejandro

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 16 Mar 2012 13:09:19 +0100

Hi all:

Just one comment. In RFC 3579 (section 2.6.3), there is text about conflicting messages.
 
I believe we are discussing these two cases:

Access-Reject/EAP-Message/EAP Success
Access-Reject/no EAP-Message attribute (or even Access-Reject/EAP-Start being EAP-Start an empty EAP attribute)

These cases are NOT recommended in that section. Reasoning is given in the text and are different for each case:

For the Access-Reject/EAP-Message/EAP Success case:

"For example, if the NAS receives an Access-Reject with an
   encapsulated EAP Success, it will not grant access to the peer.
   However, on receiving the EAP Success, the peer will be lead to
   believe that it authenticated successfully."

For Access-Reject/no EAP-Message attribute

"If no EAP-Message attribute is included within an
   Access-Accept or Access-Reject, then the peer may not be informed as
   to the outcome of the authentication, while the NAS will take action
   to allow or deny access."

However I believe that, with GSS-EAP, these cases (and the consequent confusion) could be easily solved. When the acceptor receives an Access-Reject it should inform the initiator about an authorization problem. This could be done by defining an error code Authorization failed in GSS-EAP (maybe existing error codes could be used for that). In other words, as long as the initiator does not get confused , then both cases are ok.

Personally, I would send a GSS token with the EAP Success and the error code Authorization failed to the initiator. This would allow the initiator to know that authentication was ok but authorization failed. Thus, the initiator does not get confused at all about what happened. 

Also, some insights from RADIUS server developers are important so that we can see how RADIUS server typically do (e.g. whether they allow Access-Reject/EAP-Message/EAP Success or Access-Reject/no EAP-Message attribute)
 
My 0.02 cents.

> but only to send an access-reject possibly with the SAML failure.

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Sam Hartman <[email-masked]>
Date: Fri, 16 Mar 2012 10:51:14 -0400

>>>>> "Rafa" == Rafa Marin Lopez <[email-masked]> writes:

    Rafa> Personally, I would send a GSS token with the EAP Success and
    Rafa> the error code Authorization failed to the initiator. This
    Rafa> would allow the initiator to know that authentication was ok
    Rafa> but authorization failed. Thus, the initiator does not get
    Rafa> confused at all about what happened.

I'd just send the error.
EAP success doesn't actually allow you to know much of anything because
it's pnot integrity-protected from the EAP server.
You need to send it in success cases so the state machines are in sync.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 16 Mar 2012 16:01:47 +0100

Hi Sam: 

> it's pnot integrity-protected from the EAP server.

It is just a matter to be coherent with each part. If the EAP authentication is successful why do not to state so?

> You need to send it in success cases so the state machines are in sync.

Precisely because of that, I believe EAP success should reach the EAP peer state machine. If the authentication is succesful the EAP success should reach the EAP state machine to move it to the final state. And if the authorization is not, the error code Authorization fail is sent in the GSS-EAP.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 16 Mar 2012 11:45:44 -0400

>> 
    >> I'd just send the error.  EAP success doesn't actually allow you
    >> to know much of anything because it's pnot integrity-protected
    >> from the EAP server.

    Rafa> It is just a matter to be coherent with each part. If the EAP
    Rafa> authentication is successful why do not to state so?

Because it's none of the peer's business whether the access is being
denied for an authorization or authentication reason.  Also, peers have
to be able to deal with the case where the EAP message is absent, so
that code path is going to be better tested.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 16 Mar 2012 17:37:17 +0100

Hi Sam:
> denied for an authorization or authentication reason.

Not sure if I agree with that in all use cases... 

>  Also, peers have

Following that reasoning, perhaps we should consider both options since they may be both possible. If the EAP server sends the EAP success ("Access-Reject/EAP-Message/EAP Success" case) I think the acceptor should not remove the EAP success and send it to the initiator. In fact, the acceptor as EAP authenticator should not care about what the EAP server is sending to the EAP peer, and just paying attention to what the AAA server is sending to the acceptor via AAA protocol. If we have "Access-Reject/no EAP-Message attribute" case the initiator will not receive the EAP success. But this is not problematic either, due to the initiator can send an AltReject to the EAP peer state machine (due to Authorization failed error code is set) to stop it and inform about such situation.

In conclusion, if you think that by not sending the EAP success to the initiator will simplify implementations, that is fine with me. Although it would be interesting to know if existing RADIUS server implementations will support any of the cases :).

Best regards.