draft-ietf-stir-certificates-06.txt   draft-ietf-stir-certificates-07.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft Neustar Internet-Draft Neustar
Intended status: Standards Track S. Turner Intended status: Standards Track S. Turner
Expires: January 8, 2017 sn3rd Expires: January 9, 2017 sn3rd
July 7, 2016 July 8, 2016
Secure Telephone Identity Credentials: Certificates Secure Telephone Identity Credentials: Certificates
draft-ietf-stir-certificates-06.txt draft-ietf-stir-certificates-07.txt
Abstract Abstract
In order to prevent the impersonation of telephone numbers on the In order to prevent the impersonation of telephone numbers on the
Internet, some kind of credential system needs to exist that Internet, some kind of credential system needs to exist that
cryptographically proves authority over telephone numbers. This cryptographically proves authority over telephone numbers. This
document describes the use of certificates in establishing authority document describes the use of certificates in establishing authority
over telephone numbers, as a component of a broader architecture for over telephone numbers, as a component of a broader architecture for
managing telephone numbers as identities in protocols like SIP. managing telephone numbers as identities in protocols like SIP.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 January 8, 2017. This Internet-Draft will expire on January 9, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 14 skipping to change at page 2, line 14
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Authority for Telephone Numbers in Certificates . . . . . . . 3 3. Authority for Telephone Numbers in Certificates . . . . . . . 3
4. Certificate Usage . . . . . . . . . . . . . . . . . . . . . . 5 4. Certificate Usage . . . . . . . . . . . . . . . . . . . . . . 5
5. Enrollment and Authorization using the TN Authorization List 6 5. Enrollment and Authorization using the TN Authorization List 6
5.1. Certificate Extension Scope and Structure . . . . . . . . 7 5.1. Levels Of Assurance . . . . . . . . . . . . . . . . . . . 7
5.2. Certificate Extension Scope and Structure . . . . . . . . 8
6. Provisioning Private Keying Material . . . . . . . . . . . . 8 6. Provisioning Private Keying Material . . . . . . . . . . . . 8
7. Acquiring Credentials to Verify Signatures . . . . . . . . . 8 7. Acquiring Credentials to Verify Signatures . . . . . . . . . 9
8. Verifying Certificate Scope with TN Authorization List . . . 9 8. Verifying Certificate Scope with TN Authorization List . . . 10
9. Certificate Freshness and Revocation . . . . . . . . . . . . 11 9. Certificate Freshness and Revocation . . . . . . . . . . . . 11
9.1. Choosing a Verification Method . . . . . . . . . . . . . 11 9.1. Choosing a Verification Method . . . . . . . . . . . . . 12
9.2. Using OCSP with TN Auth List . . . . . . . . . . . . . . 12 9.2. Using OCSP with TN Auth List . . . . . . . . . . . . . . 13
9.2.1. OCSP Extension Specification . . . . . . . . . . . . 13 9.2.1. OCSP Extension Specification . . . . . . . . . . . . 13
9.3. Acquiring TN Lists By Reference . . . . . . . . . . . . . 15 9.3. Acquiring TN Lists By Reference . . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
12. Security Considerations . . . . . . . . . . . . . . . . . . . 17 12. Security Considerations . . . . . . . . . . . . . . . . . . . 17
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 20 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
The STIR problem statement [RFC7340] identifies the primary enabler The STIR problem statement [RFC7340] identifies the primary enabler
of robocalling, vishing, swatting and related attacks as the of robocalling, vishing, swatting and related attacks as the
capability to impersonate a calling party number. The starkest capability to impersonate a calling party number. The starkest
examples of these attacks are cases where automated callees on the examples of these attacks are cases where automated callees on the
PSTN rely on the calling number as a security measure, for example to PSTN rely on the calling number as a security measure, for example to
access a voicemail system. Robocallers use impersonation as a means access a voicemail system. Robocallers use impersonation as a means
of obscuring identity; while robocallers can, in the ordinary PSTN, of obscuring identity; while robocallers can, in the ordinary PSTN,
skipping to change at page 3, line 23 skipping to change at page 3, line 23
requirements, including extending X.509 with a Telephone Number requirements, including extending X.509 with a Telephone Number
Authorization List which binds certificates to authority for Authorization List which binds certificates to authority for
particular telephone numbers, or potentially telephone number blocks particular telephone numbers, or potentially telephone number blocks
or ranges. or ranges.
In the STIR in-band architecture specified in In the STIR in-band architecture specified in
[I-D.ietf-stir-rfc4474bis], two basic types of entities need access [I-D.ietf-stir-rfc4474bis], two basic types of entities need access
to these credentials: authentication services, and verification to these credentials: authentication services, and verification
services (or verifiers). An authentication service must be operated services (or verifiers). An authentication service must be operated
by an entity enrolled with the certification authority (CA, see by an entity enrolled with the certification authority (CA, see
Section 5), whereas a verifier need only trust the root certificate Section 5), whereas a verifier need only trust the trust anchor of
of the authority, and have a means to access and validate the public the authority, and have a means to access and validate the public
keys associated with these certificates. Although the guidance in keys associated with these certificates. Although the guidance in
this document is written with the STIR in-band architecture in mind, this document is written with the STIR in-band architecture in mind,
the credential system described in this document could be useful for the credential system described in this document could be useful for
other protocols that want to make use of certificates to prove other protocols that want to make use of certificates to prove
authority over telephone numbers on the Internet. authority over telephone numbers on the Internet.
This document specifies only the credential syntax and semantics This document specifies only the credential syntax and semantics
necessary to support this architecture. It does not assume any necessary to support this architecture. It does not assume any
particular CA or deployment environment. We anticipate that some particular CA or deployment environment. We anticipate that some
deployment experience will be necessary to determine optimal deployment experience will be necessary to determine optimal
skipping to change at page 5, line 9 skipping to change at page 5, line 10
verifier behavior and authorization decision that will change verifier behavior and authorization decision that will change
depending on the approach to telephone number authority taken by the depending on the approach to telephone number authority taken by the
certificate. For that reason, the two approaches are not mutually certificate. For that reason, the two approaches are not mutually
exclusive, and in fact a certificate issued to a traditional exclusive, and in fact a certificate issued to a traditional
telephone network service provider could contain a TN Authorization telephone network service provider could contain a TN Authorization
List or not, depending on the CA issuing the credential. Regardless List or not, depending on the CA issuing the credential. Regardless
of which approach is used, certificates that assert authority over of which approach is used, certificates that assert authority over
telephone numbers are subject to the ordinary operational procedures telephone numbers are subject to the ordinary operational procedures
that govern certificate use per [RFC5280]. This means that that govern certificate use per [RFC5280]. This means that
verification services must be mindful of the need to ensure that they verification services must be mindful of the need to ensure that they
trust the root certificate authority that issued the certificate, and trust the trust anchor that issued the certificate, and that they
that they have some means to determine the freshness of the have some means to determine the freshness of the certificate (see
certificate (see Section 9). Section 9).
4. Certificate Usage 4. Certificate Usage
[I-D.ietf-stir-rfc4474bis] requires that all credential systems used [I-D.ietf-stir-rfc4474bis] requires that all credential systems used
for signing the Identity header in SIP detail the following: for signing the Identity header in SIP detail the following:
1. The URI schemes permitted in the SIP Identity header "info" 1. The URI schemes permitted in the SIP Identity header "info"
parameter, as well as any special procedures required to parameter, as well as any special procedures required to
dereference the URIs. While normative text is given below in dereference the URIs. While normative text is given below in
Section 7, this mechanism permits the HTTP, CID and SIP URI Section 7, this mechanism permits the HTTP, CID and SIP URI
skipping to change at page 5, line 49 skipping to change at page 5, line 50
credentials. For this specification, that means the signature credentials. For this specification, that means the signature
algorithms used to sign certificates. This specification algorithms used to sign certificates. This specification
REQUIRES that implementations support both ECDSA with the P-256 REQUIRES that implementations support both ECDSA with the P-256
curve (see [RFC4754]) and RSA PKCS#1 v1.5 (see [RFC3447] curve (see [RFC4754]) and RSA PKCS#1 v1.5 (see [RFC3447]
Section 8.2) for certificate signatures. Implementers are Section 8.2) for certificate signatures. Implementers are
advised that RS256 is mandated only as a transitional mechanism, advised that RS256 is mandated only as a transitional mechanism,
due to its widespread use in existing PKI, but we anticipate that due to its widespread use in existing PKI, but we anticipate that
this mechanism will eventually be deprecated. this mechanism will eventually be deprecated.
5. Finally, note that all certificates compliant with this 5. Finally, note that all certificates compliant with this
specification MUST provide cryptographic keying material specification:
sufficient to generate the ECDSA using P-256 and SHA-256
signatures necessary to support the ES256 hashed signatures * MUST provide cryptographic keying material sufficient to
required by PASSporT [I-D.ietf-stir-passport], which in turn generate the ECDSA using P-256 and SHA-256 signatures
follows JSON Web Token (JWT) [RFC7519]. necessary to support the ES256 hashed signatures required by
PASSporT [I-D.ietf-stir-passport], which in turn follows JSON
Web Token (JWT) [RFC7519].
* MUST support both ECDSA with P-256 and RSA PKCS#1 v1.5 for
certificate signature verification.
This document also includes additional certificate-related
requirements:
o See Section 5.1 for requirements related to the certificate
policies extension.
o See Section 7 for requirements related to the TN Query certificate
extension.
o See Section 9.2 and Section 9.3 for requirements related to the
Authority Information Access (AIA) certificate extension.
o See Section 9.2.1 for requirements related to the authority key
identifier and subject key identifier certificate extensions.
5. Enrollment and Authorization using the TN Authorization List 5. Enrollment and Authorization using the TN Authorization List
This document assumes a threefold model for certificate enrollment This document assumes a threefold model for certificate enrollment
when using the TN Authorization List extension. when using the TN Authorization List extension.
The first enrollment model is one where the CA acts in concert with The first enrollment model is one where the CA acts in concert with
national numbering authorities to issue credentials to those parties national numbering authorities to issue credentials to those parties
to whom numbers are assigned. In the United States, for example, to whom numbers are assigned. In the United States, for example,
telephone number blocks are assigned to Local Exchange Carriers telephone number blocks are assigned to Local Exchange Carriers
skipping to change at page 7, line 7 skipping to change at page 7, line 27
100 numbers used by an IP PBX, and the organization might in turn 100 numbers used by an IP PBX, and the organization might in turn
delegate authority for a particular number to an individual employee. delegate authority for a particular number to an individual employee.
This is analogous to delegation of organizational identities in This is analogous to delegation of organizational identities in
traditional hierarchical PKIs who use the name constraints extension traditional hierarchical PKIs who use the name constraints extension
[RFC5280]; the root CA delegates names in sales to the sales [RFC5280]; the root CA delegates names in sales to the sales
department CA, names in development to the development CA, etc. As department CA, names in development to the development CA, etc. As
lengthy certificate delegation chains are brittle, however, and can lengthy certificate delegation chains are brittle, however, and can
cause delays in the verification process, this document considers cause delays in the verification process, this document considers
optimizations to reduce the complexity of verification. optimizations to reduce the complexity of verification.
Future versions of this specification may also discuss methods of
partial delegation, where certificate holders delegate only part of
their authority. For example, individual assignees may want to
delegate to a service authority for text messages associated with
their telephone number, but not for other functions.
5.1. Levels Of Assurance
This specification supports different level of assurance (LOA). The This specification supports different level of assurance (LOA). The
LOA indications, which are Object Identifiers (OIDs) included in the LOA indications, which are Object Identifiers (OIDs) included in the
certificate's certificate policies extension [RFC5280], allow CAs to certificate's certificate policies extension [RFC5280], allow CAs to
differentiate those enrolled from proof-of-possession versus differentiate those enrolled from proof-of-possession versus
delegation. A Certification Policy and a Certification Practice delegation. A Certification Policy and a Certification Practice
Statement [RFC3647] are produced as part of the normal PKI Statement [RFC3647] are produced as part of the normal PKI
bootstrapping process (i.e., the CP is written first and then the CAs bootstrapping process (i.e., the CP is written first and then the CAs
say how they conform to the CP in the CPS). OIDs are used to say how they conform to the CP in the CPS). OIDs are used to
reference the CP and if the CA wishes it can also include a reference reference the CP and if the CA wishes it can also include a reference
to the CPS with the certificate policies extension. CAs that wish to to the CPS with the certificate policies extension. CAs that wish to
express different LOAs MUST include the certificate policies express different LOAs MUST include the certificate policies
extension in issued certificates. See Section 11 for additional extension in issued certificates. See Section 11 for additional
information about the LOA registry. information about the LOA registry.
Future versions of this specification may also discuss methods of 5.2. Certificate Extension Scope and Structure
partial delegation, where certificate holders delegate only part of
their authority. For example, individual assignees may want to
delegate to a service authority for text messages associated with
their telephone number, but not for other functions.
5.1. Certificate Extension Scope and Structure
This specification places no limits on the number of telephone This specification places no limits on the number of telephone
numbers that can be associated with any given certificate. Some numbers that can be associated with any given certificate. Some
service providers may be assigned millions of numbers, and may wish service providers may be assigned millions of numbers, and may wish
to have a single certificate that is capable of signing for any one to have a single certificate that is capable of signing for any one
of those numbers. Others may wish to compartmentalize authority over of those numbers. Others may wish to compartmentalize authority over
subsets of the numbers they control. subsets of the numbers they control.
Moreover, service providers may wish to have multiple certificates Moreover, service providers may wish to have multiple certificates
with the same scope of authority. For example, a service provider with the same scope of authority. For example, a service provider
skipping to change at page 12, line 24 skipping to change at page 12, line 43
mechanisms to scope the size of the CRLs based on revocation reasons mechanisms to scope the size of the CRLs based on revocation reasons
(e.g., key compromise vs CA compromise), user certificates only, and (e.g., key compromise vs CA compromise), user certificates only, and
CA certificates only as well as just operationally deciding to keep CA certificates only as well as just operationally deciding to keep
the CRLs small. However, scoping the CRL introduces other issues the CRLs small. However, scoping the CRL introduces other issues
(i.e., does the RP have all of the CRL partitions). (i.e., does the RP have all of the CRL partitions).
CAs in the STIR architecture will likely all create CRLs for audit CAs in the STIR architecture will likely all create CRLs for audit
purposes, but it NOT RECOMMENDED that they be relying upon for status purposes, but it NOT RECOMMENDED that they be relying upon for status
information. Instead, one of the two "online" options is preferred. information. Instead, one of the two "online" options is preferred.
Between the two, OCSP is much more widely deployed and this document Between the two, OCSP is much more widely deployed and this document
therefore recommends the use of OCSP in high-volume environments for therefore recommends the use of OCSP in high-volume environments
validating the freshness of certificates, based on [RFC6960], (HVE) for validating the freshness of certificates, based on
incorporating some (but not all) of the optimizations of [RFC5019]. [RFC6960], incorporating some (but not all) of the optimizations of
[RFC5019]. CRLs MUST be signed with the same algorithm as the
certificate.
9.2. Using OCSP with TN Auth List 9.2. Using OCSP with TN Auth List
Certificates compliant with this specification therefore SHOULD Certificates compliant with this specification therefore SHOULD
include a URL pointing to an OCSP service in the Authority include a URL pointing to an OCSP service in the Authority
Information Access (AIA) certificate extension, via the "id-ad-ocsp" Information Access (AIA) certificate extension, via the "id-ad-ocsp"
accessMethod specified in [RFC5280]. Baseline OCSP however supports accessMethod specified in [RFC5280]. Baseline OCSP however supports
only three possible response values: good, revoked, or unknown. only three possible response values: good, revoked, or unknown.
Without some extension, OCSP would not indicate whether the Without some extension, OCSP would not indicate whether the
certificate is authorized for a particular telephone number that the certificate is authorized for a particular telephone number that the
skipping to change at page 14, line 8 skipping to change at page 14, line 31
The HVE OCSP profile [RFC5019] prohibits the use of per-request The HVE OCSP profile [RFC5019] prohibits the use of per-request
extensions. As it is anticipated that STIR will use OCSP in a high- extensions. As it is anticipated that STIR will use OCSP in a high-
volume environment, many of the optimizations recommended by HVE are volume environment, many of the optimizations recommended by HVE are
desirable for the STIR environment. This document therefore uses the desirable for the STIR environment. This document therefore uses the
HVE optimizations augmented as follows: HVE optimizations augmented as follows:
o Implementations MUST use SHA-256 as the hashing algorithm for the o Implementations MUST use SHA-256 as the hashing algorithm for the
CertID.issuerNameHash and the CertID.issuerKeyHash values. That CertID.issuerNameHash and the CertID.issuerKeyHash values. That
is CertID.hashAlgorithm is id-sha256 [RFC4055] and the values are is CertID.hashAlgorithm is id-sha256 [RFC4055] and the values are
truncated as per Option 1 in [RFC7093]. truncated to 160-bits as specified Option 1 in Sectin 2 of as per
in [RFC7093].
o Clients MUST include the OCSP TNQuery extension in requests' o Clients MUST include the OCSP TNQuery extension in requests'
singleRequestExtensions. singleRequestExtensions.
o Servers MUST include the OCSP TNQuery extension in responses' o Servers MUST include the OCSP TNQuery extension in responses'
singleExtensions. singleExtensions.
o Servers SHOULD return responses that would otherwise have been o Servers SHOULD return responses that would otherwise have been
"unknown" as "not good" (i.e., return only "good" and "not good" "unknown" as "not good" (i.e., return only "good" and "not good"
responses). responses).
o Clients MUST treat returned "unknown"responses as "not good". o Clients MUST treat returned "unknown" responses as "not good".
o If the server uses ResponderID, it MUST generate the KeyHash using o If the server uses ResponderID, it MUST generate the KeyHash using
SHA-256. The value is generated as per Option 1 in [RFC7093]. SHA-256 and truncate the value to 160-bits as specified in Option
1 in Section 2 of [RFC7093].
o Implementations MUST support ECDSA using P-256 and SHA-256. Note o Implementations MUST support ECDSA using P-256 and SHA-256. Note
that [RFC6960] requires RSA with SHA-256 be supported. that [RFC6960] requires RSA with SHA-256 be supported.
o There is no requirement to support SHA-1, RSA with SHA-1, or DSA o There is no requirement to support SHA-1, RSA with SHA-1, or DSA
with SHA-1. with SHA-1.
OCSP responses MUST be signed using the same algorithm as the
certificate being checked.
To facilitate matching the authority key identifier values found in
CA certificates with the KeyHash used in the OCSP response,
certificates compliant with this specification MUST generate
authority key identifiers and subject key identifers using the
SHA-256 and truncate the value to 160-bits as specified in Option 1
in Section 2 of [RFC7093].
Ideally, once a certificate has been acquired by a verifier, some Ideally, once a certificate has been acquired by a verifier, some
sort of asynchronous mechanism could notify and update the verifier sort of asynchronous mechanism could notify and update the verifier
if the scope of the certificate changes so that verifiers could if the scope of the certificate changes so that verifiers could
implement a cache. While not all possible categories of verifiers implement a cache. While not all possible categories of verifiers
could implement such behavior, some sort of event-driven notification could implement such behavior, some sort of event-driven notification
of certificate status is another potential subject of future work. of certificate status is another potential subject of future work.
One potential direction is that a future SIP SUBSCRIBE/NOTIFY-based One potential direction is that a future SIP SUBSCRIBE/NOTIFY-based
accessMethod for AIA might be defined (which would also be applicable accessMethod for AIA might be defined (which would also be applicable
to the method described in the following section) by some future to the method described in the following section) by some future
specification. specification.
 End of changes. 19 change blocks. 
36 lines changed or deleted 73 lines changed or added

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