[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01 02                                                      
Network Working Group                                        J. Laganier
Internet-Draft                         ENS Lyon / Sun Microsystems, Inc.
Expires: August 25, 2003                                   G. Montenegro
                                                  Sun Microsystems, Inc.
                                                       February 24, 2003


        Using IKE with IPv6 Cryptographically Generated Address
                     draft-laganier-ike-ipv6-cga-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 25, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This document describes IKE peer authentication via IPv6
   Cryptographically Generated Addresses.  These have been proposed to
   solve several security issues in the absence of any trusted
   infrastructure.









Laganier & Montenegro    Expires August 25, 2003                [Page 1]


Internet-Draft    Using IKE with IPv6 Cryptographically Generated AddressFebruary 2003


Table of Contents

   1.  Introduction and Problem Statement . . . . . . . . . . . . . .  3
   2.  Related work . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Node Configuration and Requirements  . . . . . . . . . . . . .  5
   4.  ISAKMP Payload use . . . . . . . . . . . . . . . . . . . . . .  6
   4.1 Identification Payload . . . . . . . . . . . . . . . . . . . .  6
   4.2 Certificate Payload  . . . . . . . . . . . . . . . . . . . . .  6
   4.3 Certificate Request Payload  . . . . . . . . . . . . . . . . .  6
   4.4 Authentication Payload . . . . . . . . . . . . . . . . . . . .  7
   5.  Authentication of the IKE Security Association . . . . . . . .  8
   6.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   8.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  Intellectual Property Rights Considerations  . . . . . . . . . 12
       Normative References . . . . . . . . . . . . . . . . . . . . . 13
       Informative References . . . . . . . . . . . . . . . . . . . . 14
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
































Laganier & Montenegro    Expires August 25, 2003                [Page 2]


Internet-Draft    Using IKE with IPv6 Cryptographically Generated AddressFebruary 2003


1. Introduction and Problem Statement

   This document describes how to use IKE with IPv6 Cryptographically
   Generated Address (CGA).  This technique only requires slight
   modifications and can be used by one or both peers.

   One use of CGA is address proof-of-ownership, but it can also be used
   with authorization certificates (e.g.  SPKI, Keynote2) to enable a
   flexible authorization framework.  CGA's have been proposed to solve
   several security issues in the absence of any trusted infrastructure,
   for example, securing Binding Updates in Mobile IPv6, securing
   Neighbor Discovery for IPv6, and securing Group Membership in
   Multicast and Anycast communications.






































Laganier & Montenegro    Expires August 25, 2003                [Page 3]


Internet-Draft    Using IKE with IPv6 Cryptographically Generated AddressFebruary 2003


2. Related work

   The lack of a global, Internet-wide, trusted infrastructure is at the
   heart of these issues.  This precludes a straightforward application
   of IPsec between any two previously unknown nodes.  The impossibility
   of always having the choice of obtaining a security association by
   leveraging a centralized infrastructure has led to cryptographic
   techniques commonly known as CGA or SUCV.  CGA usage has lacked
   generality as it has been applied either within specific frameworks
   like Mobile IP ([4], [5]) or using its own custom protocol,
   Statistically Unique and Cryptographically Verifiable protocol
   (sucvP) [4].  Lately, a proposal using Just Fast Keying (JFK) has
   been put forth ([6]).  Nevertheless, we believe that a full-blown key
   exchange protocol is redundant.  Moreover, because the design,
   implementation and debugging of a new security protocol is especially
   costly and error-prone, we think that it is not worth "reinventing
   the wheel".  From the point of view of implementation effort, the
   fact that this approach only requires the addition of stand-alone CGA
   validation routines into existing IKE daemons (e.g.  racoon, isakmpd,
   pluto, etc) is another considerable advantage.

   Accordingly, this note presents an overview of how to use the
   Internet Key Exchange protocol [1] while one or both peers
   authenticate themselves via CGA proof-of-ownership.  This document
   details the slight modifications needed.  Additionally, it aims at
   capturing the current thinking about how to achieve proof-of-
   ownership in IKE via CGA in a standard manner, thus preventing
   subsequent conflicting definitions.























Laganier & Montenegro    Expires August 25, 2003                [Page 4]


Internet-Draft    Using IKE with IPv6 Cryptographically Generated AddressFebruary 2003


3. Node Configuration and Requirements

   Each node that want to prove address ownership via CGA generates a
   public-private key pair, PK and SK, respectively.  The nodes then use
   P to obtain and configure a CGA as specified in [4]:

   CGA = NetworkPrefix | SHA1_64 ( PK )

   Those nodes that want to prove that they own their CGA should use it
   as their so-called IKE "peer" address while sending IKE packets.









































Laganier & Montenegro    Expires August 25, 2003                [Page 5]


Internet-Draft    Using IKE with IPv6 Cryptographically Generated AddressFebruary 2003


4. ISAKMP Payload use

   A peer wanting to prove CGA ownership while exchanging keys with IKE
   has to use ISAKMP payloads in a specific manner.  Following
   subsections describes the requirements on those of the ISAKMP
   payloads that need it while doing an IKE phase 1 exchange with CGA
   proof-of-ownership.

4.1 Identification Payload

   The Identification (ID) Payload of IKE contains the name of the
   entity to be authenticated with the Authentication (AUTH) Payload.
   When using CGA, the name of the node is its CGA.  Though CGA are IPv6
   Addresses as well, a peer embedding its CGA within the ID payload
   under the type ID_IPV6_ADDR would not trigger any verification of the
   PK-CGA binding on the other side.  Hence, we believe that a new ID
   type is needed to explicitly state the cryptographic nature of a CGA
   and require verification of the binding.  Thus, a peer wanting to
   prove CGA ownership MUST use an ID payload of type ID_IPV6_CGADDR
   containing its CGA.  The value of type ID_IPV6_CGADDR is initially
   assigned out of the range 249-255 reserved for "private use amongst
   cooperating systems", as per [2].  If justified, a subsequent, more
   official assignment will imply IANA involvement.

4.2 Certificate Payload

   The Certificate (CERT) Payload provide a means to transport
   certificates within IKE packets.  When performing CGA ownership
   exchange, Certificates should be used to transmit to the
   correspondent the public key used to generate the CGA.  Though
   several types of certificates are specified in [1], we only use those
   that contains a public key, namely PKCS7_WRAPP_X509_CERT, PGP_CERT,
   DNS_SIGNED_KEY, X509_CERT_SIGNATURE and SPKI_CERT.  A peer wanting to
   prove CGA ownership MUST use a CERT payload that contains the public
   key used when generating its CGA.

4.3 Certificate Request Payload

   The Certificate Request (CERTREQ) Payload is used by a peer to
   request preferred certificates to its correspondent.  A preference is
   the type of certificate requested as well as an acceptable
   certificate authority for this type.  A peer can include multiples
   preferences using several CERTREQ payload.  For CGA, certificates
   used would usually be self-signed, though this does not preclude one
   to generate its CGA using the public key embedded in a CA-signed
   certificate.





Laganier & Montenegro    Expires August 25, 2003                [Page 6]


Internet-Draft    Using IKE with IPv6 Cryptographically Generated AddressFebruary 2003


4.4 Authentication Payload

   The Authentication (AUTH) Payload contains data used to authenticate
   the entity named in the ID payload, i.e.  the CGA owner.  Since CGA
   are generated using public key cryptography, the AUTH payload have to
   contain a digital signature of the message computed using the public
   key contained in the CERT payload.  Currently specified digital
   signature algorithms includes RSA and DSA, but this scheme could be
   used with any public key cryptographic algorithm.  A peer wanting to
   prove CGA ownership MUST use an AUTH payload that contains the
   digital signature computed using the private key associated with its
   CGA.







































Laganier & Montenegro    Expires August 25, 2003                [Page 7]


Internet-Draft    Using IKE with IPv6 Cryptographically Generated AddressFebruary 2003


5. Authentication of the IKE Security Association

   [1] does not mandate that two peers exchanging keys use the same
   means of authenticating themselves.  Available means of
   authentication are Digital Signatures, Public Key Encryption and Pre-
   shared Secret.  It is explicitly stated that end-points are not
   required to use the same means of authenticating themselves.  One
   could use pre-shared secret, while the other could use a digital
   signature.  This note does not conflict with that, allowing one or
   both entities to prove CGA ownership, thus allowing one to possibly
   use another means of authenticating itself.

   On nodes that want to verify address ownership, IKE implementation
   should be modified to handle the case of CGA verification which is
   very similar to already implemented self-signed certificates one.
   Apart from verifying the self-signed certificate, the implementation
   MUST verify that the public key contained in the certificate generate
   the address used in the identity payload as detailed above.

































Laganier & Montenegro    Expires August 25, 2003                [Page 8]


Internet-Draft    Using IKE with IPv6 Cryptographically Generated AddressFebruary 2003


6. Conclusion

   This note presents an overview of how IKE and CGA can be combined to
   achieve CGA proof-of-ownership authentication.  The CGA technique is
   sufficiently well understood and can use widely deployed and
   implemented mechanisms.  This proposal works in the absence of any
   previously established direct or indirect (via a broker, AAA roaming
   operator or trusted third party) security relationship.  Because of
   this, these methods are a very practical and deployable means of
   using IPsec between previously unknown peers.









































Laganier & Montenegro    Expires August 25, 2003                [Page 9]


Internet-Draft    Using IKE with IPv6 Cryptographically Generated AddressFebruary 2003


7. Security Considerations

   This document discusses possible use of IKE as a means to prove CGA
   ownership and exchange keys to bootstrap IPsec SAs.  Because IKE has
   already been specified and this technique only slightly modify it, we
   believe that this should not raise others security concerns that
   those incurred by CGA proof-of-ownership.  Though the cryptographic
   algorithm used are the same, CGA proof-of-ownership is very different
   in nature to authentication.  One must be especially careful when
   establishing the security policy, as this technique allows nodes that
   use their own IPv6 CGA to be successfully authenticated as their
   "owner".  This is similar in essence to IKE used with self-signed
   certificates, with the additional consideration that CGA binds the
   address to the public key.  A CGA may be considered as a verifiable
   self-generated address.




































Laganier & Montenegro    Expires August 25, 2003               [Page 10]


Internet-Draft    Using IKE with IPv6 Cryptographically Generated AddressFebruary 2003


8. Open Issues

   This document introduce a new ID payload type, ID_IPV6_CGADDR.
   However, it is not yet clear what is the most appropriate means of
   requiring peers to verify the PK-CGA binding.  Other means are
   possible.













































Laganier & Montenegro    Expires August 25, 2003               [Page 11]


Internet-Draft    Using IKE with IPv6 Cryptographically Generated AddressFebruary 2003


9. Intellectual Property Rights Considerations

   The IETF takes no position regarding the validity or scope of
   intellectual property or other rights that might be claimed 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; neither does it represent that it has made
   any effort to identify any such rights.  Information on the IETF's
   procedures with respect to rights in standards-track and standards-
   related documentation can be found in BCP-11.  Copies of claims of
   rights made available for publication 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 implementors or users of this specification can be obtained from
   the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.

























Laganier & Montenegro    Expires August 25, 2003               [Page 12]


Internet-Draft    Using IKE with IPv6 Cryptographically Generated AddressFebruary 2003


Normative References

   [1]  Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
        RFC 2409, November 1998.

   [2]  Piper, D., "The Internet IP Security Domain of Interpretation
        for ISAKMP", RFC 2407, November 1998.

   [3]  Maughan, D., Schneider, M., Schertler, M. and J. Turner,
        "Internet Security Association and Key Management Protocol
        (ISAKMP)", RFC 2408, November 1998.








































Laganier & Montenegro    Expires August 25, 2003               [Page 13]


Internet-Draft    Using IKE with IPv6 Cryptographically Generated AddressFebruary 2003


Informative References

   [4]  Montenegro, G. and C. Castelluccia, "Statistically Unique and
        Cryptographically Verifiable  (SUCV) Identifiers and
        Addresses.", NDSS 2002, February 2002.

   [5]  Roe, M., Aura, T., O'Shea, G. and J. Arkko, "Authentication of
        Mobile IPv6 Binding Updates and Acknowledgments", draft-roe-
        mobileip-updateauth-02 (work in progress), February 2002.

   [6]  Castelluccia, C. and G. Montenegro, "IPv6 Opportunistic
        Encryption", INRIA Research Report RR-4568, October 2002.

   [7]  Castelluccia, C. and G. Montenegro, "Securing Group Management
        in IPv6 with  Cryptographically Generated  Addresses", draft-
        irtf-gsec-sgmv6-00 (work in progress), April 2002.


Authors' Addresses

   Julien Laganier
   ENS Lyon / Sun Microsystems, Inc.
   180, avenue de l'Europe
   38334 Saint Ismier CEDEX
   France

   EMail: julien.laganier@sun.com


   Gabriel Montenegro
   Sun Microsystems, Inc.
   180, avenue de l'Europe
   38334 Saint Ismier CEDEX
   France

   EMail: gab@sun.com















Laganier & Montenegro    Expires August 25, 2003               [Page 14]


Internet-Draft    Using IKE with IPv6 Cryptographically Generated AddressFebruary 2003


Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

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



















Laganier & Montenegro    Expires August 25, 2003               [Page 15]