< draft-ietf-sip-domain-certs-06.txt   draft-ietf-sip-domain-certs-07.txt >
SIP V. Gurbani SIP V. Gurbani
Internet-Draft Bell Laboratories, Alcatel-Lucent Internet-Draft Bell Laboratories, Alcatel-Lucent
Updates: RFC3261 S. Lawrence Updates: RFC3261 S. Lawrence
(if approved) Avaya, Inc. (if approved) Avaya, Inc.
Intended status: Standards Track A. Jeffrey Intended status: Standards Track A. Jeffrey
Expires: September 23, 2010 Bell Laboratories, Alcatel-Lucent Expires: November 6, 2010 Bell Laboratories, Alcatel-Lucent
March 22, 2010 May 05, 2010
Domain Certificates in the Session Initiation Protocol (SIP) Domain Certificates in the Session Initiation Protocol (SIP)
draft-ietf-sip-domain-certs-06 draft-ietf-sip-domain-certs-07
Abstract Abstract
This document describes how to construct and interpret certain This document describes how to construct and interpret certain
information in a X.509 PKIX-compliant certificate for use in a information in a X.509 PKIX-compliant certificate for use in a
Session Initiation Protocol (SIP) over Transport Layer Security (TLS) Session Initiation Protocol (SIP) over Transport Layer Security (TLS)
connection. More specifically, this document describes how to encode connection. More specifically, this document describes how to encode
and extract the identity of a SIP domain in a certificate and how to and extract the identity of a SIP domain in a certificate and how to
use that identity for SIP domain authentication. As such, this use that identity for SIP domain authentication. As such, this
document is relevant both to implementors of SIP and to issuers of document is relevant both to implementors of SIP and to issuers of
skipping to change at page 1, line 46 skipping to change at page 1, line 46
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 23, 2010. This Internet-Draft will expire on November 6, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3
4. SIP domain to host resolution . . . . . . . . . . . . . . . . 6 4. SIP domain to host resolution . . . . . . . . . . . . . . . . 5
5. The need for mutual interdomain authentication . . . . . . . . 7 5. The need for mutual interdomain authentication . . . . . . . . 6
6. Certificate usage by a SIP service provider . . . . . . . . . 8 6. Certificate usage by a SIP service provider . . . . . . . . . 7
7. Behavior of SIP entities . . . . . . . . . . . . . . . . . . . 9 7. Behavior of SIP entities . . . . . . . . . . . . . . . . . . . 8
7.1. Finding SIP Identities in a Certificate . . . . . . . . . 9 7.1. Finding SIP Identities in a Certificate . . . . . . . . . 8
7.2. Comparing SIP Identities . . . . . . . . . . . . . . . . . 10 7.2. Comparing SIP Identities . . . . . . . . . . . . . . . . . 9
7.3. Client behavior . . . . . . . . . . . . . . . . . . . . . 11 7.3. Client behavior . . . . . . . . . . . . . . . . . . . . . 10
7.4. Server behavior . . . . . . . . . . . . . . . . . . . . . 12 7.4. Server behavior . . . . . . . . . . . . . . . . . . . . . 11
7.5. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . 13 7.5. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . 12
7.6. Registrar behavior . . . . . . . . . . . . . . . . . . . . 13 7.6. Registrar behavior . . . . . . . . . . . . . . . . . . . . 12
7.7. Redirect server behavior . . . . . . . . . . . . . . . . . 13 7.7. Redirect server behavior . . . . . . . . . . . . . . . . . 12
7.8. Virtual SIP Servers and Certificate Content . . . . . . . 13 7.8. Virtual SIP Servers and Certificate Content . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8.1. Connection authentication using Digest . . . . . . . . . . 14 8.1. Connection authentication using Digest . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Editorial guidance (non-normative) . . . . . . . . . 16 Appendix A. Editorial guidance (non-normative) . . . . . . . . . 15
A.1. Additions . . . . . . . . . . . . . . . . . . . . . . . . 17 A.1. Additions . . . . . . . . . . . . . . . . . . . . . . . . 16
A.2. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 17 A.2. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 16
A.2.1. 26.3.1 . . . . . . . . . . . . . . . . . . . . . . . . 17 A.2.1. 26.3.1 . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Terminology 1. Terminology
1.1. Key Words 1.1. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
Additional definition(s): Additional definition(s):
skipping to change at page 8, line 9 skipping to change at page 7, line 9
precedence when there are multiple names identifying the holder of precedence when there are multiple names identifying the holder of
the certificate. the certificate.
The authentication problem for Proxy-A is straightforward: in the The authentication problem for Proxy-A is straightforward: in the
certificate Proxy-A receives from Proxy-B, Proxy-A looks for an certificate Proxy-A receives from Proxy-B, Proxy-A looks for an
identity that is a SIP URI ("sip:example.net") or a DNS name identity that is a SIP URI ("sip:example.net") or a DNS name
("example.net") that asserts Proxy-B's authority over the example.net ("example.net") that asserts Proxy-B's authority over the example.net
domain. Normative behavior for a TLS client like Proxy-A is domain. Normative behavior for a TLS client like Proxy-A is
specified in Section 7.3. specified in Section 7.3.
The problem for Proxy-B is slightly more complex since it accepted The problem for Proxy-B is slightly more complex since it accepts the
the TLS request passively. Thus, Proxy-B does not possess an TLS request passively. Thus, Proxy-B does not possess an equivalent
equivalent AUS that it can use as an anchor in matching identities AUS that it can use as an anchor in matching identities from
from Proxy-A's certificate. Proxy-A's certificate.
RFC 3261 [2] section 26.3.2.2 only tells Proxy-B to "compare the RFC 3261 [2] section 26.3.2.2 only tells Proxy-B to "compare the
domain asserted by the certificate with the 'domainname' portion domain asserted by the certificate with the 'domainname' portion
of the From header field in the INVITE request." The difficulty of the From header field in the INVITE request." The difficulty
with that instruction is that the domainname in the From header with that instruction is that the domainname in the From header
field is not always that of the domain from which the request is field is not always that of the domain from which the request is
received. received.
The normative behavior for a TLS server like Proxy-B that passively The normative behavior for a TLS server like Proxy-B that passively
accepts a TLS connection and requires authentication of the sending accepts a TLS connection and requires authentication of the sending
 End of changes. 6 change blocks. 
48 lines changed or deleted 36 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/