Internet DRAFT - draft-narayanan-psk-addr-gen

draft-narayanan-psk-addr-gen







Network Working Group                                    N. Venkitaraman
Internet-Draft                                                  Motorola
Expires: August 14, 2006                                    V. Narayanan
                                                               Qualcomm
                                                       February 10, 2006


               Pre-Shared Key (PSK) Based Addresses (PBA)
                  draft-narayanan-psk-addr-gen-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 August 14, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Cryptographically generated addresses (CGAs) provide a means of
   generating an IP address that is tied to a public key of a node.
   Using this means, the address ownership of the node can be verified
   by using the public key of the node to decrypt data signed by the
   node using its private key.  In AAA-based systems, there is currently
   no means of performing such absolute address ownership checks, since
   address authorization is traditionally outside the scope of AAA.



Venkitaraman & Narayanan  Expires August 14, 2006               [Page 1]

Internet-Draft             PSK-Based Addr Gen              February 2006


   However, in some key generation protocols, it may be critical to
   perform address ownership verification or authorization before the
   generated key can be used.  When such key generation protocols are
   AAA-based, there is no known method of address authorization to allow
   this operation.

   This draft provides a means of IPv6 address generation using a shared
   secret so that the IP address of a node can be verified by the entity
   with which the node shares the secret.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  PBA Generation  . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  PBA Verification  . . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6
   Intellectual Property and Copyright Statements  . . . . . . . . . . 7


























Venkitaraman & Narayanan  Expires August 14, 2006               [Page 2]

Internet-Draft             PSK-Based Addr Gen              February 2006


1.  Introduction

   Cryptographically generated addresses (CGAs) provide a means of
   generating an IP address that is tied to a public key of a node.
   Using this means, the address ownership of the node can be verified
   by using the public key of the node to decrypt data signed by the
   node using its private key.  In AAA-based systems, there is currently
   no means of performing such absolute address ownership checks, since
   address authorization is traditionally outside the scope of AAA.
   However, in some key generation protocols, it may be critical to
   perform address ownership verification or authorization before the
   generated key can be used.  When such key generation protocols are
   AAA-based, there is no known method of address authorization to allow
   this operation.

   For instance, AAA-based authentication and authorization are often
   used in cellular and WiMax systems.  Nodes running Mobile IP may use
   a secret shared with the AAA server as a means for authentication and
   derivation of shared keys with the home agent.  In the case of Fast
   Mobile IP (FMIP), handover keys may be derived using AAA between the
   MN and AR.

   This draft provides a means of IPv6 address generation using a shared
   secret so that the IP address of a node can be verified by the entity
   with which the node shares the secret.  For instance, an MN may use
   an MN-AAA key to derive an IPv6 address suffix that can be verified
   by the AAA server for address authorization.  Any AAA-assisted key
   derivation protocols may use the method specified in this draft to
   verify the address and bind the derived keys to the IP address of the
   MN.


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 RFC- 2119 [1].

   In addition, this document uses the following terms:

   Pre-Shared Key (PSK) Based Address (PBA)

      An IPv6 address generated cryptographically using a pre-shared
      key.







Venkitaraman & Narayanan  Expires August 14, 2006               [Page 3]

Internet-Draft             PSK-Based Addr Gen              February 2006


   Address Generation Key (AGK)

      A key generated from the PSK specifically to use in the creation
      of PBAs.


3.  PBA Generation

   This section describes a method of using a Pre-Shared Key (PSK) to
   derive the IPv6 address of a node.  The input parameters for PBA
   Generation include an Address Generation Key (AGK) generated using
   the PSK, a link ID of the node (e.g., MAC address), a nonce, the ID
   of the router advertising the prefix and the advertised network
   prefix itself.  The AGK is derived from the PSK as follows.

   AGK = PRF (PSK, Node ID | Key Generation Nonce | "Address Generation
   Key"), where | denotes concatenation.

   In AAA-based scenarios, the PSK is the key that the node shares with
   the AAA server (e.g., MN-AAA secret).  The Node ID in this case is
   the NAI of the node.  The Key Generation Nonce is a random value
   generated by the node.  It is recommended that the nonce be a
   cryptographically generated value for added privacy.

   The IPv6 suffix of the address of the node is derived as follows.

   Address Suffix = PRF (AGK, Router ID | Collision Count), where |
   denotes concatenation.

   The Router ID is the IP address of the router advertising the IPv6
   prefix.  The collision count by default is 0 and is incremented by 1
   every time there is a collision on the generated address.  The Pseudo
   Random Function (PRF) used is HMAC-SHA1.

   The generated suffix is then concatenated with the advertised prefix
   to form a complete IPv6 address for the node.


4.  PBA Verification

   The PBA may be sent to an entity that shares the PSK with the node
   for address ownership verification.  Such a message must contain a
   hash of the address generated using the PSK.  For instance, a node
   may use the AAA key to sign the message to the AAA server.  The other
   parameters such as the nonce, router ID and collision count must also
   be sent to the AAA server.  The collision count should be considered
   to be 0 if it is not specifically sent to the AAA server or other
   verifying entity.



Venkitaraman & Narayanan  Expires August 14, 2006               [Page 4]

Internet-Draft             PSK-Based Addr Gen              February 2006


   After successful verification of the signature, the AAA server must
   generate the AGK corresponding to the node based on the PSK as in the
   previous section.  The AGK can then be used along with the other
   parameters in generating the address suffix in exactly the same
   manner as done by the node.  It is generally sufficient to verify
   that the node is claiming the right suffix.


5.  Security Considerations

   This document describes a means of address authorization using pre-
   shared keys.  It is not known to introduce any security
   vulnerabilities.  In general, the PSK and nonce used must be strong
   to avoid any observer being able to generate the same address or
   being able to tie multiple PBAs of a node together to derive the key.


6.  IANA Considerations

   No IANA services are required in this document.


7.  Acknowledgments


8.  References

8.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

8.2.  Informative References

   [2]  Aura, T., "Cryptographically Generated Addresses (CGA)",
        RFC 3972, March 2005.















Venkitaraman & Narayanan  Expires August 14, 2006               [Page 5]

Internet-Draft             PSK-Based Addr Gen              February 2006


Authors' Addresses

   Narayanan Venkitaraman
   Motorola
   1301 E. Algonquin Road
   Schaumburg, IL  60196
   US

   Email: narayanan.venkitaraman@motorola.com


   Vidya Narayanan
   Qualcomm
   5775 Morehouse Dr
   San Diego, CA  92121
   US

   Email: vidyan@qualcomm.com

































Venkitaraman & Narayanan  Expires August 14, 2006               [Page 6]

Internet-Draft             PSK-Based Addr Gen              February 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

   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 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.


Copyright Statement

   Copyright (C) The Internet Society (2006).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Venkitaraman & Narayanan  Expires August 14, 2006               [Page 7]