< draft-saintandre-tls-server-id-check-13.txt   draft-saintandre-tls-server-id-check-14.txt >
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track J. Hodges Intended status: Standards Track J. Hodges
Expires: July 9, 2011 PayPal Expires: July 16, 2011 PayPal
January 5, 2011 January 12, 2011
Representation and Verification of Domain-Based Application Service Representation and Verification of Domain-Based Application Service
Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Identity within Internet Public Key Infrastructure Using X.509 (PKIX)
Certificates in the Context of Transport Layer Security (TLS) Certificates in the Context of Transport Layer Security (TLS)
draft-saintandre-tls-server-id-check-13 draft-saintandre-tls-server-id-check-14
Abstract Abstract
Many application technologies enable secure communication between two Many application technologies enable secure communication between two
entities by means of Internet Public Key Infrastructure Using X.509 entities by means of Internet Public Key Infrastructure Using X.509
(PKIX) certificates in the context of Transport Layer Security (TLS). (PKIX) certificates in the context of Transport Layer Security (TLS).
This document specifies procedures for representing and verifying the This document specifies procedures for representing and verifying the
identity of application services in such interactions. identity of application services in such interactions.
Status of this Memo Status of this Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on July 9, 2011. This Internet-Draft will expire on July 16, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 2, line 33 skipping to change at page 2, line 33
2.2. DNS Domain Names . . . . . . . . . . . . . . . . . . . . . 15 2.2. DNS Domain Names . . . . . . . . . . . . . . . . . . . . . 15
2.3. Subject Naming in PKIX Certificates . . . . . . . . . . . 16 2.3. Subject Naming in PKIX Certificates . . . . . . . . . . . 16
2.3.1. Implementation Notes . . . . . . . . . . . . . . . . . 17 2.3.1. Implementation Notes . . . . . . . . . . . . . . . . . 17
3. Designing Application Protocols . . . . . . . . . . . . . . . 18 3. Designing Application Protocols . . . . . . . . . . . . . . . 18
4. Representing Server Identity . . . . . . . . . . . . . . . . . 19 4. Representing Server Identity . . . . . . . . . . . . . . . . . 19
4.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 20
5. Requesting Server Certificates . . . . . . . . . . . . . . . . 21 5. Requesting Server Certificates . . . . . . . . . . . . . . . . 21
6. Verifying Service Identity . . . . . . . . . . . . . . . . . . 22 6. Verifying Service Identity . . . . . . . . . . . . . . . . . . 22
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2. Constructing a List of Reference Identifiers . . . . . . . 22 6.2. Constructing a List of Reference Identifiers . . . . . . . 23
6.2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 22 6.2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 24 6.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 25
6.3. Preparing to Seek a Match . . . . . . . . . . . . . . . . 25 6.3. Preparing to Seek a Match . . . . . . . . . . . . . . . . 25
6.4. Matching the DNS Domain Name Portion . . . . . . . . . . . 26 6.4. Matching the DNS Domain Name Portion . . . . . . . . . . . 27
6.4.1. Checking of Traditional Domain Names . . . . . . . . . 27 6.4.1. Checking of Traditional Domain Names . . . . . . . . . 27
6.4.2. Checking of Internationalized Domain Names . . . . . . 27 6.4.2. Checking of Internationalized Domain Names . . . . . . 27
6.4.3. Checking of Wildcard Certificates . . . . . . . . . . 27 6.4.3. Checking of Wildcard Certificates . . . . . . . . . . 27
6.4.4. Checking of Common Names . . . . . . . . . . . . . . . 28 6.4.4. Checking of Common Names . . . . . . . . . . . . . . . 28
6.5. Matching the Application Type Portion . . . . . . . . . . 28 6.5. Matching the Application Type Portion . . . . . . . . . . 29
6.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . . 28 6.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . . 29
6.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . . 29 6.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . . 29
6.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . . 29 6.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . . 29
6.6.2. Case #2: No Match Found, Pinned Certificate . . . . . 29 6.6.2. Case #2: No Match Found, Pinned Certificate . . . . . 29
6.6.3. Case #3: No Match Found, No Pinned Certificate . . . . 29 6.6.3. Case #3: No Match Found, No Pinned Certificate . . . . 30
6.6.4. Fallback . . . . . . . . . . . . . . . . . . . . . . . 29 6.6.4. Fallback . . . . . . . . . . . . . . . . . . . . . . . 30
7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7.1. Pinned Certificates . . . . . . . . . . . . . . . . . . . 30 7.1. Pinned Certificates . . . . . . . . . . . . . . . . . . . 30
7.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 30 7.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 31
7.3. Internationalized Domain Names . . . . . . . . . . . . . . 32 7.3. Internationalized Domain Names . . . . . . . . . . . . . . 32
7.4. Multiple Identifiers . . . . . . . . . . . . . . . . . . . 32 7.4. Multiple Identifiers . . . . . . . . . . . . . . . . . . . 32
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
11.1. Normative References . . . . . . . . . . . . . . . . . . . 33 11.1. Normative References . . . . . . . . . . . . . . . . . . . 34
11.2. Informative References . . . . . . . . . . . . . . . . . . 34 11.2. Informative References . . . . . . . . . . . . . . . . . . 35
Appendix A. Sample Text . . . . . . . . . . . . . . . . . . . . . 39 Appendix A. Sample Text . . . . . . . . . . . . . . . . . . . . . 40
Appendix B. Prior Art . . . . . . . . . . . . . . . . . . . . . . 41 Appendix B. Prior Art . . . . . . . . . . . . . . . . . . . . . . 41
B.1. IMAP, POP3, and ACAP (1999) . . . . . . . . . . . . . . . 41 B.1. IMAP, POP3, and ACAP (1999) . . . . . . . . . . . . . . . 41
B.2. HTTP (2000) . . . . . . . . . . . . . . . . . . . . . . . 42 B.2. HTTP (2000) . . . . . . . . . . . . . . . . . . . . . . . 42
B.3. LDAP (2000/2006) . . . . . . . . . . . . . . . . . . . . . 43 B.3. LDAP (2000/2006) . . . . . . . . . . . . . . . . . . . . . 44
B.4. SMTP (2002/2007) . . . . . . . . . . . . . . . . . . . . . 46 B.4. SMTP (2002/2007) . . . . . . . . . . . . . . . . . . . . . 47
B.5. XMPP (2004) . . . . . . . . . . . . . . . . . . . . . . . 48 B.5. XMPP (2004) . . . . . . . . . . . . . . . . . . . . . . . 48
B.6. NNTP (2006) . . . . . . . . . . . . . . . . . . . . . . . 49 B.6. NNTP (2006) . . . . . . . . . . . . . . . . . . . . . . . 49
B.7. NETCONF (2006/2009) . . . . . . . . . . . . . . . . . . . 50 B.7. NETCONF (2006/2009) . . . . . . . . . . . . . . . . . . . 50
B.8. Syslog (2009) . . . . . . . . . . . . . . . . . . . . . . 51 B.8. Syslog (2009) . . . . . . . . . . . . . . . . . . . . . . 52
B.9. SIP (2010) . . . . . . . . . . . . . . . . . . . . . . . . 52 B.9. SIP (2010) . . . . . . . . . . . . . . . . . . . . . . . . 53
B.10. SNMP (2010) . . . . . . . . . . . . . . . . . . . . . . . 53 B.10. SNMP (2010) . . . . . . . . . . . . . . . . . . . . . . . 53
B.11. GIST (2010) . . . . . . . . . . . . . . . . . . . . . . . 54 B.11. GIST (2010) . . . . . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
1.1. Motivation 1.1. Motivation
The visible face of the Internet largely consists of services that The visible face of the Internet largely consists of services that
employ a client-server architecture in which an interactive or employ a client-server architecture in which an interactive or
skipping to change at page 21, line 43 skipping to change at page 21, line 43
This section provides rules and guidelines for service providers This section provides rules and guidelines for service providers
regarding the information to include in certificate signing requests regarding the information to include in certificate signing requests
(CSRs). (CSRs).
In general, service providers are encouraged to request certificates In general, service providers are encouraged to request certificates
that include all of the identifier types that are required or that include all of the identifier types that are required or
recommended for the application service type that will be secured recommended for the application service type that will be secured
using the certificate to be issued. using the certificate to be issued.
If the certificate will be used for only a single application service If the certificate might be used for any type of application service,
type, then the service provider is encouraged to request a then the service provider is encouraged to request a certificate that
includes only a DNS-ID.
If the certificate will be used for only a single type of application
service, then the service provider is encouraged to request a
certificate that includes a DNS-ID and, if appropriate for the certificate that includes a DNS-ID and, if appropriate for the
service type, an SRV-ID or URI-ID that limits the deployment scope of service type, an SRV-ID or URI-ID that limits the deployment scope of
the certificate to only the defined service type. the certificate to only the defined service type.
If the certificate will be used for multiple application service If a service provider offering multiple service types (e.g., a world
types, then the service provider is discouraged from requesting one wide web service, an email service, and an instant messaging service)
certificate with multiple kinds of SRV-IDs or URI-IDs identifying wishes to limit the applicability of certificates using SRV-IDs or
each different application service type. Instead, the service URI-IDs, then the service provider is encouraged to request multiple
provider is encouraged to request either (a) one certificate per certificates, i.e., one certificate per service type. Conversely,
service type or (b) a single certificate that contains only an the service provider is discouraged from requesting a single
identifier type of DNS-ID representing the DNS domain name(s) for the certificate containing multiple SRV-IDs or URI-IDs identifying each
provided service(s). different application service type. This guideline does not apply to
service type "bundles" that are used to identify manifold distinct
access methods to the same underlying application (e.g., an email
application with access methods denoted by the service types of
"imap", "imaps", "pop3", "pop3s", and "submission" as described in
[EMAIL-SRV]).
6. Verifying Service Identity 6. Verifying Service Identity
This section provides rules and guidelines for implementers of This section provides rules and guidelines for implementers of
application client software regarding algorithms for verification of application client software regarding algorithms for verification of
application service identity. application service identity.
6.1. Overview 6.1. Overview
At a high level, the client verifies the application service's At a high level, the client verifies the application service's
skipping to change at page 25, line 6 skipping to change at page 25, line 17
other than those of type Common Name and MUST NOT check for RDNs other than those of type Common Name and MUST NOT check for RDNs
other than those of type Common Name in the presented identifiers. other than those of type Common Name in the presented identifiers.
6.2.2. Examples 6.2.2. Examples
A web browser that is connecting via HTTPS to the website at A web browser that is connecting via HTTPS to the website at
"www.example.com" might have two reference identifiers: a DNS-ID of "www.example.com" might have two reference identifiers: a DNS-ID of
"www.example.com" and, as a fallback, a CN-ID of "www.example.com". "www.example.com" and, as a fallback, a CN-ID of "www.example.com".
A mail user agent that is connecting via IMAP to the email service at A mail user agent that is connecting via IMAP to the email service at
"example.net" (resolved as "mail.example.net") might have two "example.net" (resolved as "mail.example.net") might have four
reference identifiers: an SRV-ID of "_imaps.example.net" (see reference identifiers: SRV-IDs of "_imaps.example.net" and
[EMAIL-SRV]) and a DNS-ID of "example.net". "_imaps.mail.example.net" (see [EMAIL-SRV]) and DNS-IDs of
"example.net" and "mail.example.net". (A legacy email user agent
would not support [EMAIL-SRV] and therefore would probably be
explicitly configured to connect to "mail.example.net", whereas an
SRV-aware user agent would derive "example.net" from an email address
of the form "user@example.net" but might also accept
"mail.example.net" as the DNS domain name portion of reference
identifiers for the service.)
A voice-over-IP (VoIP) user agent that is connecting via SIP to the A voice-over-IP (VoIP) user agent that is connecting via SIP to the
voice service at "voice.example.edu" might have only one reference voice service at "voice.example.edu" might have only one reference
identifier: a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]). identifier: a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]).
An instant messaging (IM) client that is connecting via XMPP to the An instant messaging (IM) client that is connecting via XMPP to the
IM service at "im.example.org" might have three reference IM service at "im.example.org" might have three reference
identifiers: an SRV-ID of "_xmpp-client.im.example.org" (see [XMPP]), identifiers: an SRV-ID of "_xmpp-client.im.example.org" (see [XMPP]),
a DNS-ID of "im.example.org", and an XMPP-specific "XmppAddr" of a DNS-ID of "im.example.org", and an XMPP-specific "XmppAddr" of
"im.example.org" (see [XMPP]). "im.example.org" (see [XMPP]).
skipping to change at page 28, line 11 skipping to change at page 28, line 29
against anything but the left-most label of the reference against anything but the left-most label of the reference
identifier (e.g., *.example.com would match foo.example.com but identifier (e.g., *.example.com would match foo.example.com but
not bar.foo.example.com or example.com). not bar.foo.example.com or example.com).
3. The client MAY match a presented identifier in which the wildcard 3. The client MAY match a presented identifier in which the wildcard
character is not the only character of the label (e.g., character is not the only character of the label (e.g.,
baz*.example.net and *baz.example.net and b*z.example.net would baz*.example.net and *baz.example.net and b*z.example.net would
be taken to match baz1.example.net and foobaz.example.net and be taken to match baz1.example.net and foobaz.example.net and
buzz.example.net, respectively). However, the client SHOULD NOT buzz.example.net, respectively). However, the client SHOULD NOT
attempt to match a presented identifier where the wildcard attempt to match a presented identifier where the wildcard
character is embedded within an NR-LDH label, A-label, or U-label character is embedded within an A-label or U-label [IDNA-DEFS] of
[IDNA-DEFS] of an internationalized domain name [IDNA-PROTO]. an internationalized domain name [IDNA-PROTO].
6.4.4. Checking of Common Names 6.4.4. Checking of Common Names
As noted, a client MUST NOT seek a match for a reference identifier As noted, a client MUST NOT seek a match for a reference identifier
of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, of CN-ID if the presented identifiers include a DNS-ID, SRV-ID,
URI-ID, or any application-specific identifier types supported by the URI-ID, or any application-specific identifier types supported by the
client. client.
Therefore, if and only if the presented identifiers do not include a Therefore, if and only if the presented identifiers do not include a
DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types
skipping to change at page 28, line 34 skipping to change at page 29, line 7
for a string whose form matches that of a fully-qualified DNS domain for a string whose form matches that of a fully-qualified DNS domain
name in a Common Name field of the subject field (i.e., a CN-ID). If name in a Common Name field of the subject field (i.e., a CN-ID). If
the client chooses to compare a reference identifier of type CN-ID the client chooses to compare a reference identifier of type CN-ID
against that string, it MUST follow the comparison rules for the DNS against that string, it MUST follow the comparison rules for the DNS
domain name portion of an identifier of type DNS-ID, SRV-ID, or domain name portion of an identifier of type DNS-ID, SRV-ID, or
URI-ID, as described under Section 6.4.1, Section 6.4.2, and URI-ID, as described under Section 6.4.1, Section 6.4.2, and
Section 6.4.3. Section 6.4.3.
6.5. Matching the Application Type Portion 6.5. Matching the Application Type Portion
When checking identifiers of type SRV-ID and URI-ID, a client SHOULD If a client supports checking of identifiers of type SRV-ID and
also check the service type of the application service with which it URI-ID, it MUST also check the service type of the application
communicates (in addition to checking the domain name as described service with which it communicates (in addition to checking the
above). This is a best practice because typically a client is not domain name as described above). This is a best practice because
designed to communicate with all kinds of services using all possible typically a client is not designed to communicate with all kinds of
application protocols, but instead is designed to communicate with services using all possible application protocols, but instead is
one kind of service, such as websites, email services, VoIP services, designed to communicate with one kind of service, such as websites,
or IM services. email services, VoIP services, or IM services.
The service type is verified by means of an SRV-ID or a URI-ID. The service type is verified by means of an SRV-ID or a URI-ID.
6.5.1. SRV-ID 6.5.1. SRV-ID
The service name portion of an SRV-ID (e.g., "imaps") MUST be matched The service name portion of an SRV-ID (e.g., "imaps") MUST be matched
in a case-insensitive manner, in accordance with [DNS-SRV]. Note in a case-insensitive manner, in accordance with [DNS-SRV]. Note
that the "_" character is prepended to the service identifier in DNS that the "_" character is prepended to the service identifier in DNS
SRV records and in SRV-IDs (per [SRVNAME]), and thus does not need to SRV records and in SRV-IDs (per [SRVNAME]), and thus does not need to
be included in any comparison. be included in any comparison.
skipping to change at page 31, line 38 skipping to change at page 32, line 9
* included as all or part of more than one label (e.g., * included as all or part of more than one label (e.g.,
*.*.example.com) *.*.example.com)
These ambiguities might introduce exploitable differences in These ambiguities might introduce exploitable differences in
identity checking behavior among client implementations and identity checking behavior among client implementations and
necessitate overly complex and inefficient identity checking necessitate overly complex and inefficient identity checking
algorithms. algorithms.
o There is no specification that defines how the wildcard character o There is no specification that defines how the wildcard character
may be embedded within the NR-LDH labels, A-labels, or U-labels may be embedded within the A-labels or U-labels [IDNA-DEFS] of an
[IDNA-DEFS] of an internationalized domain name [IDNA-PROTO]; as a internationalized domain name [IDNA-PROTO]; as a result,
result, implementations are strongly discouraged from including or implementations are strongly discouraged from including or
attempting to check for the wildcard character emdedded within NR- attempting to check for the wildcard character embedded within the
LDH labels, A-labels, or U-labels of an internationalized domain A-labels or U-labels of an internationalized domain name (e.g.,
name (e.g., "xn--kcry6tjko*.example.org"). Note, however, that a "xn--kcry6tjko*.example.org"). Note, however, that a presented
presented domain name identifier MAY contain the wildcard domain name identifier MAY contain the wildcard character as long
character as long as that character occupies the entire left-most as that character occupies the entire left-most label position,
label position, where some or all of the remaining labels are NR- where all of the remaining labels are valid NR-LDH labels,
LDH labels, A-labels, or U-labels (e.g., "*.xn-- A-labels, or U-labels (e.g., "*.xn--kcry6tjko.example.org").
kcry6tjko.example.org").
Notwithstanding the foregoing security considerations, specifications Notwithstanding the foregoing security considerations, specifications
that re-use this one can legitimately encourage continued support for that re-use this one can legitimately encourage continued support for
the wildcard character if they have good reasons to do so, such as the wildcard character if they have good reasons to do so, such as
backward compatibility with deployed infrastructure (see, for backward compatibility with deployed infrastructure (see, for
example, [EV-CERTS]). example, [EV-CERTS]).
7.3. Internationalized Domain Names 7.3. Internationalized Domain Names
Allowing internationalized domain names can lead to the inclusion of Allowing internationalized domain names can lead to the inclusion of
 End of changes. 17 change blocks. 
55 lines changed or deleted 70 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/