draft-ietf-stir-rfc4474bis-00.txt   draft-ietf-stir-rfc4474bis-01.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: Standards Track C. Jennings Intended status: Standards Track C. Jennings
Expires: December 21, 2014 Cisco Expires: January 5, 2015 Cisco
E. Rescorla E. Rescorla
RTFM, Inc. RTFM, Inc.
June 19, 2014 July 4, 2014
Authenticated Identity Management in the Session Initiation Protocol Authenticated Identity Management in the Session Initiation Protocol
(SIP) (SIP)
draft-ietf-stir-rfc4474bis-00.txt draft-ietf-stir-rfc4474bis-01.txt
Abstract Abstract
The baseline security mechanisms in the Session Initiation Protocol The baseline security mechanisms in the Session Initiation Protocol
(SIP) are inadequate for cryptographically assuring the identity of (SIP) are inadequate for cryptographically assuring the identity of
the end users that originate SIP requests, especially in an the end users that originate SIP requests, especially in an
interdomain context. This document defines a mechanism for securely interdomain context. This document defines a mechanism for securely
identifying originators of SIP requests. It does so by defining new identifying originators of SIP requests. It does so by defining new
SIP header fields for conveying a signature used for validating the SIP header fields for conveying a signature used for validating the
identity, and for conveying a reference to the credentials of the identity, and for conveying a reference to the credentials of the
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 December 21, 2014. This Internet-Draft will expire on January 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 26 skipping to change at page 2, line 26
3. Overview of Operations . . . . . . . . . . . . . . . . . . . 5 3. Overview of Operations . . . . . . . . . . . . . . . . . . . 5
4. Signature Generation and Validation . . . . . . . . . . . . . 6 4. Signature Generation and Validation . . . . . . . . . . . . . 6
4.1. Authentication Service Behavior . . . . . . . . . . . . . 6 4.1. Authentication Service Behavior . . . . . . . . . . . . . 6
4.1.1. Intermediary Authentication Services . . . . . . . . 9 4.1.1. Intermediary Authentication Services . . . . . . . . 9
4.2. Verifier Behavior . . . . . . . . . . . . . . . . . . . . 10 4.2. Verifier Behavior . . . . . . . . . . . . . . . . . . . . 10
4.3. Identity within a Dialog and Retargeting . . . . . . . . 11 4.3. Identity within a Dialog and Retargeting . . . . . . . . 11
5. Credentials . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Credentials . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Credential Use by the Authentication Service . . . . . . 12 5.1. Credential Use by the Authentication Service . . . . . . 12
5.2. Credential Use by the Verification Service . . . . . . . 13 5.2. Credential Use by the Verification Service . . . . . . . 13
5.3. Handling Identity-Info URIs . . . . . . . . . . . . . . . 14 5.3. Handling Identity-Info URIs . . . . . . . . . . . . . . . 14
5.4. Credential Systems . . . . . . . . . . . . . . . . . . . 14 5.4. Credential Systems . . . . . . . . . . . . . . . . . . . 15
6. Identity Types . . . . . . . . . . . . . . . . . . . . . . . 16 6. Identity Types . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Telephone Numbers . . . . . . . . . . . . . . . . . . . . 16 6.1. Telephone Numbers . . . . . . . . . . . . . . . . . . . . 16
6.2. Usernames with Domain Names . . . . . . . . . . . . . . . 18 6.2. Usernames with Domain Names . . . . . . . . . . . . . . . 18
7. Header Syntax . . . . . . . . . . . . . . . . . . . . . . . . 19 7. Header Syntax . . . . . . . . . . . . . . . . . . . . . . . . 19
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10.1. Handling of digest-string Elements . . . . . . . . . . . 23 10.1. Handling of digest-string Elements . . . . . . . . . . . 23
10.2. Securing the Connection to the Authentication Service . 26 10.2. Securing the Connection to the Authentication Service . 26
10.3. Authorization and Transitional Strategies . . . . . . . 27 10.3. Authorization and Transitional Strategies . . . . . . . 27
skipping to change at page 2, line 49 skipping to change at page 2, line 49
11.1. Header Field Names . . . . . . . . . . . . . . . . . . . 28 11.1. Header Field Names . . . . . . . . . . . . . . . . . . . 28
11.2. 428 'Use Identity Header' Response Code . . . . . . . . 29 11.2. 428 'Use Identity Header' Response Code . . . . . . . . 29
11.3. 436 'Bad Identity-Info' Response Code . . . . . . . . . 29 11.3. 436 'Bad Identity-Info' Response Code . . . . . . . . . 29
11.4. 437 'Unsupported Credential' Response Code . . . . . . . 29 11.4. 437 'Unsupported Credential' Response Code . . . . . . . 29
11.5. 438 'Invalid Identity Header' Response Code . . . . . . 30 11.5. 438 'Invalid Identity Header' Response Code . . . . . . 30
11.6. Identity-Info Parameters . . . . . . . . . . . . . . . . 30 11.6. Identity-Info Parameters . . . . . . . . . . . . . . . . 30
11.7. Identity-Info Algorithm Parameter Values . . . . . . . . 30 11.7. Identity-Info Algorithm Parameter Values . . . . . . . . 30
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
13. Changes from RFC4474 . . . . . . . . . . . . . . . . . . . . 31 13. Changes from RFC4474 . . . . . . . . . . . . . . . . . . . . 31
14. Informative References . . . . . . . . . . . . . . . . . . . 31 14. Informative References . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
This document provides enhancements to the existing mechanisms for This document provides enhancements to the existing mechanisms for
authenticated identity management in the Session Initiation Protocol authenticated identity management in the Session Initiation Protocol
(SIP, RFC 3261 [RFC3261]). An identity, for the purposes of this (SIP, RFC 3261 [RFC3261]). An identity, for the purposes of this
document, is defined as either a SIP URI, commonly a canonical document, is defined as either a SIP URI, commonly a canonical
address-of-record (AoR) employed to reach a user (such as address-of-record (AoR) employed to reach a user (such as
'sip:alice@atlanta.example.com'), or a telephone number, which can be 'sip:alice@atlanta.example.com'), or a telephone number, which can be
represented as either a TEL URI or as the user portion of a SIP URI. represented as either a TEL URI or as the user portion of a SIP URI.
skipping to change at page 11, line 34 skipping to change at page 11, line 34
Step 5: Step 5:
The verifier MUST validate the Date header in the manner described in The verifier MUST validate the Date header in the manner described in
Section 10.1; recipients that wish to verify Identity signatures MUST Section 10.1; recipients that wish to verify Identity signatures MUST
support all of the operations described there. It must furthermore support all of the operations described there. It must furthermore
ensure that the value of the Date header falls within the validity ensure that the value of the Date header falls within the validity
period of the credential used to sign the Identity header. period of the credential used to sign the Identity header.
4.3. Identity within a Dialog and Retargeting 4.3. Identity within a Dialog and Retargeting
The mechanism is this document provides a signature over the URI in The mechanism in this document provides a signature over the URI in
the To header field value. The recipient of a request must compare the To header field value in order to allow recipient policy to
that value to their own identity in order to determine whether or not detect replay attacks where a request originally sent to one
the identity information in this call might have been replayed. recipient is forwarded to another, unrelated recipient by an
attacker. The recipient of a request may compare the To header field
value to their own identity in order to determine whether or not the
identity information in this call might have been replayed.
Retargeting, however, complicates this evaluation. Retargeting, however, complicates this evaluation.
Retargeting is broadly defined as the alteration of the Request-URI Retargeting is broadly defined as the alteration of the Request-URI
by intermediaries. More specifically, retargeting supplants the by intermediaries. More specifically, retargeting replaces the
original target URI with one that corresponds to a different user, original target URI with one that corresponds to a different user,
potentially a user that is not authorized to register under the potentially a user that would not be not authorized to register under
original target URI. By this definition, retargeting does not the original target URI. By this definition, retargeting does not
include translation of the Request-URI to a contact address of an include translation of the Request-URI to a contact address of an
endpoint that has registered under the original target URI. endpoint that has registered under the original target URI.
When a request is retargeted, it may reach a SIP endpoint whose user When a request is retargeted, it may reach a SIP endpoint whose user
is not identified by the URI designated in the To header field value. is not identified by the URI designated in the To header field value.
Moreover, the value in the To header field of a dialog-forming
request is used as the From header field of requests sent in the This can cause complications for securing requests sent in the
backwards direction during the dialog, and is accordingly the header backwards direction in a dialog; while this is not in the scope of
that would be signed by an authentication service for requests sent impersonation protection for this document, some considerations are
in the backwards direction. But in retargeting cases, if the URI in given here for future work that attempts to tackle that problem by
the From header does not identify the sender of the request in the building on this mechanism. In the absence of "from-change" option
backwards direction, then clearly it would be inappropriate to provided in [RFC4916], the value in the To header field of a dialog-
forming request is used as the From header field of requests sent in
the backwards direction during the dialog, and is accordingly the
header that would be signed by an authentication service for requests
sent in the backwards direction. But in retargeting cases, if the
URI in the From header does not identify the sender of the request in
the backwards direction, then clearly it would be inappropriate to
provide an Identity signature over that From header. As specified provide an Identity signature over that From header. As specified
above, if the authentication service is not responsible for the above, if the authentication service is not responsible for the
domain in the From header field of the request, it MUST NOT add an domain in the From header field of the request, it MUST NOT add an
Identity header to the request, and it should process/forward the Identity header to the request, and it should process/forward the
request normally. request normally.
Any means of anticipating retargeting, and so on, is outside the Any means of anticipating retargeting, and so on, is outside the
scope of this document, and likely to have equal applicability to scope of this document, and likely to have equal applicability to
response identity as it does to requests in the backwards direction response identity as it does to requests in the backwards direction
within a dialog. Consequently, no special guidance is given for within a dialog. Consequently, no special guidance is given for
skipping to change at page 17, line 6 skipping to change at page 17, line 15
indicator at the start of the user-portion. Absent these indicator at the start of the user-portion. Absent these
indications, if there are numbers present in the user-portion, indications, if there are numbers present in the user-portion,
implementations may also detect that the user-portion of the URI implementations may also detect that the user-portion of the URI
contains a telephone number by determining whether or not those contains a telephone number by determining whether or not those
numbers would be dialable or routable in the local environment -- numbers would be dialable or routable in the local environment --
bearing in mind that the telephone number may be a valid E.164 bearing in mind that the telephone number may be a valid E.164
number, a nationally-specific number, or even a private branch number, a nationally-specific number, or even a private branch
exchange number. exchange number.
Once an implementation has identified a telephone number, it must Once an implementation has identified a telephone number, it must
construct a number string. Implemenations MUST drop any leading construct a number string. Implementations MUST drop any leading
+'s, any internal dashes, parentheses or other non-numeric +'s, any internal dashes, parentheses or other non-numeric
characters. This MUST result in an ASCII string of only digits characters, excepting only the leading "#" or "*" keys used in
without whitespace or visual-separators. some special service numbers (typically, these will appear only in
the To header field value). This MUST result in an ASCII string
limited to "#", "*" and digits without whitespace or visual
separators.
Next, an implementation must assess if the number string is a Next, an implementation must assess if the number string is a
valid, globally-routable number with a leading country code. If valid, globally-routable number with a leading country code. If
not, implementations SHOULD convert the number into E.164 format, not, implementations SHOULD convert the number into E.164 format,
adding a country code if necessary. This may involve transforming adding a country code if necessary; this may involve transforming
the number from a dial string (see RFC3966 [RFC3966]), removing the number from a dial string (see RFC3966 [RFC3966]), removing
dialing prefixes (e.g., a leading '011') or performing similar any national or international dialing prefixes or performing
procedures. It is only the case that an implementation cannot similar procedures. It is only in the case that an implementation
determine how to convert the number to a globally-routable format cannot determine how to convert the number to a globally-routable
that this step may be skipped. format that this step may be skipped.
In some cases, further transformations MAY be made in accordance In some cases, further transformations MAY be made in accordance
with specific policies used within the local domain. For example, with specific policies used within the local domain. For example,
one domain may only use local number formatting and need to one domain may only use local number formatting and need to
convert all To/From user portions to E.164 by prepending country- convert all To/From user portions to E.164 by prepending country-
code and region code digits; another domain might prefix usernames code and region code digits; another domain might prefix usernames
with trunk- routing codes and need to remove the prefix. with trunk- routing codes and need to remove the prefix.
The resulting canonical number string will be used as input to the The resulting canonical number string will be used as input to the
hash calculation during signing and verifying process. hash calculation during signing and verifying processes.
The ABNF of this number string is: The ABNF of this number string is:
tn-spec = *DIGIT tn-spec = [ "#" / "*" ] 1*DIGIT
[TBD: do we need military codes A-D? Other codes?]
If the result of this procedure forms a complete telephone number, If the result of this procedure forms a complete telephone number,
that number is used for the purpose of creating and signing the that number is used for the purpose of creating and signing the
digest-string by both the authentication service and verification digest-string by both the authentication service and verification
service. If the result does not form a complete telephone number, service. If the result does not form a complete telephone number,
the authentication service and verification service should treat the the authentication service and verification service should treat the
entire URI as a SIP URI, and apply a domain signature per the entire URI as a SIP URI, and apply a domain signature per the
procedures in Section 6.2. procedures in Section 6.2.
In the longer term, it is possible that some directory or other In the longer term, it is possible that some directory or other
skipping to change at page 21, line 5 skipping to change at page 21, line 16
Identity-Reliance field in the request. If the message has no Identity-Reliance field in the request. If the message has no
body, or no Identity-Reliance header, then the fifth slot will be body, or no Identity-Reliance header, then the fifth slot will be
empty, and the final "|" will not be followed by any additional empty, and the final "|" will not be followed by any additional
characters. characters.
For more information on the security properties of these headers, and For more information on the security properties of these headers, and
why their inclusion mitigates replay attacks, see Section 10 and why their inclusion mitigates replay attacks, see Section 10 and
[RFC3893]. The precise formulation of this digest-string is, [RFC3893]. The precise formulation of this digest-string is,
therefore (following the ABNF[RFC4234] in RFC 3261 [RFC3261]): therefore (following the ABNF[RFC4234] in RFC 3261 [RFC3261]):
digest-string = addr-spec / tn-spec "|" addr-spec / tn-spec "|" digest-string = ( addr-spec / tn-spec ) "|" ( addr-spec / tn-spec ) "|"
Method "|" SIP-date "|" [ signed-identity-reliance-digest ] Method "|" SIP-date "|" [ signed-identity-reliance-digest ]
For the definition of 'tn-spec' see Section 6.1. For the definition of 'tn-spec' see Section 6.1.
After the digest-string or reliance-digest-string is formed, each After the digest-string or reliance-digest-string is formed, each
MUST be hashed and signed with the certificate of authority over the MUST be hashed and signed with the certificate of authority over the
identity. The hashing and signing algorithm is specified by the identity. The hashing and signing algorithm is specified by the
'alg' parameter of the Identity-Info header (see below for more 'alg' parameter of the Identity-Info header (see below for more
information on Identity-Info header parameters). This document information on Identity-Info header parameters). This document
defines only one value for the 'alg' parameter: 'rsa-sha256'; further defines only one value for the 'alg' parameter: 'rsa-sha256'; further
skipping to change at page 32, line 37 skipping to change at page 32, line 37
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC
3966, December 2004. 3966, December 2004.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 4234, October 2005.
[RFC4501] Josefsson, S., "Domain Name System Uniform Resource [RFC4501] Josefsson, S., "Domain Name System Uniform Resource
Identifiers", RFC 4501, May 2006. Identifiers", RFC 4501, May 2006.
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", RFC 4916, June 2007.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, August 2012. Protocol: TLSA", RFC 6698, August 2012.
Authors' Addresses Authors' Addresses
 End of changes. 18 change blocks. 
31 lines changed or deleted 48 lines changed or added

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