Network Working Group M. Nakhjiri Internet-Draft Huawei USA Intended status: Standards Track C. Wan, Ed. Expires: July 22, 2007 Huawei Technologies January 18, 2007 A Network Service Identifier for separation of Mobile IPv6 service authorization from Mobile node authentication draft-nakhjiri-dime-mip6-nsi-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 July 22, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Dime working group is designing a procedure for bootstrapping Mobile IPv6 using Diameter. In order to reduce the complexity of Diameter Mobile IPv6 application, the process of Mobile IPv6 service authorization is being separated from the initial mobile node authentication. This This allows for outsourcing the authentication process to another application such as Diameter EAP[RFC4072] . The Nakhjiri & Wan Expires July 22, 2007 [Page 1] Internet-Draft NSI January 2007 process can have security considerations, if the authorizing server does not have a clear assurance that the MN has actually been authenticated before, especially if the authorizing server is different from the authenticating server. In this document we provide a procedure and number of extensions to Mobile IPv6 and Diameter signaling to address those considerations. Specifically a new Network Service Identifier (NSI) is defined to assist the interaction between the authorizing and authenticating procedures and servers. Table of Contents 1. Introduction and problem statement . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Proposed solution: Use of Network Service Identifier . . . . . 6 4. messaging procedure . . . . . . . . . . . . . . . . . . . . . 8 5. key management . . . . . . . . . . . . . . . . . . . . . . . . 10 6. MN_MIP6_Authorization_option: the NSI extension for Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Diameter considerations and AVPs . . . . . . . . . . . . . . . 13 7.1. MN_MIP6_NSI AVP . . . . . . . . . . . . . . . . . . . . . 13 7.2. MN_MIP6_AUTH_ID AVP . . . . . . . . . . . . . . . . . . . 14 7.3. MIP6_Usage_data AVP . . . . . . . . . . . . . . . . . . . 14 7.4. MN_MIP6_USRK AVP . . . . . . . . . . . . . . . . . . . . . 14 7.5. Verfication_Result AVP . . . . . . . . . . . . . . . . . . 15 8. Security considerations . . . . . . . . . . . . . . . . . . . 15 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 Appendix A. Appendix: Auth_ID generation . . . . . . . . . . . . 17 A.1. Auth_ID from USRK . . . . . . . . . . . . . . . . . . . . 17 A.2. Auth_ID as a random number . . . . . . . . . . . . . . . . 18 A.3. Cryptographic stateless Auth_ID . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Nakhjiri & Wan Expires July 22, 2007 [Page 2] Internet-Draft NSI January 2007 1. Introduction and problem statement With the advent of the more and more diverse broadband access technologies, the revenue margins for access providers are being reduced. The same diversity of the access technologies also dictates a need for access agnostic application and service offerings so that a service-only provider can deploy the same service architecture for any user regardless of the underlying access technology and co-exist with the access providers providing only connectivity. Mobile IPv6 operation is for instance considering scenarios where the Mobility service provider that is separate from the access service provider. Different providers will naturally use different AAA servers and possibly different AAA infrastructure to control and manage resource usage and users. Each service provider naturally deploys a different AAA server. Another emerging trend is the use of the extensible authentication protocol (EAP) for authentication of mobile nodes at the AAA servers. The key generation capabilities of the EAP servers [EAPKEYING] [USRK] combined with the addition of EAP as an authentication method for IKEv2 [IKEv2] allowing use of backend Diameter servers and infrastructure [RFC4072] has made EAP a popular authentication method compared to the customized authentication and key management mechanisms such as [RFC3012] and [RFC3579]. Providing master keys through EAP, is a desired feature that allows generation of many service-related keys [MIP_USRK]. The use of EAP and the existence of the Diameter EAP application, has made the Diameter community to decide to separate the act of authentication from the Diameter Mobile IPv6 application, when it comes to Diameter support for Mobile IPv6 authorization and bootstrapping [Dime_MIP6_Split] . This way, the peer and AAA client first run an EAP with the AAA server using Diameter EAP application, followed by a service authorization process for Mobile IPv6 service. The Diameter Mobile IPv6 application would then concentrate on authorization and accounting procedure. However, this creates some security considerations: -Potentially the AAA server performing EAP authentication and the AAA server performing Mobile IPv6 authorization can be separate. We denote the former as AAA-EAP or authenticating AAA (AAAn), and the latter as AAA-MIP or authorizing AAA (AAAz). The AAAn only performs the authentication task, and when doing so it may not be aware of the services the MN is going to request in the future, nor is able to authorize these services. However, according to [EAPKEYING] the AAAn as the entity performing EAP, is the only entity that holds EAP EMSK, required for generation of service- related keys. Thus EMSK can only reside at AAAn (no transport is Nakhjiri & Wan Expires July 22, 2007 [Page 3] Internet-Draft NSI January 2007 allowed), and AAAn is the only entity able to generate the USRK from EMSK (given "usage data" [USRK] ). On the other hand, the Mobile IP service is authorized only at AAAz, which means, it is AAAz that is aware of "usage data" and it is also AAAz that must hold and manage the service-related keys must be available to AAAz. For instance, in case of Mobile IPv6 service, it is the AAAz holds the Mobile IPv6 "usage data" and is able to authorize the MN for Mobile IPv6 service. Since EMSK is not available at the AAAz, the AAAz must make the "usage data" available to the AAAn and request for the MIP6_USRK [MIP_USRK] from the AAAn to be able to generate further Mobile IPv6 keys. -Separation of the authorization from authentication means that the authorizing server (AAAz) needs an assurance of the previous authentication with the authenticating server (AAAn). Using the same MN identifier may only help in cases where the AAAn and AAAz are the same, so that the AAA server can upon receiving a service request check the states related to MN and see that the authentication session is still valid and the MN is using the same identity. However, currently the MN does not provide any explicit proof of previous authentication in its service request to the AAAz. If an identity and message authentication is not enforced on service requests, any rouge MN (or even HA) could potentially spoof the current MN's identity and send service requests on behalf of a legitimate MN and have the charges for rendered services transferred to the legitimate MN. The protection provided today is based on the following argument: The MN and HA according to the [Dime_MIP6_Split] have established an IPsec association as part of the IKE and EAP authentication with AAAn. The HA can request service on behalf of the MN, since it knows that MN has been authenticated. There are however issues with using IKE for Mobile IP bootstrapping. 1. IKE messaging is used for configuration of Mobile IP parameters. However, bootstrapping Mobile IP parameters by itself means that Mobile IP service is already authorized. This creates a conflict between IKE messaging (this IPsec protection) and Mobile IP authorization messaging. 2. Even if the timing of the messaging is straighten out, an IPsec SA between MN and HA, only protects the MN against attackers on the MN-HA path (assuming IPsec protection of the signaling on this path is actually used), it does not protect the MN against a compromised HA, which can send service requests on behalf of any MN it wishes. So it is important that when AAAz receives a service request from the MN, it can assure that the MN has already been authenticated (with AAAn) and is using the same authenticated identity for the service Nakhjiri & Wan Expires July 22, 2007 [Page 4] Internet-Draft NSI January 2007 request, so that the AAAz can authorize service for a legitimate MN. -Additionally, another problem that arises from the current framework is that, if AAAz and AAAn are different, the MN may not have a security association with the AAAz initially and thus cannot sign a service request message in a way that can be verified by the AAAz. The proposal in this draft allows the MN to assure the AAAz of a previous authentication with the AAAn and to allow the AAAz to not only verify this authentication with the AAAn, but also to obtain other security material required for operation of Mobile IPv6 signaling. By providing explicit assurance by the MN within the service request to the AAAz, the chances of spoofing and theft of service are reduced and the architecture with separate AAAn and AAAz is supported. To do this, the draft introduces some new Diameter AVPs and Mobile IPv6 options to carry the assurances and signatures. However, the main concepts of Authorization identifier and Network Service Identifier (NSI) can be applied to any service controlled through a central authority such as AAAz, while separating the act of authorization from authentication. Through use of NSI the AAAz can simply find the AAAn and tie the authorization to the existing and valid authentication state. The message authentication and identity authentication from MN are also embedded in this approach. 2. Terminology 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 [RFC2119]. Network Service Identifier(NSI) The network service identifier is an identifier generated as a result of mobile node authentication and used in the authorization procedure to locate the authentication state or the authenticating server. Authenticating AAA server(AAAn) The AAA server that is in charge of authenticating the mobile node. The assumption in this document is that authentication takes place using EAP, although that may not necessarily be the case. For convenience, we use the terms AAAn and AAA_EAP, interchangeably. Authorizing AAA server(AAAz) Nakhjiri & Wan Expires July 22, 2007 [Page 5] Internet-Draft NSI January 2007 The AAA server that is in charge of authorizing a service, in case of this document Mobile IP service. For that reason, we use AAAz and AAA_MIP interchangeably. This document specifically support an implementation where the AAAz and AAAn can not only be physically separated but also operated by two different providers. AAAz will be operated by a mobility service provider (MSP). 3. Proposed solution: Use of Network Service Identifier To allow for easier separation of Diameter Mobile IP application from the Diameter authentication application (e.g. EAP[RFC4072]), and to support potentially disjoint authentication (AAAn) and authorization (AAAz) servers, without introducing new security risks, it is important to allow the authorizing server (AAAz) to ensure that the mobile node is properly authenticated previously before authorizing Mobile IP service. For those two reasons, it is important to sufficiently tie the authentication and authorization procedures between the potentially different AAA servers.. As mentioned, the AAAn at the time authentication, has no knowledge about the upcoming service request for Mobile IP service. Hence, the AAAn does not have access to service information and cannot generate usage specific root keys (USRK), such as MIP_USRK [MIP_USRK] even when the AAAn and AAAz are the same. To solve this problem, we suggest the use of a parameter called network service identifier (NSI) to assist the authorization process. The idea is that following a successful authentication, and prior to a service request, the MN generates the NSI and includes the NSI along with its service request to the AAAz (through a service agent such as HA, which acts as a AAA client for AAAz. We follow a similar syntax for NAI defined in [RFC4282]and [RFC0821] for NSI, i.e. the Augmented Backus_Noir Form (ABNF) of "username@realm": NSI=Auth_Info "@" realm The details are listed below: -realm: The realm is formed in the same manner as that in NAI and is designed to assist the AAA client (home agent) and the rest of the AAA infrastructure in routing AAA requests. In a general case, the realm for the authorizing AAA server (AAAz) may not be known to the MN and the MN may only know the realm for the AAAn which authenticated the MN. In that case: NSI_realm: realm for AAAn (e.g. the same as in the NAI, the MN has used for authentication with the AAAn). We can follow this convention also in cases where AAAn and AAAz are the same. In cases where the realm for the AAAz is known to the MN, the realm for AAAz may be used for the realm portion, while the realm of the AAAn can be appended to the Auth_ID portion of the Nakhjiri & Wan Expires July 22, 2007 [Page 6] Internet-Draft NSI January 2007 NSI as described below. -Auth_Info: Auth_Info=(Auth_ID | [AAAn-realm]): where the use of AAAn_realm is optional, and is only done in cases where the MN knows the realm of the AAAz and uses that information in the realm portion of NSI. In a general case, the MN uses the AAAn-realm as the realm portion of NSI and thus Auth_info=Auth_ID. The existence of AAAn_realm in Auth_info, can be indicated through an Auth_info_realm_flag or through a combination of Auth_ID_length and Auth_info_length within NSI, where the flag is set when AAAn_realm is present. -Auth_ID is a authorization identifier for an MN that acts as a one- time token to assist a AAA server finds the previous authentication state for the MN. The MN sends the Auth_ID as part of NSI back to the AAAz, which forwards it to the AAAn. Once the AAAn sees the Auth_ID, it can search for MN's authentication state and verify MN's authentication. There are several different ways to generate Auth_ID: 1. Auth_ID From USRK: This is only possible, when the AAAn and AAAz are the same and the AAAn is aware of the service being authorized at the time of peer authentication. The advantage of this approach is that the peer is also able to generate the Auth_ID and thus a secure transport of Auth_ID from AAAn to the peer is not required. The Auth_ID can be mobile specific in this case. The details of the Auth_ID generation are covered in the appendix. 2. Auth_ID as a random number: In completely decoupled scenarios, where AAAn and AAAz are separate servers and the AAAn is only authenticating the MN without having knowledge of future service requests, this is the preferred approach. The AAAn creates a random number as Auth_ID as a result of a successful authentication and passes it to the AAA client, which in turn forwards it to the peer. The Auth_ID needs to be temporally unique and unique for each MN. The transport details in this case are covered in Diameter considerations section. Considerations for random Auth_IDs are discussed in the appendix. This is the preferred approach due to its generality. 3. Cryptographic stateless Auth_ID: In case, where the AAAn server and AAAz server are separated and AAAn will not keep any MN specific states, the AAA server may generate the Auth_ID in a way that requires no MN-specific state, but uses generic states, such as internal non-MN-specific keys and nonces. This is also explained in the appendix. This approach also requires secure transport of Auth-ID from the AAAn to the peer, but does not Nakhjiri & Wan Expires July 22, 2007 [Page 7] Internet-Draft NSI January 2007 require the AAAn to store all previously generated Auth_IDs. 4. messaging procedure The messaging procedure described below assumes the use of a randomly generated Auth_ID or a cryptographically generated stateless Auth_ID at the AAAn server. This is to allow for a model, where authentication and AAAn are separate from authorization and AAAz. However, the Auth_ID must be transported from the AAAn to the peer. The case where the Auth_ID is generated at the MN does not require any transport. The procedure is shown in the following figure and described below: +----+ +-------+ +-----+ +--------+ | MN | |AAA-EAP| | HA | | AAA-MIP| +----+ +-------+ +-----+ +--------+ | | | | |<------------->| | | |Authentication | | | | | | | |----------------------------->| | |Service_request(NSI,nonce, | | |signed with SERVICE_TOKEN_KEY)|---------------------------->| | | |Mobile IPv6 authorization req| | | | | | |<-------------------------------------------| | | Mobile IPv6 key and verification request| | | | | | |------------------------------------------->| | | Mobile IPv6 key and verification Answer | | | | | | | |<----------------------------| | | | Mobile IPv6 | | | | authorization Answer | Figure.1 mip6 authorization procedure -After successful authentication with AAAn, the AAAn generates an Auth_ID for the MN. When EAP is used for authentication, the AAAn sends a Diameter EAP answer (DEA) to the AAA client (home agent). In such cases, the AAAn can include the Auth_ID inside an MN_MIP6_Auth_ID AVP. -The HA passes the Auth_ID back to the MN through IKE configuration signaling Nakhjiri & Wan Expires July 22, 2007 [Page 8] Internet-Draft NSI January 2007 -Upon reception of indication on successful EAP or IKE configuration messaging, the mobile node initiates the authorization process, by generating MIP6_USRK, the network service identifier, and the SERVICE_TOKEN_KEY. If the Auth_ID is to be created from the MIP6_USRK, the MN creates the Auth_ID as well. The MN then builds the NSI as explained previously in Section 3 for its service request. In case of Mobile IPv6, the service request is a binding update (BU) and the NSI is added within a and inserts the NSI extension inside a new "MN_MIP6_Authorization_option" designed as mobility option and added to the binding update. The option also includes a authenticator field, or more specifically a message authentication code (MAC) to protect the message and extension from tampering and to provide assurance of a previous authentication. The SERVICE_TOKEN_KEY derived from MIP6-USRK (as described shortly) is used in creation of the MAC. It should be noted that NSI is not used for the purpose of identification. In fact the same identity that was used for authentication to AAAn, must be used again. The MN may for instance use an NAI extension for this purpose. The details of NSI extension and mobile node identification are covered later on. -Upon reception of the Mobile IPv6 BU message, the home agent acting as an AAA client of the AAAz will create a Mobile IPv6 authorization command [Dime_MIP6_Split] for the AAAz. The HA inserts data included in the MN_MIP6_Authorization_option inside an MN_MIP6_NSI AVP for this command. The AAA AVPs are defined in Section 7. The home agent also needs to include the User_name AVP in the Mobile IPv6 authorization request to identify the mobile node. The User_name AVP must carry the same MN identity as that used for authentication previously. -Once received the Mobile IPv6 authorization request message, the AAAz needs to first make sure the MN is previously authorized. The AAAz extracts the MN_MIP6_NSI AVP from the Mobile IPv6 Authorization Request. Based on realm information in NSI (either in realm portion or within Auth_info portion), the AAAz can locate the AAAn realm and send a "Mobile IPv6 Key and verification request" (MKVR) command to the AAAn. This command has two purposes: first the AAAz asks the AAAn to verify the MAC signature and thereby assure AAAz that MN has already been authenticated and second to request creation a MIP6_USRK for usage at AAAz. The AAAn needs to know the usage data for Mobile IPv6 (defined in [MIP_USRK]) to be able to calculate the MIP6_USRK. Thus the AAAz must also include "usage data" required for creation of MIP6_USRK to the AAAn [USRK]. The usage data is included inside a "MIP6_Usage_data" AVP. Transport of usage data to AAAn is important, since AAAn (AAA_EAP) has the EMSK, while AAAn may not Nakhjiri & Wan Expires July 22, 2007 [Page 9] Internet-Draft NSI January 2007 have access to Mobile IPv6 related data. AAAz may get part of usage data from the HA or MN. After receiving the MKVR command from the AAAz, the AAAn needs to perform two checks: first the AAAn looks for Auth_ID of the NSI. If the Auth_ID is valid (not repeated previously and/or stored in the cache or can be created based on the given the data), then the AAAn proceeds with creating MIP6_USRK using EMSK. If Auth_ID verification fails, the AAAn does not need to calculate the USRK and simply sends a failure code inside the Verfication_Result AVP in an MKVA command (see below) to AAAz. Then, using the MIP6_USRK, the AAAn can generate the SERVICE_TOKEN_KEY to check the MN signature. If Auth_ID was generated by cryptographically using MIP6-USRK, the AAAn needs to do the same. If verification succeeds, the AAAn sends a Mobile IPv6 key and verification answer (MKVA) back to the AAAz. This command includes the MIP6_USRK for AAAz usage and also verifies that MN has already been authenticated by the AAAn, so that AAAz can authorize MN for MIP6 service. Therefore, the MIP6_USRK AVP must be encrypted. Using the previously established AAAn-AAAz security association (encrypted by a AAAn-AAAz key encryption key). The MIP6_USRK is included in the Mobile IPv6 key acknowledgement message for use at the AAAz for further key generation for Mobile IPv6 service. In case the verification fails, the MKVA includes an Authorization_Result AVP indicating the failure. -When received the MKVA command, the AAAz can create other MIP6 child keys using the MIP6_USRK. The MIP6 key generation is defined in [MIP_USRK] and authorize the MN for Mobile IPv6 service by sending a Mobile IPv6 authorization answer to the AAA client (HA). -Upon receiving the Mobile IPv6 authorization answer (MAA) message, the home agent can get the authorization result and MIP6 related keys. If authorization fails, the home agent needs to notify the mobile node in the binding acknowledgement message. 5. key management Section 3 discusses the authorization procedure. This section explains the keying hierarchy for the authorization procedure. Upon receiving the service data, the AAAn can generate the MIP6_USRK using EMSK and service data. EMSK is exported by the EAP method during authentication. The generation of MIP6_USRK is discussed in [MIP_USRK]. The SERVICE_TOKEN_KEY is generated from MIP6_USRK and the Auth_ID is optionally generated from MIP6_USRK. Figure 2 shows the keying hierarchy of the authorization procedure. Nakhjiri & Wan Expires July 22, 2007 [Page 10] Internet-Draft NSI January 2007 +-------+ | EMSK | +-------+ | | V +------------+ +---------+ |Usage data |-->|MIP6_USRK| +------------+ +---------+ | | +------------------+ | | V V +-----------------+ +-------+ +-----+ |SERVICE_TOKEN_KEY| |Auth_ID|<---|Nonce| +-----------------+ +-------+ +-----+ Figure.2 Authorization keying hierarchy The SERVICE_TOKEN_KEY key generation formula is shown below: SERVICE_TOKEN_KEY= PRF (MIP6_USRK, "service_token_key derivation"| MN_ID | AAAz_ID| Service_type| length) The details are listed below: -Service_type is to be standardized by IANA for the service (e.g. Mobile IPv6). -The length of SERVICE_TOKEN_KEY should be 128 bits. -MN_ID and AAAz_ID are used for identifying the two entities who share the key. The generation of Auth_ID, using MIP_USRK is described in Appendix. 6. MN_MIP6_Authorization_option: the NSI extension for Mobile IPv6 When requesting authorization for Mobile IPv6 service, the MN needs to include the NSI and the MAC signature along with other data inside a mobility option called "MN_MIP6_Authorization_option" to the HA. We use the syntax similar to [RFC3775] mobility options for this purpose. Nakhjiri & Wan Expires July 22, 2007 [Page 11] Internet-Draft NSI January 2007 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 | NSI (including Auth_ID)...| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN_ID ........... | Service_Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure.3 The MN_MIP6_Authorization_option Type TBD by IANA Length The length in bytes of all fields except the Type and length fields. NSI: A string in the NSI format (Auth_info@realm). NSI is formed as mentioned previously. The exact format and length of NSI is still TBD. It may need to include information on Auth_ID length, Auth_info_realm_flag and possibly information on the length of entire NSI or length of Auth_info field. MN_ID: this is the same MN identifier used for previous authentication. This information may be included in other mobility options along with the Mobile IPv6 message carrying this option. However, it is included in this option to make the conversion of this Mobile IPv6 option to Diameter AVPs more straightforward. In cases where bandwidth limitation for link between MN and HA is a concern, this field can be dropped from this option and added by the HA to the Diameter AVP. The "Service Type" indicates Mobile IPv6 service. This is in anticipation of the AAA community using the notion of NSI for a generic service application, where service authorization signaling is separated from end node authentication. Services other than Mobile IP can use different Service Type values. Inclusion of service type field within a Mobile IPv6 option seems rather redundant, however, this makes conversion of this Mobile IPv6 option to Diameter AVPs more straightforward. In cases where bandwidth limitation for link between MN and HA is a concern, this field can be dropped from this option and added by the HA to the Diameter AVP. The length of "Service Type" is TBD based on other IETF efforts such as USRK definitions. MAC is the authenticator field for the option and is calculated as follows Nakhjiri & Wan Expires July 22, 2007 [Page 12] Internet-Draft NSI January 2007 MAC=First (128, HMAC_SHA1 (SERVICE_TOKEN_KEY, Authorization data) where the authorization data=(NSI | MN_ID | Service_Type) Note that NSI includes AAAn realm information and thereby is an indicator of the AAA server that authenticated the MN and possibly generated parts of Auth_ID. 7. Diameter considerations and AVPs Section 3 defines the authorization procedure. This section defines the diameter AVPs used in the authorization procedure. 7.1. MN_MIP6_NSI AVP As the AAA infrastructure typically uses NAI to identify the user, the NSI should be carried in a separate diameter AVP rather than inside User_Name. The NSI information along data for its verification (the MAC signature) is fitted inside an diameter AVP, called "MN-MIP6-NSI" for transport with Diameter signaling. The MN_MIP6_NSI AVP is of type grouped: MN_MIP6_NSI ::= < AVP Header: TBD > {Auth_ID} {Auth_ID_TYPE} {Auth_ID_length} {Auth_info_length} {NSI} {User_name} {Service_Type} {MAC} The details are listed below: -The MN_MIP6_NSI is extracted by the HA from the information included in MN_MIP6_Authorization option included in Mobile IPv6 signaling. -The AVPs are extracted by the HA from the MN_MIP6_Authorization_option directly. -The User_name AVP must include the MN_ID that is used within the MN_MIP6_Authorization_option. Otherwise the MAC verification will fail later on. Inclusion of User_name seems redundant in cases where the service requests should include a User_name. However, since User_name is used in calculation of the MAC signature, adding user name to this AVP, makes the AVP self sufficient for later verification of the MAC. This user name along with Auth_ID will serve the AAAn to locate the authentication state and keys from the MN's authentication session. It is recommended that mobile node Network Access Identifier (NAI) is used as MN_ID, since AAA servers today can uniquely identify the clients by using the NAI. [RFC4283] specifies a way for the mobile node to use NAI for identification and authentication to the AAA server by including the NAI in the MN-NAI Nakhjiri & Wan Expires July 22, 2007 [Page 13] Internet-Draft NSI January 2007 Mobility Option along with the Mobile IPv6 binding update. This is especially important for MNs who do not have a home address available. The bootstrapping documents have implied use of FQDN style identities in the IKE_AUTH exchanges. -Auth_ID_TYPE specifies the method by which the auth_ID is created. 1: random number, 2: using AAA_secret, 3: using USRK. 7.2. MN_MIP6_AUTH_ID AVP After EAP authentication, in case the Auth_ID is generated only at the AAAn, the AAAn may need to send the Auth_ID to the AAA client and then to MN. The diameter AVP used for transporting Auth_ID from the AAAn to the diameter client, called MN_MIP6_AUTH_ID AVP is defined below: MN_MIP6_AUTH_ID ::= < AVP Header: TBD > {Auth_ID} {Auth_ID_TYPE} {Auth_ID_length}{User_name} the MN_MIP6_AUTH_ID AVP can be transported along with a DEA (Diameter EAP answer) message from AAAn to the AAA client. However, since the destination for Auth_ID information is the MN, the information within Auth_ID must be protected against tampering by intermediaries (including the AAA client) and thus must be signed by AAAn using a key that is only available to the MN. The Auth_ID information is carried from AAA client to the MN through the protocol available between the AAA client and the MN. For instance in cases where IKEv2 messaging is used for conveying Mobile IP bootstrapping information from HA to the MN, the same IKE message can carry the Auth_ID information. 7.3. MIP6_Usage_data AVP The content of "usage data" to be used for Mobile IPv6 is to be standardized based on the guidelines of [USRK] and thus is TBD. 7.4. MN_MIP6_USRK AVP After a successful verification, the AAAn will send the MIP6_USRK information to the AAAz. The MIP6_USRK information is fitted inside the diameter AVP called MN_MIP6_USRK AVP. The MN_MIP6_USRK AVP is of type grouped and contains data for lifetime. Its value has the following ABNF grammar: MN_MIP6_USRK ::= < AVP Header: TBD > {MIP6_USRK} {User_name} {lifetime} The details are listed below: Nakhjiri & Wan Expires July 22, 2007 [Page 14] Internet-Draft NSI January 2007 -The lifetime is suggested by the AAAn based on EMSK lifetime. However, the ultimate decision on MIP6_USRK lifetime is performed by AAAz. -The MIP6_USRK AVP must be encrypted, using the previously established AAAn-AAAz security association (encrypted by a AAAn-AAAz key encryption key). 7.5. Verfication_Result AVP In case the verification of the request from AAAz fails at the AAAn (signature not verifiable), this AVP can be used to communicate the failure to the AAAz inside the MKVA command. Inclusion of a success may be optional, when USRK-related AVPs are included. 8. Security considerations The treatment of NSI at the AAA devices should be similar to that of NAI. It is desired that Auth_ID part (user-specific part) of the NSI is treated as opaque data, when the NSI is treated by nodes other than AAAn and AAAz. Since Auth_ID does not have a direct correlation with User ID, user privacy does not require encryption of Auth_ID for privacy from unintended intermediaries. As long as anti-replay measures are taken to ensure temporal uniqueness of Auth_ID, so that a man in the middle cannot replay the service request with the same Auth_ID to gain access. It should be noted that the procedures proposed in this case can only protect the MN and the AAAz from tampering of authorization signaling (service requests). If the HA as a AAA client is given full control in providing Mobile IP service, a compromised HA may still provide service to unauthorized and unauthenticated MNs. Furthermore, a compromised HA may also intentionally not send accounting records related to unauthorized MNs or send accounting records using the identity of a legitimate MN, causing the charges for a stolen service to be deferred to a legitimate subscriber. Protection of accounting framework (in the sense of policing of the accounting for rendering services to authorized MNs is a security problem for the accounting framework and is outside scope of this document. 9. IANA considerations The value for MN_MIP6_Authorization_option must be assigned from the Mobile IPv6 [RFC3775] numbering space. The [Dime_MIP6_Split] defines the MAR and MAA commands for Nakhjiri & Wan Expires July 22, 2007 [Page 15] Internet-Draft NSI January 2007 authorization between the home agent and the AAAz. This document defines the MAD, MKVR and MKVA commands that are used between the AAAn and the AAAz. Those command code values must be assigned from the command code name space defined in [RFC3588]. The MN_MIP6_NSI AVP, MN_MIP6_AUTH_ID AVP and MN_MIP6_USRK AVP codes should be assigned from the AVP code name space defined in[RFC3588]. 10. References 10.1. Normative References [Dime_MIP6_Split] Bournelle, J., "Diameter Mobile IPv6: HA-to-AAAH support", October 2006, . [EAPKEYING] Aboba, B. and Et. Al, "Extensible Authentication Protocol (EAP) Key Management Framework", January 2007, . [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", December 2005, . [MIP_USRK] Nakhjiri, M. and C. Wan, "Specification for use of EAP EMSK in deriving Mobile IP root keys", October 2006, . [RFC0821] Postel, B., "SIMPLE MAIL TRANSFER PROTOCOL", August 1982, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997, . [RFC3012] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/ Response Extensions", November 2000, . [RFC3588] Calhoun, P. and Et. Al, "Diameter Base Protocol", September 2003. [RFC3748] Aboba , B. and Et. Al, "Extensible Authentication Protocol Nakhjiri & Wan Expires July 22, 2007 [Page 16] Internet-Draft NSI January 2007 (EAP)", June 2004. [RFC3775] Johnson, D. and Et. Al, "Mobility Support in IPv6", June 2004, . [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", August 2005, . [RFC4282] Aboba, B. and Et. Al, "The Network Access Identifier", December 2005, . [RFC4283] Patel , A. and Et. Al, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", November 2005, . [USRK] Salowey, J. and Et. Al, "Extensible Authentication Protocol (EAP) Key Management Framework", June 2006, . 10.2. Informative References [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", September 2003, . Appendix A. Appendix: Auth_ID generation As seen before, generation of auth_ID (Authorization identifier) requires slightly more fineness and thought, since the authentication and authorization steps may be performed at different times and possibly by different servers. In general case, one cannot assume that all service and authentication data are available at the same time and the same place. As we saw earlier, depending on the scenario at hand, one could take 3 different approaches for generating Auth_ID. In the following we provide detailed descriptions for each case. A.1. Auth_ID from USRK In this case, the AAAn and AAAz were the same and the AAAn, performing EAP, at the time of authentication, has the service data related to the Mobile IP available, it could generate the MIP_USRK Nakhjiri & Wan Expires July 22, 2007 [Page 17] Internet-Draft NSI January 2007 from the EMSK resulted from EAP data[MIP_USRK]. The same AAAn could then generate Auth_ID cryptographically using the MIP_USRK. So does the mobile node. In this case, the Auth_ID generation formula is shown below: Auth_ID=PRF (MIP6_USRK, "Authorization ID generation" | | Service_type |length) The details are listed below: -Service_type should match the one used for generating SERVICE_TOKEN_KEY. -The length of Auth_ID should be at least 128 bits. -Nonce is only needed for the AAA servers that cannot hold any previous state or if multiple authorization requests may be required during the lifetime of the authentication session, since no other parameter used with Auth_ID generation from MIP6_USRK provides anti_replay protection. -PRF provides cryptographic separation between User ID and Auth_ID. As one can see, the Auth_ID can be mobile specific and unique to each authentication session. A.2. Auth_ID as a random number When Auth_ID is generated randomly, a minimum length guarantee is important for providing uniqueness and a guarantee for protection against theft of service. Therefore we recommend that the Auth_ID such that it generates an NSI of at least 253 octets (following the same recommendations for NAI length). Any device (AAA client, AAAn and AAAz servers) handling NSI should support a minimum length of 253 octets. The length requirements does not however provide any protection against replay attacks. To provide such protection, it is required that each Auth_ID is used only once with each service request and each AAAz. This means Auth_IDs cannot be repeated in different service requests. This however requires the AAAn and possibly AAAz to keep state of the previously used Auth_IDs for the valid authentication session (e.g. EAP session). Once the authenticated session expires, the AAAn can delete the cache of Auth_IDs issues for the MN. A.3. Cryptographic stateless Auth_ID : In case, where the AAAn server and AAAz server are separated and AAAn will not keep any MN specific states, the AAA server may Nakhjiri & Wan Expires July 22, 2007 [Page 18] Internet-Draft NSI January 2007 generate the Auth_ID in a way that requires no MN-specific state, but uses generic states, such as internal non-MN-specific keys and nonces: Auth_ID=PRF(AAA_key, "Auth_ID generation"| nonce| length) Where the AAA_key is a key that only AAAn knows internally (possibly not tied to EAP session), and the nonce is internal to the AAAn. It is at the discretion of the AAAn to refresh the nonces to the extent that the AAAn server memory allows to keep previous nonces. When a request from MN with an Auth_ID arrives, the AAAn simply uses its internal state (AAA_key and nonce) to generate the Auth_ID and verify the request. The AAAn does not need to keep state of all previously created Auth_IDs, but needs to keep a cache of previously used nonces. The AAA server may also send the nonce along with Auth_ID to the peer, so that the peer may include the nonce in its future requests. This way the AAAn does not need to keep state of the nonce either. The nonce and Auth_ID should have the same length of at least 128 bits. Since, the nonces are not required to change for each MN. This means, the Auth_ID in this case will not be unique for the period which the nonce is constant. Authors' Addresses Madjid Nakhjiri Huawei USA Email: mnakhjiri@huawei.com Changsheng Wan (editor) Huawei Technologies Email: wanchangsheng@ustc.edu Nakhjiri & Wan Expires July 22, 2007 [Page 19] Internet-Draft NSI January 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Nakhjiri & Wan Expires July 22, 2007 [Page 20]