Re: [abfab] slides for the meetings later today
Alejandro Pérez Méndez <alex@um.es> Mon, 20 July 2015 12:28 UTC
Return-Path: <alex@um.es>
X-Original-To: abfab@ietfa.amsl.com
Delivered-To: abfab@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFF71A8033 for <abfab@ietfa.amsl.com>; Mon, 20 Jul 2015 05:28:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.911
X-Spam-Level:
X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBKx532SnP3n for <abfab@ietfa.amsl.com>; Mon, 20 Jul 2015 05:28:15 -0700 (PDT)
Received: from xenon22.um.es (xenon22.um.es [155.54.212.162]) by ietfa.amsl.com (Postfix) with ESMTP id 55BE81A8032 for <abfab@ietf.org>; Mon, 20 Jul 2015 05:28:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by xenon22.um.es (Postfix) with ESMTP id AD6952B36 for <abfab@ietf.org>; Mon, 20 Jul 2015 14:28:13 +0200 (CEST)
X-Virus-Scanned: by antispam in UMU at xenon22.um.es
Received: from xenon22.um.es ([127.0.0.1]) by localhost (xenon22.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nyclP7NPAlTi for <abfab@ietf.org>; Mon, 20 Jul 2015 14:28:13 +0200 (CEST)
Received: from [192.168.20.112] (186.160.broadband14.iol.cz [90.181.160.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon22.um.es (Postfix) with ESMTPSA id 6B2B82B1E for <abfab@ietf.org>; Mon, 20 Jul 2015 14:28:12 +0200 (CEST)
To: "abfab@ietf.org" <abfab@ietf.org>
References: <55ACB4BD.9060102@mnt.se>
From: Alejandro Pérez Méndez <alex@um.es>
Message-ID: <55ACE95C.1060506@um.es>
Date: Mon, 20 Jul 2015 14:28:12 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <55ACB4BD.9060102@mnt.se>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/abfab/CGz7hs0T3pyqmkuGx6t7yOvbNeM>
Subject: Re: [abfab] slides for the meetings later today
X-BeenThere: abfab@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" <abfab.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/abfab>, <mailto:abfab-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/abfab/>
List-Post: <mailto:abfab@ietf.org>
List-Help: <mailto:abfab-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/abfab>, <mailto:abfab-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jul 2015 12:28:19 -0000
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/fileserver.rp.com@rp.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 > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab
- [abfab] slides for the meetings later today Leif Johansson
- Re: [abfab] slides for the meetings later today Alejandro Pérez Méndez
- Re: [abfab] slides for the meetings later today Sam Hartman
- Re: [abfab] slides for the meetings later today Leif Johansson
- Re: [abfab] slides for the meetings later today Alejandro Pérez Méndez