Network Working Group T. Melia Internet-Draft Y:. El Mghazli Intended status: Experimental Alcatel-Lucent Expires: August 3, 2009 January 30, 2009 Access Network Service Discovery Function discovery draft-melia-radext-andsf-discovery-extension-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 3, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document specifies extensions to RADIUS to convey to the network authentication server information about the Access Network Discovery Melia & El Mghazli Expires August 3, 2009 [Page 1] Internet-Draft ANDSF discovery January 2009 Service Function. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Scenarios for ANDSF deployment . . . . . . . . . . . . . . . . 3 4. System Components . . . . . . . . . . . . . . . . . . . . . . . 4 5. Radius attributes to carry ANDSF parameters . . . . . . . . . . 5 5.1. ANDSF attribute . . . . . . . . . . . . . . . . . . . . . . 5 5.2. ANDSF Parameter Authenticity Attribute . . . . . . . . . . 6 6. Table of attributes . . . . . . . . . . . . . . . . . . . . . . 7 7. MN considerations . . . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Melia & El Mghazli Expires August 3, 2009 [Page 2] Internet-Draft ANDSF discovery January 2009 1. Introduction The 3GPP standadization body, to optimize non-3GPP network discovery procedures, is currently specifying the Access Network Service Discovery Function. This is a function implemented in the home network for release 8, and in both visited and home network for release 9 of 3GPP specifications. The interface between the mobile device and the ANDSF server is IP based and the MN needs to dynamically discover the IP address or the FQDN of the ANDSF server. This document addresses the case of discovering an ANDSF server either located in the home or visited network where the entity authenticating the mobile node and providing the ANDSF service is the same. We commonly refer to this as integrated scenario (opposed to the split scenario where the entity authenticating the MN in the network and the entity providing the service are different). This document defines new attributes to facilitate ANDSF bootstrapping via a RADIUS infrastructure. In an access network where the user attaches to get IPv6 access, there may be a Network Access Server (NAS) or an Access Gateway that will require authentication and authorization. In some cases, this type of access authentication takes place via RADIUS infrastructure. As part of the authentication setup the NAS may receive useful configuration information from the home RADIUS server of the user. In case of ANDSF the Home RADIUS server may assign various information relevant to the user's device for bootstrapping. 2. Terminology ANDSF It contains data management and control functionality necessary to provide network discovery and selection assistance data as per operators' policy. The ANDSF is able to initiate data transfer to the mobile node, based on network triggers, and respond to requests from the mobile node. The ANDSF provides inter-system mobility policies and access network discovery information. 3. Scenarios for ANDSF deployment Figure 1 provides and insight of the envisioned deployment scenario where ANDSF can be either provided in the home or in the visisted similarly to what specified in [I-D.ietf-mipshop-mstp-solution]. Melia & El Mghazli Expires August 3, 2009 [Page 3] Internet-Draft ANDSF discovery January 2009 +=====+ +--------------+ |ANDSF| | HOME NETWORK | +=====+ +--------------+ /\ ----------------------||------------- \/ +=====+ +-----------------+ |ANDSF| | VISITED NETWORK | +=====+ +-----------------+ /\ || \/ +--------+ | MN | +--------+ Figure 1: ANDSF deployment scenario 4. System Components The following section describes the system behavior as shown in Figure 2. During AAA phase, MN gets authenticated and authorized by the home AAA to get network access. At first MN interacts with the NAS at the visited network, which in turns polls AAA infrastructure to obtain MN access credentials. In this phase, AAA defines which ANDSF the MN can access to (i.e. if the authorized ANDSF are in visited or home and which kind of services are provided). After the successfull authentication and network access authorization, the AAA has provided to the NAS the list of ANSDSF (identified either by a FQDN or their IP address) and the list of service they are able to provide. To support the ANDSF assignment, the NAS MUST be able to provide such MoS related information to some entity communicating witht he mobile node. One possibility to deliver such informatiopn to the MN is the use of the options defined in [I-D.ietf-mipshop-mos-dhcp-options] The definition of such method is however outside the scope of this document. Melia & El Mghazli Expires August 3, 2009 [Page 4] Internet-Draft ANDSF discovery January 2009 Visited | Home | | +-------+ | +-------+ | | | | | |RADIUS |--RADIUS---|--------|RADIUS | |PROXY | | |SERVER | | | | | | +-------+ | +-------+ | | | R | +--------+ | A | | ANDSF | | D | +--------+ | I | +--------+ | U | | ANDSF | | S | +--------+ | | +-----+ | +----+ | | | | MN |------| NAS | | +----+ | | | +-----+ | | ANDSF -- Access Network Discovery Service Function NAS -- Network Access Server Figure 2: MOS Discovery using Network Access Authentication 5. Radius attributes to carry ANDSF parameters This section defines format and syntax for the attribute that carries the ANDSF parameters. 5.1. ANDSF attribute This attribute is sent by the RADIUS server to the NAS in an Access- Accept message. The attribute carries the assigned ANDSF address. Melia & El Mghazli Expires August 3, 2009 [Page 5] Internet-Draft ANDSF discovery January 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | IPv6 address of assigned ANDSF | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: ASSIGNED-ANDSF-TYPE to be defined by IANA. Length: = 20 octets Reserved: Reserved for future use. All bits set to 0 IPv6 address of assigned ANDSF: 128-bit IPv6 address of the assigned ANDSF. 5.2. ANDSF Parameter Authenticity Attribute This attribute is sent by the RADIUS server to the NAS in an Access- Accept message. The attribute carries a authenticator to validate the integrity of the ANDSF parameters that are assigned by the RADIUS server. The authenticator is calculated by taking HMAC-SHA-1 of the all the ANDSF related assigned parameter values and a shared secret that the RADIUS server has for the MN. Melia & El Mghazli Expires August 3, 2009 [Page 6] Internet-Draft ANDSF discovery January 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Authenticator | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: ANDSF-PARM-AUTH-TYPE to be defined by IANA. Length: = 20 octets. Reserved: Reserved for future use. All bits set to 0. Authenticator: HMAC-SHA-1 (shared secret between the MN and the RADIUS, assigned ANDSF values). 6. Table of attributes The following table provides a guide to which attributes may be found in RADIUS message and in what number. Request Accept Reject Challenge # Attribute 0 0-1 0 0 TBD ANDSF 0 0-1 0 0 TBD ANDSF Parameter Authenticity The following table defines the meaning of the above table entries. 0 This attribute MUST NOT be present. 0-1 Zero or one instance of this attribute MAY be present. 7. MN considerations Upon receiving the ANDSF parameters from the network via mechanisms the MN MUST check whether the parameter set contains the ANDSF Parameter Authenticity value. If yes, the MN MUST compute a secure hash as following: Melia & El Mghazli Expires August 3, 2009 [Page 7] Internet-Draft ANDSF discovery January 2009 HMAC-SHA-1 (shared secret between the MN and the RADIUS, received ANDSF values) The MN matchs the output of the above hash with the ANDSF Parameter Authenticity value received from the network. If the values match the MN accept the received ANDSF parameters to be from a trusted source. If the comparison results in a mismatch, the MN MUST silently discard the received ANDSF parameters. If the received ANDSF parameter set does not contain the ANDSF Parameter Authenticity value, the MN MAY accept the received ANDSF parameters. 8. IANA Considerations This document makes no request of IANA. 9. Security Considerations Assignment of these values to a user should be based on successful authentication of the user's access at the NAS. The RADIUS server should only assign these values to an user who is authorized for ANDSF service (this check could be performed with the user's subscription profile in the Home Network). The NAS to the Home RADIUS server transactions must be adequately secured. Otherwise there is a possibility that the user may receive fraudulent values from a rogue RADIUS server potentially hijacking wrong ANDSF information. If the RADIUS server has a shared secret with the MN, the RADIUS server MUST include the ANDSF Parameter Authenticity attribute while assigning other ANDSF bootstrap information to the MN. This enables the MN to verify that the received ANDSF bootstrap information is from a trusted source. These new attributes do not involve additional security considerations besides the one identified in [RFC2865]. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Melia & El Mghazli Expires August 3, 2009 [Page 8] Internet-Draft ANDSF discovery January 2009 10.2. Informative References [I-D.ietf-mipshop-mos-dhcp-options] Bajko, G. and S. Das, "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Server (MoS) discovery", draft-ietf-mipshop-mos-dhcp-options-10 (work in progress), January 2009. [I-D.ietf-mipshop-mstp-solution] Melia, T., Bajko, G., Das, S., Golmie, N., and J. Zuniga, "IEEE 802.21 Mobility Services Framework Design (MSFD)", draft-ietf-mipshop-mstp-solution-11 (work in progress), January 2009. Authors' Addresses Telemaco Melia Alcatel-Lucent Route de Villejust Nozay 91620 France Email: telemaco.melia@alcatel-lucent.com Yacine El Mghazli Alcatel-Lucent Route de Villejust Nozay 91620 France Email: yacine.el_mghazli@alcatel-lucent.com Melia & El Mghazli Expires August 3, 2009 [Page 9]