Subject: [abfab] Proposal for post-authentication attribute request

From: Josh Howlett <[email-masked]>
Date: Tue, 5 Feb 2013 16:33:05 +0000

Jim has previously articulated a requirement for support of
post-authentication attribute request, and to allow requests for
attributes of the user and/or machine associated with the authentication.
In a call before Christmas, Scott suggested a strategy based on the use of
SAML Subject Confirmation.

The idea is that the SAML Requester can use an attribute request using a
new SAML Subject Confirmation Method. This Method gives (1) the value of
the RADIUS State attribute pointing to the RADIUS session in question and
(2) whether the response should include attributes describing the user or
machine.

Here's the proposed text:

8.  RADIUS State Confirmation Method

   URI: urn:ietf:params:xml:ns:abfab:cm:radius-state

   The RADIUS State Confirmation Method indicates that the Subject is
   the system entity associated with a RADIUS Access-Accept message,
   identified by the value of the RADIUS message's State attribute.

   There are typically two types of system entity associated with a
   RADIUS authentication: a user or a machine.  This Confirmation Method
   uses the Identity-Type TLV defined by
   [I-D.ietf-emu-eap-tunnel-method] to permit disambiguation.  This
   allows, for example, a SAML Requester to request attributes for a
   user, even if machine credentials were used in the original RADIUS
   authentication.

   Define an XML attribute ("RadiusStateValue") giving the RADIUS State
attribute value

   Define an XML attribute ("RadiusIdentityType") giving the Identity-Type
TLV value

  <SubjectConfirmation
    Method="urn:ietf:params:xml:ns:abfab:cm:radius-state">
      <SubjectConfirmationData RadiusStateValue="ABC123"
RadiusIdentityType="1" />
  </SubjectConfirmation>

While working through this, I spotted a bug in the proposed ABFAB
Assertion Query Profile in that it needs to specify a value for the RADIUS
User-Name attribute which MUST accompany the SAML-Message attribute (per
RFC2865). My view is that the user portion of the NAI in the User-Name
attribute should take a well-known value for different types of SAML
endpoints. For example, the attribute authority for RADIUS realm FOO could
be named as saml2-attribute-authority@foo. SAML tends to use URIs to name
such things, and so one option to improve consistency (at the expense of
verbosity) is to use the aaa: and/or aaas: URI schemes defined by Diameter
(but which also supports naming RADIUS endpoints).

Comments welcome...

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: "Jim Schaad" <[email-masked]>
Date: Tue, 5 Feb 2013 14:01:39 -0600

Josh,

I am not sure why you think that the RADIUS state variable needs to be put
into the SAML and not just in the RADIUS message that is carrying the SAML
request.  Can you elaborate?

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Josh Howlett
> Sent: Tuesday, February 05, 2013 10:33 AM
> To: [email-masked]
> Subject: [abfab] Proposal for post-authentication attribute request
> 
> Jim has previously articulated a requirement for support of post-
> authentication attribute request, and to allow requests for attributes of
the
> user and/or machine associated with the authentication.
Assertion
> Query Profile in that it needs to specify a value for the RADIUS User-Name
> attribute which MUST accompany the SAML-Message attribute (per
> be named as saml2-attribute-authority@foo. SAML tends to use URIs to
> name such things, and so one option to improve consistency (at the expense
> of
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
> 
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Gabriel Lopez <[email-masked]>
Date: Wed, 06 Feb 2013 10:34:57 +0100

> the RADIUS State attribute pointing to the RADIUS session in question and

Do we have to take into account the scenario where the idP is not
co-located with the Radius server?
In this case this method is not valid.
> (2) whether the response should include attributes describing the user or
Using the current SAML AttributeQuery element the client can specify the
list of desired attributes. Is it not enough to specify the set of
attributes (user/machine) in the same query identified by urn?

Regards, Gabi.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 06 Feb 2013 09:49:38 +0000

I don't see why a radius server couldn't communicate the state attri ute to an idp.
The same attribute may apply to user and machine with different values.z

Gabriel Lopez <[email-masked]> wrote:

>name

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

---

From: Gabriel Lopez <[email-masked]>
Date: Wed, 06 Feb 2013 15:00:58 +0100

> I don't see why a radius server couldn't communicate the state attri
Does the idp understand this attribute? I mean, the idp could understand
the user-name, but I'm not sure if the state attribute....

regards, Gabi.
>         post-authentication attribute request, and to allow requests
>         for attributes of the user and/or machine associated with the
>         authentication. In a call before Christmas, Scott suggested a
>         strategy based on the use of SAML Subject Confirmation. The
>         idea is that the SAML Requester can use an attribute request
>         using a new SAML Subject Confirmation Method. This Method
>         gives (1) the value of the RADIUS State attribute pointing to
>         the RADIUS session in question and
>
>
>         (2) whether the response should include attributes describing
>         the user or machine. 
>
>         Here's the proposed text: 8. RADIUS State Confirmation Method
>         URI: urn:ietf:params:xml:ns:abfab:cm:radius-state The RADIUS
>         State Confirmation Method indicates that the Subject is the
>         system entity associated with a RADIUS Access-Accept message,
>         identified by the value of the RADIUS message's State
>         attribute. There are typically two types o f system entity
>         associated with a RADIUS authentication: a user or a machine.
>         This Confirmation Method uses the Identity-Type TLV defined by
>         [I-D.ietf-emu-eap-tunnel-method] to permit disambiguation.
>         This allows, for example, a SAML Requester to request
>         attributes for a user, even if machine credentials were used
>         in the original RADIUS authentication. Define an XML attribute
>         ("RadiusStateValue") giving the RADIUS State attribute value
>         Define an XML attribute ("RadiusIdentityType") giving the
>         Identity-Type TLV value <SubjectConfirmation
>         RadiusIdentityType="1" /> </SubjectConfirmation> While working
>         through this, I spotted a bug in the proposed ABFAB Assertion
>         Query Profile in that it needs to specify a value for the
>         RADIUS User-Name attr ibute which MUST accompany the
>         SAML-Message attribute (per RFC2865). My view is that the user
>         portion of the NAI in the User-Name attribute should take a
>         well-known value for different types of SAML endpoints. For
>         example, the attribute authority for RADIUS realm FOO could be
>         named as saml2-attribute-authority@foo. SAML tends to use URIs
>         to name such things, and so one option to improve consistency
>         (at the expense of verbosity) is to use the aaa: and/or aaas:
>         URI schemes defined by Diameter (but which also supports
>         naming RADIUS endpoints). Comments welcome... 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
>         ------------------------------------------------------------------------
>         abfab mailing list abfab@ietf .org
>     ------------------------------------------------------------------------
>
>     abfab mailing list
>     [email-masked]

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 6 Feb 2013 15:10:34 +0000

> (2) whether the response should include attributes describing the user or

Wouldn't one assume that absent this subject confirmation, the query was about the subject (the user)?

>    Define an XML attribute ("RadiusIdentityType") giving the Identity-Type

You can do that, but they'll have to be namespace qualified, the wildcard in the schema requires namespace="##other", which doesn't permit unqualified attributes.

-- Scott