[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 RFC 6193

MMUSIC Working Group                                            M. Saito
Internet-Draft                                        NTT Communications
Intended status: Standards Track                                 D. Wing
Expires: December 27, 2007                                 Cisco Systems
                                                           June 25, 2007


  Media Description for IKE in the Session Description Protocol (SDP)
                     draft-saito-mmusic-sdp-ike-01

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 December 27, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).













Saito & Wing            Expires December 27, 2007               [Page 1]

Internet-Draft    Media Description for IKE in the SDP         June 2007


Abstract

   This document extends the protocol identifier of SDP so that it could
   negotiate the use of IKE for media session in SDP offer/answer model.
   And it also specifies the method to generate VPN based on tunnel mode
   IPsec using self-signed certificate under the mechanism of comedia-
   tls.  This document extends RFC 4572.  In addition, it defines a new
   attribute "udp-setup", which is similar to "setup" attribute defined
   in RFC 4145, to enable endpoints to negotiate their roles in the IKE
   session.









































Saito & Wing            Expires December 27, 2007               [Page 2]

Internet-Draft    Media Description for IKE in the SDP         June 2007


Conventions used in this document

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


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Problem Statement  . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Approach to Solution . . . . . . . . . . . . . . . . . . .  4
   2.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Protocol Identifiers . . . . . . . . . . . . . . . . . . . . .  8
   4.  Example of SDP Offer and Answer Exchange . . . . . . . . . . .  9
   5.  Application to IKE . . . . . . . . . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Appendix A.  Changes since draft-saito-mmusic-sdp-ike-00 . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16



























Saito & Wing            Expires December 27, 2007               [Page 3]

Internet-Draft    Media Description for IKE in the SDP         June 2007


1.  Introduction

   In this section, the background of the problem in accessing home
   network which this document tries to solve, and the approach to the
   solution are described.

1.1.  Problem Statement

   When a device outside the home network connects to another device
   inside the home network, it often becomes a problem to traverse a NAT
   (Network Address Translation) device between them.  One of the
   effective solutions for this problem is VPN remote access to the NAT
   device, usually a home router.  With this approach, once the external
   device participates in the home network securely, it will be easy to
   establish connections with all the devices inside the home.  However,
   because a global IP address of the home router is not always fixed,
   it is necessary to make use of an effective name resolution
   mechanism.

   On the other hand, there is also a problem how a remote client and a
   home router authenticate each other over IKE [RFC4306] which
   establishes VPN.  It wouldn't be always possible that both parties
   exchange a pre-shared key securely in advance.  It would be also
   impractical to distribute authentication certificates signed by well-
   known root certification authority (CA) to all the devices because of
   their cost and administrative overhead, and after all, it is
   inefficient to publish a temporary certificate to the device which
   does not have a fixed IP address or hostname.  Therefore, if it is
   possible to use a self-signed certificate for authentication
   securely, that will be one of the effective solutions in this case.

1.2.  Approach to Solution

   As for the name resolution mechanism noted in 1.1, SIP [RFC3261] is
   one of the possible protocols.  Today, SIP is applied to not only
   VoIP but also various applications and recognized as a general
   protocol for session initiation.  Therefore, it can be used to
   initiate VPN sessions, too.

   On the other hand, there is also a specification which uses a self-
   signed certificate for authentication in the SIP/SDP [RFC4566]
   framework.  Actually, comedia-tls [RFC4572] specifies the method to
   exchange a fingerprint of self-signed certificate to establish a TLS
   [RFC4346] connection.  This specification defines a mechanism that
   allows self-signed certificates can be used securely, provided that
   the integrity of the SDP description is assured.  Because a
   certificate itself can be used for authentication not only in TLS but
   also in IKE which is used to launch VPN, this mechanism will be



Saito & Wing            Expires December 27, 2007               [Page 4]

Internet-Draft    Media Description for IKE in the SDP         June 2007


   applied to the establishment of VPN based on tunnel mode IPsec by
   extending the protocol identifier of SDP so that it could specify
   IKE.

   One of the easy methods to protect the integrity of SDP description,
   which is the premise of this spec, is to use SIP identity [RFC4474]
   mechanism.  This approach is also referred in
   [I-D.fischl-sipping-media-dtls].  Because SIP identity mechanism can
   protect the integrity of a body part as well as the value of From
   header in a SIP request by a valid Identity header, the receiver of
   the request can establish the secure IPsec connections with the
   sender by confirming that the hash value of the certificate sent
   during IKE negotiation matches the fingerprint in the SDP.  Although
   SIP identity does not protect the identity of the receiver of the SIP
   request, SIP connected identity [RFC4916] does it.

   Considering above background, this document defines a new media
   format "IKE" which can be used when the protocol identifier is "UDP"
   to enable the negotiation of using IKE for media session over SDP
   exchange on condition that the integrity of SDP description is
   assured.  And it also specifies the method to generate VPN based on
   tunnel mode IPsec by exchanging fingerprints of self-signed
   certificates following comedia-tls, and notes the example of SDP
   offer/answer [RFC3264] and the points which implementation should
   take care.  In addition, it defines an attribute "udp-setup" for UDP
   media sessions, similar to the "setup" attribute for TCP-based media
   transport defined in RFC 4145 [RFC4145].  It is used to negotiate the
   role of each endpoint in the IKE session.























Saito & Wing            Expires December 27, 2007               [Page 5]

Internet-Draft    Media Description for IKE in the SDP         June 2007


2.  Protocol Overview

   As shown in Figure 1, for example, there is a case of VPN remote
   access from a device outside the home to the home router whose IP
   address is not fixed.  In this case, the external device, a remote
   client recognizes Address of Record of the home router, but does not
   have any information about its contact address and certificate.
   Generally, it is difficult to establish tunnel mode IPsec dynamically
   and securely in this situation.  However as specified in comedia-tls,
   if the integrity of SDP session descriptions is assured, it is
   possible for the home router and the remote client to have a prior
   relationship with each other by exchanging certificate fingerprints,
   secure one-way hashes of the DER (distinguished encoding rules) form
   of the certificates.

                   REGISTRATION  +----------+  REGISTRATION
                       (1)       |   SIP    |      (1)
                     +---------->|  Proxy   |<------+
                     |  +------->|          |-----+ |
                     |  |INVITE  +----------+     | |
                     |  |  (2)                    | |  +--------+
                     |  |                         V |  |   Home |
               +----------+  IKE(Media Session) +--------+ Net. |
               |          |<--------(3)-------->| Home   |      |
               | Remote   |                     | Router |      |
               | Client   ==========(4)====================     |
               |          |  Tunnel Mode IPsec  +--------+      |
               +----------+                            |        |
                                                       +--------+

                  Figure 1: Remote Access to Home Network

   1.  Both Remote Client and Home Router generate secure signaling
       channels.  They may REGISTER to SIP Proxy using TLS.

   2.  Both Remote Client (SDP offerer) and Home Router (SDP answerer)
       exchange the fingerprints of their self-signed certificates in
       SDP during an INVITE transaction.

   3.  After SDP exchange, Remote Client (SDP offerer) initiates IKE
       with the SDP answerer to establish tunnel mode IPsec.  Both the
       offerer and the answerer validate that the certificate presented
       in the IKE exchange has a fingerprint that matches the
       fingerprint from SDP.  If they match, IKE negotiation proceeds as
       normal.

   4.  Remote Client joins in the Home Network.




Saito & Wing            Expires December 27, 2007               [Page 6]

Internet-Draft    Media Description for IKE in the SDP         June 2007


   Using this method, the self-signed certificates of both parties are
   used for authentication in IKE, but SDP itself is not concerned with
   all the negotiations related to key-exchange such as those of
   encryption and authentication algorithms.  These negotiations are up
   to IKE.  And in many cases that tunnel mode IPsec is used for remote
   access, a remote client needs to obtain a private address inside the
   home network dynamically while initiating the remote access,
   therefore IPsec security policy also needs to be set dynamically at
   the same time.  However, such a management function of security
   policy is on the responsibility of the high-level VPN application.
   SDP is not concerned with it.  The roles of SDP here are to determine
   the IP addresses of both parties used for IKE connection with c-line
   in SDP, and exchange fingerprints of certificates used for
   authentication in IKE with fingerprint attribute in SDP.

   If the high-level application thinks a VPN session as the media
   session, it will discard the security policy and terminate IKE when
   that media session is terminated by BYE request.  But each party can
   cache the certificate of the other party as described in Security
   Consideration of comedia-tls.

   The above example is for tunnel mode IPsec used for remote access,
   but the actual usage of negotiated IPsec is not limited.  For
   example, IKE can negotiate transport mode IPsec to encrypt multiple
   media sessions between two parties with only a pair of IPsec security
   associations.  Only one thing that SDP offer/answer model is
   responsible for is to exchange the fingerprints of certificates used
   for IKE, therefore, it does not take care of security policy.























Saito & Wing            Expires December 27, 2007               [Page 7]

Internet-Draft    Media Description for IKE in the SDP         June 2007


3.  Protocol Identifiers

   This document defines a new media format description "IKE", which can
   be used when the protocol identifier is "UDP" and indicates that the
   described media is IKE.  Both offerer and answerer can negotiate IKE
   by specifying "UDP" in the "proto" field and "IKE" in the "fmt" field
   in SDP.

   In addition, this document defines a new attribute "udp-setup", which
   can be used when the protocol identifier is "UDP" and the "fmt" field
   is "IKE", in order to describe how endpoints should perform the IKE
   session setup procedure.  The "udp-setup" attribute indicates which
   of the end points should initiate the IKE session establishment.  The
   "udp-setup" attribute is charset-independent and can be a session-
   level or a media-level attribute.  The following is the ABNF of the
   "udp-setup" attribute.

      udp-setup-attr = "a=udp-setup:" role
      role           = "active" / "passive" / "actpass"

      'active'  : The endpoint will initiate an outgoing session.
      'passive' : The endpoint will accept an incoming session.
      'actpass' : The endpoint is willing to accept an incoming
                  session or to initiate an outgoing session.

   As defined in 4.1 of RFC 4145, both endpoints negotiate the value of
   "udp-setup" using the offer/answer model.  However, "holdconn"
   defined in RFC 4145 is not defined here because UDP doesn't establish
   a connection.

      Offer       Answer
      ----------------------------
      active      passive
      passive     active
      actpass     active / passive

   The semantics of "active", "passive", and "actpass" in the offer/
   answer exchange is the same as the definition described in 4.1 of RFC
   4145.  The default value of the udp-setup attribute is "active" in
   the offer and "passive" in the answer.











Saito & Wing            Expires December 27, 2007               [Page 8]

Internet-Draft    Media Description for IKE in the SDP         June 2007


4.  Example of SDP Offer and Answer Exchange

   The example of SDP exchanged to negotiate IKE following this
   specification is as follows.

   (Note: due to RFC formatting conventions, this document splits SDP
   across lines whose content would exceed 72 characters.  A backslash
   character marks where this line folding has taken place.  This
   backslash and its trailing CRLF and whitespace would not appear in
   actual SDP content.)

   offer SDP
      ...
      m=application 500 UDP IKE
      c=IN IP4 192.0.2.10
      a=udp-setup:active
      a=fingerprint:SHA-1 \
      4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
      ...

   answer SDP
      ...
      m=application 500 UDP IKE
      c=IN IP4 192.0.2.20
      a=udp-setup:passive
      a=fingerprint:SHA-1 \
      D2:9F:6F:1E:CD:D3:09:E8:70:65:1A:51:7C:9D:30:4F:21:E4:4A:8E
      ...

   Following comedia-tls specification, the fingerprint attribute may be
   either a session-level or a media-level SDP attribute.  If it is a
   session-level attribute, it applies to all IKE sessions and TLS
   sessions for which no media-level fingerprint attribute is defined.


















Saito & Wing            Expires December 27, 2007               [Page 9]

Internet-Draft    Media Description for IKE in the SDP         June 2007


5.  Application to IKE

   After sharing fingerprints of both parties securely over the SDP
   exchange, SDP offerer MAY start the IKE session to the other party.
   To follow this specification, digital signature MUST be chosen as an
   authentication method in IKE phase 1.  In this process, certificate
   whose hashed value matches the fingerprint exchanged over SDP MUST be
   used.  If the certificate used in IKE does not match the original
   fingerprint, the endpoint MUST terminate the IKE session with
   detecting an authentication failure.

   In addition, each party MUST present a certificate and be
   authenticated by each other.






































Saito & Wing            Expires December 27, 2007              [Page 10]

Internet-Draft    Media Description for IKE in the SDP         June 2007


6.  Security Considerations

   This entire document concerns itself with security, but the security
   considerations applicable to SDP in general is described in SDP
   specification.  And the security issues which should be considered in
   using comedia-tls are described in Section 7 in its specification.
   This section describes the security considerations specific in the
   negotiation of IKE using comedia-tls.

   Offering IKE in SDP (or agreeing to one in SDP offer/answer mode)
   does not create an obligation for an endpoint to accept any IKE
   session with the given fingerprint.  On the other hand, the endpoint
   must engage in the standard IKE negotiation procedure to ensure that
   the IPsec security associations (including encryption and
   authentication algorithms) chosen meet the security requirements of
   VPN that the higher-level application needs.  When IKE has finished
   negotiating, the decision to conclude IKE and establish an IPsec
   security association with the remote peer is entirely the decision of
   each endpoint.  This procedure is similar to how VPNs are typically
   established in the absence of SIP.

   In the general authentication process in IKE, subject DN or
   subjectAltName is recognized as the identity of the remote party.
   However by using SIP identity and SIP connected identity mechanisms
   in this spec, certificates are used just as a carrier for the public
   keys of the peers and there is no need for the information about who
   is the signer of the certificate and whom subject DN indicates.

   In this document, the purpose of using IKE is launching the IPsec
   tunnel for VPN, and not for the security mechanism of RTP and RTCP
   packets.  Actually, this mechanism cannot provide end-to-end security
   inside the virtual private network as long as using tunnel mode
   IPsec, therefore other security methods such as SRTP must be used to
   secure them.

















Saito & Wing            Expires December 27, 2007              [Page 11]

Internet-Draft    Media Description for IKE in the SDP         June 2007


7.  IANA Considerations

   This document defines a session and media level SDP attribute, "udp-
   setup".  This attribute should be registered by the IANA under
   "Session Description Protocol (SDP) Parameters" under "att-field
   (both session and media level)".

   This document defines a media format "IKE".  This media format value
   should be registered by the IANA.  A media format "IKE" is associated
   with a proto value "UDP".









































Saito & Wing            Expires December 27, 2007              [Page 12]

Internet-Draft    Media Description for IKE in the SDP         June 2007


8.  References

8.1.  Normative References

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

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              June 2002.

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC4572]  Lennox, J., "Connection-Oriented Media Transport over the
              Transport Layer Security (TLS) Protocol in the Session
              Description Protocol (SDP)", RFC 4572, July 2006.

8.2.  Informative References

   [I-D.fischl-sipping-media-dtls]
              Fischl, J., "Datagram Transport Layer Security (DTLS)
              Protocol for Protection of Media  Traffic Established with
              the Session Initiation Protocol",
              draft-fischl-sipping-media-dtls-02 (work in progress),
              March 2007.

   [RFC4145]  Yon, D. and G. Camarillo, "TCP-Based Media Transport in
              the Session Description Protocol (SDP)", RFC 4145,
              September 2005.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

   [RFC4474]  Peterson, J. and C. Jennings, "Enhancements for
              Authenticated Identity Management in the Session
              Initiation Protocol (SIP)", RFC 4474, August 2006.

   [RFC4916]  Elwell, J., "Connected Identity in the Session Initiation
              Protocol (SIP)", RFC 4916, June 2007.



Saito & Wing            Expires December 27, 2007              [Page 13]

Internet-Draft    Media Description for IKE in the SDP         June 2007


Appendix A.  Changes since draft-saito-mmusic-sdp-ike-00

   Instruction to RFC Editor: please remove this section prior to
   publication as an RFC

   o  Added that SIP identity and SIP connected identity mechanisms can
      be used to protect the integrity of SDP to 1.2.

   o  The port number 9500 in the m-line of the offer SDP described in
      the chapter 4 was corrected to 500.

   o  Clarified that the security consideration to the establishment of
      VPN between an offerer and an answerer was the same as that of
      general VPN, added that the information about signer and owner of
      the certificate would be unnecessary for security by using SIP
      identity and SIP connected identity mechanisms with this spec and
      deleted the previous description about identity in Chapter 6.

   o  Minor grammatical edits.
































Saito & Wing            Expires December 27, 2007              [Page 14]

Internet-Draft    Media Description for IKE in the SDP         June 2007


Authors' Addresses

   Makoto Saito
   NTT Communications
   3-20-2 Nishi-Shinjuku, Shinjuku-ku
   Tokyo  163-1421
   Japan

   Email: ma.saito@nttv6.jp


   Dan Wing
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134
   United States

   Email: dwing@cisco.com

































Saito & Wing            Expires December 27, 2007              [Page 15]

Internet-Draft    Media Description for IKE in the SDP         June 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).





Saito & Wing            Expires December 27, 2007              [Page 16]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/