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, <http://www.ietf.org/internet-drafts/
              draft-ietf-dime-mip6-split-01.txt>.

   [EAPKEYING]
               Aboba, B. and Et. Al, "Extensible Authentication Protocol
              (EAP) Key Management Framework", January 2007, <http://
              www.ietf.org/internet-drafts/
              draft-ietf-eap-keying-16.txt>.

   [IKEv2]    Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              December 2005,
              <http://www.ietf.org/rfc/rfc4306.txt?number=4306>.

   [MIP_USRK]
              Nakhjiri, M. and C. Wan, "Specification for use of EAP
              EMSK in deriving Mobile IP root keys", October 2006,
              <http://www.ietf.org/rfc/rfc2119.txt?number=2119>.

   [RFC0821]  Postel, B., "SIMPLE MAIL TRANSFER PROTOCOL", August  1982,
              <http://www.ietf.org/rfc/rfc0821.txt?number=0821>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997,
              <http://www.ietf.org/rfc/rfc2119.txt?number=2119>.

   [RFC3012]  Perkins, C. and P.  Calhoun, "Mobile IPv4 Challenge/
              Response Extensions", November  2000,
              <http://www.ietf.org/rfc/rfc3012.txt?number=3012>.

   [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,
              <http://www.ietf.org/rfc/rfc3775.txt?number=3775>.

   [RFC4072]  Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
              Authentication Protocol (EAP) Application", August 2005,
              <http://www.ietf.org/rfc/rfc4072.txt?number=4072>.

   [RFC4282]  Aboba, B. and Et. Al, "The Network Access Identifier",
              December 2005,
              <http://www.ietf.org/rfc/rfc4282.txt?number=4282>.

   [RFC4283]  Patel , A. and Et. Al, "Mobile Node Identifier Option for
              Mobile IPv6 (MIPv6)", November 2005,
              <http://www.ietf.org/rfc/rfc4283.txt?number=4283>.

   [USRK]     Salowey, J. and Et. Al, "Extensible Authentication
              Protocol (EAP) Key Management Framework", June 2006, <http
              ://tools.ietf.org/wg/eap/
              draft-salowey-eap-emsk-deriv-01.txt>.

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,
              <http://www.ietf.org/rfc/rfc3579.txt?number=3579>.


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" | <nonce> |
   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]