One document matched: draft-saito-mmusic-sdp-ike-00.txt
MMUSIC Working Group
Internet Draft M. Saito
Intended status: Standards Track NTT Communications
Expires: August 2007 D. Wing
Cisco Systems
February 2007
Media Description for IKE in the Session Description Protocol (SDP)
draft-saito-mmusic-sdp-ike-00
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.
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.
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 RFC-2119 [RFC2119].
Saito & Wing Expires - August 2007 [Page 1]
Media Description for IKE in the SDP February 2007
Table of Contents
1. Introduction..................................................2
1.1. Problem Statement........................................2
1.2. Approach to Solution.....................................3
2. Protocol Overview.............................................3
3. Protocol Identifiers..........................................5
4. Example of SDP Offer and Answer Exchange......................6
5. Application to IKE............................................6
6. Security Consideration........................................7
7. IANA Considerations...........................................7
8. References....................................................8
8.1. Normative References.....................................8
8.2. Informative References...................................8
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.
Saito & Wing Expires - August 2007 [Page 2]
Media Description for IKE in the SDP February 2007
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
applied to the establishment of VPN based on tunnel mode IPsec by
extending the protocol identifier of SDP so that it could specify
IKE.
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.
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.
Saito & Wing Expires - August 2007 [Page 3]
Media Description for IKE in the SDP February 2007
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.
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.
Saito & Wing Expires - August 2007 [Page 4]
Media Description for IKE in the SDP February 2007
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 security policy.
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 should endpoints 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
Saito & Wing Expires - August 2007 [Page 5]
Media Description for IKE in the SDP February 2007
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.
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 9500 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.
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, a self-signed
certificate that is an original of fingerprint exchanged over SDP
MUST be used. If the certificate used in IKE does not match the
Saito & Wing Expires - August 2007 [Page 6]
Media Description for IKE in the SDP February 2007
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.
6. Security Consideration
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.
In this specification, each endpoint MAY assert its SIP Address of
Record or IP address or FQDN as its identity in the subjectAltName
field in a certificate. However, when an endpoint receives a
certificate for IKE asserting an identity other than SIP Address of
Record without authenticity and integrity protection of SDP
descriptions, it SHOULD alert the user and ask for confirmation.
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.
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 - August 2007 [Page 7]
Media Description for IKE in the SDP February 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.
[RFC4306] C. Kaufman, Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A.
Johnston, J. Peterson, R. Sparks, M. Handley, and E.
Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[RFC4566] M. Handley, V. Jacobson, and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4572] J. Lennox, "Connection-Oriented Media Transport over
the Transport Layer Security (TLS) Protocol in the
Session Description Protocol (SDP)", RFC 4572, July
2006.
[RFC3264] Rosenberg, J., and Schulzrinne, H., "An Offer/Answer
Model with the Session Description Protocol (SDP)",
RFC 3264, June 2002.
8.2. Informative References
[RFC4346] T. Dierks, and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.1", RFC 4346, April
2006.
[RFC4145] D. Yon, and G. Camarillo, "TCP-Based Media Transport
in the Session Description Protocol (SDP)", RFC 4145,
September 2005.
Author's Addresses
Makoto Saito
NTT Communications
3-20-2 Nishi-Shinjuku, Shinjuku-ku
Tokyo 163-1421 Japan
Email: ma.saito@nttv6.jp
Saito & Wing Expires - August 2007 [Page 8]
Media Description for IKE in the SDP February 2007
Dan Wing
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134 United States
Email: dwing@cisco.com
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.
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.
Saito & Wing Expires - August 2007 [Page 9] | PAFTECH AB 2003-2026 | 2026-04-25 07:21:23 |