Re: [abfab] slides for the meetings later today

[Alejandro Pérez Méndez <[e-mail]>]

Hi,

one of the key issues we have with draft-ietf-abfab-aaa-saml is the 
binding/mapping between SAML names and AAA names.
I have a proposal, consisting on the definition of two new 
RoleDescriptor subtypes: RADIUSIDPDescriptor and RADIUSIDPDescriptor, 
and the definition of a way to represent
AAA names as URIs.

You can find the complete text for the proposal at the end of this mail.

Regards,
Alejandro


4.3.3.  Mapping of AAA names in SAML metadata

    This section defines the extensions to the SAML metadata
    specification [OASIS.saml-metadata-2.0-os] that are required in order
    to represent AAA names associated to a particular <EntityDescriptor>
    element.

    In SAML metadata, each single entity may act in many different roles
    in the support of multiple profiles.  This document defines two new
    roles: RADIUS IDP and RADIUS RP, requiring the declaration of two new
    subtypes of RoleDescriptorType: RADIUSIDPDescriptor and
    RADIUSRPDescriptor.

4.3.3.1.  <RADIUSIDPDescriptor>

    The <RADIUSIDPDescriptor> element extends RoleDescriptorType with
    with elements common to IdPs that support RADIUS, and contains the
    following additional elements:

    <RADIUSIDPService> [Zero or More]  Zero or more elements of type
       EndpointType that describe RADIUS endpoints that are associated to
       this Entity.  The Binding attribute MUST be set to
       "urn:ietf:params:abfab:bindings:radius", whereas the
       ResponseLocation attribute MUST be omitted.

    The following schema fragment defines the <RADIUSIDPDescriptor>
    element and its RADIUSIDPDescriptorType complex type:

       <element name="RADIUSIDPDescriptor"
                type="md:RADIUSIDPDescriptorType"/>
           <complexType name="RADIUSIDPDescriptorType">
               <complexContent>
                   <extension base="md:RoleDescriptorType">
                       <sequence>
                           <element ref="md:RADIUSIDPService"
                                    minOccurs="0" maxOccurs="unbounded"/>
                       </sequence>
                   </extension>
               </complexContent>
           </complexType>
       <element name="RADIUSIDPService" type="md:EndpointType"/>

                    Figure 3: RADIUSIDPDescriptor schema

4.3.3.2.  <RADIUSRPDescriptor>

    The <RADIUSRPDescriptor> element extends RoleDescriptorType with with
    elements common to RPs that support RADIUS, and contains the
    following additional elements:

    <RADIUSRPService> [Zero or More]  Zero or more elements of type
       EndpointType that describe RADIUS endpoints that are associated to
       this Entity.  The Binding attribute MUST be set to
       "urn:ietf:params:abfab:bindings:radius", whereas the
       ResponseLocation attribute MUST be omitted.

    The following schema fragment defines the <RADIUSRPDescriptor>
    element and its RADIUSRPDescriptorType complex type:

       <element name="RADIUSRPDescriptor"
                type="md:RADIUSRPDescriptorType"/>
           <complexType name="RADIUSRPDescriptorType">
               <complexContent>
                   <extension base="md:RoleDescriptorType">
                       <sequence>
                           <element ref="md:RADIUSRPService"
                                    minOccurs="0" maxOccurs="unbounded"/>
                       </sequence>
                   </extension>
               </complexContent>
           </complexType>
       <element name="RADIUSRPService" type="md:EndpointType"/>

                     Figure 4: RADIUSRPDescriptor schema


4.3.4.  URI representation of RADIUS names

    The Location attribute of the RADIUSIDPService and RADIUSRPService
    EndPointTypes is defined as a URI.  However, RADIUS does not identify
    the peers using this format, but based on the values of a set of
    RADIUS attributes.  This section describes how the value of these
    attributes can be represented into the URI form.

4.3.4.1.  Representation of RP name

    [RFC2865] defines the NAS-IP-Address and NAS-Identifier attributes,
    that are used to provide simplistic information about the RP's
    identity.  In particular, while the former provides information about
    the RP's IP address, the latter provides a textual identifier for the
    RP.  However, for some deployments this information is not enough,
    and more descriptive one is required.  For instance, this is the case
    of ABFAB and its GSS-EAP mechanism (RFC 7055), where a set of four
    attributes are used to convey the RP's full name information.

    This section provides a URI representation for these three
    identifiers, although the ABFAB one is preferred whenever the
    required RADIUS attributes are available:

    o  "radius:rp:nas-ip-address:{ip_address}", where {ip_address} is the
       textual representation of the IP address to be matched with the
       value of the NAS-IP-Address RADIUS attribute.

    o  "radius:rp:nas-identifier:{identifier}", where {identifier} is the
       textual value to be matched with the value of the NAS-Identifier
       RADIUS attribute.

    o  "radius:rp:gss-eap:{identifier}", where {identifier} is the
       textual value resulting after reconstructing the acceptor service
       name after the reception of the GSS-Acceptor-Service-Name, GSS-
       Acceptor-Host-Name, GSS-Acceptor-Service-Specifics, and GSS-
       Acceptor-Realm-Name RADIUS attributes, as described in section 3.4
       of [RFC7055].  Note that this representation might require the use
       of the "percent-encoding" to incorporate the required "/" and "@"
       into the {identifier} value.

4.3.4.2.  Representation of IDP name

    In RADIUS there is not an attribute used for identifying the IDP.
    However, for the binding and profiles described in this document, it
    is assumed that the realm part of the user's NAI uniquely names the
    IDP.  This realm can be extracted from the User-Name RADIUS attribute
    at any moment of the authentication process.  Therefore, The proposed
    URI representation for the IDP would be:

    o  "radius:idp:{realm}", where {realm} is the textual value to be
       matched with the realm of the user's NAI.

4.3.5.  Example of SAML metadata

    The following examples illustrate how to define metadata on both
    sides, RP and IDP.  The RP SAML name is "https://RelyingParty.com/
    SAML", while its ABFAB name is "nfs/[e-mail]".com".  The
    IDP SAML name is "https://IdentityProvider.com/", while its RADIUS
    realm is "idp.com".

      <EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
entityID="https://IdentityProvider.com/SAML">
          <RADIUSIDPDescriptor protocolSupportEnumeration=
"urn:oasis:names:tc:SAML:2.0:protocol">
              <RADIUSIDPService
Binding="urn:ietf:params:abfab:bindings:radius"
                  Location="radius:idp:idp.com"/>
          </RADIUSIDPDescriptor>
      </EntityDescriptor>

                        Figure 5: Metadata on the RP

     <EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
entityID="https://RelyingParty.com/SAML">
         <RADIUSRPDescriptor protocolSupportEnumeration=
"urn:oasis:names:tc:SAML:2.0:protocol">
             <RADIUSRPService
Binding="urn:ietf:params:abfab:bindings:radius"
Location="radius:rp:gss-eap:nfs%2Ffileserver.rp.com%40rp.com"/>
         </RADIUSRPDescriptor>
     </EntityDescriptor>

                        Figure 6: Metadata on the IDP

El 20/07/15 a las 10:43, Leif Johansson escribió:
> If anyone wants to show any slides at the meeting in Prague, please send
> them to me asap.
>
> 	Cheers Leif
>
> _______________________________________________
> abfab mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/abfab