--- 1/draft-ietf-stir-rfc4474bis-12.txt 2016-09-30 07:16:43.767780487 -0700 +++ 2/draft-ietf-stir-rfc4474bis-13.txt 2016-09-30 07:16:43.867783018 -0700 @@ -1,24 +1,24 @@ Network Working Group J. Peterson Internet-Draft NeuStar -Intended status: Standards Track C. Jennings -Expires: March 13, 2017 Cisco - E. Rescorla +Obsoletes: 4474 (if approved) C. Jennings +Intended status: Standards Track Cisco +Expires: April 2, 2017 E. Rescorla RTFM, Inc. C. Wendt Comcast - September 9, 2016 + September 29, 2016 Authenticated Identity Management in the Session Initiation Protocol (SIP) - draft-ietf-stir-rfc4474bis-12.txt + draft-ietf-stir-rfc4474bis-13.txt Abstract The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining a SIP header field for conveying a signature used for validating the identity, and for conveying a reference to the credentials of the @@ -32,21 +32,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on March 13, 2017. + This Internet-Draft will expire on April 2, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -56,55 +56,56 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 4 4. Identity Header Field Syntax . . . . . . . . . . . . . . . . 6 4.1. PASSporT Construction . . . . . . . . . . . . . . . . . . 7 - 4.1.1. 'canon' and PASSporT . . . . . . . . . . . . . . . . 9 - 5. Example of Operations . . . . . . . . . . . . . . . . . . . . 10 + 4.1.1. Example Full and Compact Forms of PASSporT in + Identity . . . . . . . . . . . . . . . . . . . . . . 9 + 5. Example of Operations . . . . . . . . . . . . . . . . . . . . 9 5.1. Example Identity Header Construction . . . . . . . . . . 11 - 6. Signature Generation and Validation . . . . . . . . . . . . . 13 - 6.1. Authentication Service Behavior . . . . . . . . . . . . . 13 - 6.2. Verifier Behavior . . . . . . . . . . . . . . . . . . . . 16 + 6. Signature Generation and Validation . . . . . . . . . . . . . 12 + 6.1. Authentication Service Behavior . . . . . . . . . . . . . 12 + 6.1.1. Handling Repairable Errors . . . . . . . . . . . . . 15 + 6.2. Verifier Behavior . . . . . . . . . . . . . . . . . . . . 15 6.2.1. Authorization of Requests . . . . . . . . . . . . . . 17 - 6.2.2. Response Codes Sent by a Verification Service . . . . 18 - 6.2.3. Handling 'canon' parameters . . . . . . . . . . . . . 19 - 7. Credentials . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 6.2.2. Failure Response Codes Sent by a Verification Service 18 + 6.2.3. Handling the full form of PASSporT . . . . . . . . . 19 + 7. Credentials . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.1. Credential Use by the Authentication Service . . . . . . 20 7.2. Credential Use by the Verification Service . . . . . . . 21 7.3. 'info' parameter URIs . . . . . . . . . . . . . . . . . . 22 7.4. Credential System Requirements . . . . . . . . . . . . . 22 - 8. Identity Types . . . . . . . . . . . . . . . . . . . . . . . 24 + 8. Identity Types . . . . . . . . . . . . . . . . . . . . . . . 23 8.1. Differentiating Telephone Numbers from URIs . . . . . . . 24 8.2. Authority for Telephone Numbers . . . . . . . . . . . . . 25 8.3. Telephone Number Canonicalization Procedures . . . . . . 25 8.4. Authority for Domain Names . . . . . . . . . . . . . . . 26 8.5. URI Normalization . . . . . . . . . . . . . . . . . . . . 27 9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 28 - 10. Backwards Compatibililty with RFC4474 . . . . . . . . . . . . 29 + 10. Backwards Compatibility with RFC4474 . . . . . . . . . . . . 29 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29 12. Security Considerations . . . . . . . . . . . . . . . . . . . 31 - 12.1. Protected Request Fields . . . . . . . . . . . . . . . . 32 + 12.1. Protected Request Fields . . . . . . . . . . . . . . . . 31 12.1.1. Protection of the To Header and Retargeting . . . . 33 12.2. Unprotected Request Fields . . . . . . . . . . . . . . . 34 - 12.3. Malicious Removal of Identity Headers . . . . . . . . . 35 + 12.3. Malicious Removal of Identity Headers . . . . . . . . . 34 12.4. Securing the Connection to the Authentication Service . 35 12.5. Authorization and Transitional Strategies . . . . . . . 36 12.6. Display-Names and Identity . . . . . . . . . . . . . . . 37 - 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 - 13.1. SIP Header Fields . . . . . . . . . . . . . . . . . . . 38 - 13.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 38 + 13.1. SIP Header Fields . . . . . . . . . . . . . . . . . . . 37 + 13.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 37 13.3. Identity-Info Parameters . . . . . . . . . . . . . . . . 38 13.4. Identity-Info Algorithm Parameter Values . . . . . . . . 38 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 15. Changes from RFC4474 . . . . . . . . . . . . . . . . . . . . 38 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 16.1. Normative References . . . . . . . . . . . . . . . . . . 39 16.2. Informative References . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 1. Introduction @@ -146,35 +147,36 @@ means of signing portions of SIP requests in order to provide an identity assurance. However, RFC4474 was in several ways misaligned with deployment realities (see [I-D.rosenberg-sip-rfc4474-concerns]). Most significantly, RFC4474 did not deal well with telephone numbers as identifiers, despite their enduring use in SIP deployments. RFC4474 also provided a signature over material that intermediaries in existing deployments commonly altered. This specification therefore deprecates the RFC4474 syntax and behavior, reconsidering the problem space in light of the threat model in [RFC7375] and aligning the signature format with PASSporT [I-D.ietf-stir-passport]. + Backwards compatibility considerations are given in Section 10. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [RFC2119]. In addition, this document uses three terms specific to the mechanism: Identity: An identifier for the user of a communications service; for the purposes of SIP, either a SIP URI or a telephone number. - Identities are derived from an "identity field" a SIP request such - as the From header field. + Identities are derived from an "identity field" in a SIP request + such as the From header field. Authentication Service: A logical role played by a SIP entity that adds Identity headers to SIP requests. Verification Service (or "Verifier"): A logical role played by a SIP entity that validates Identity headers in a SIP request. 3. Architectural Overview The identity architecture for SIP defined in this specification @@ -229,86 +231,85 @@ the domain owner's credentials, or the user agent must possess credentials that prove in some fashion that the domain owner has given the user agent the right to a name. In order to share a cryptographic assurance of end-user SIP identity in an interdomain or intradomain context, an authentication service constructs tokens based on the PASSporT [I-D.ietf-stir-passport] format, a JSON [RFC7159] object comprising values derived from certain header field values in the SIP request. The authentication service computes a signature over those JSON elements as PASSporT - specifies. That signature is then placed in the SIP Identity header - field. In order to assist in the validation of the Identity header - field, this specification also describes a parameter of the Identity - header field that can be used by the recipient of a request to - recover the credentials of the signer. + specifies. An encoding of the resulting PASSporT is then placed in + the SIP Identity header field. In order to assist in the validation + of the Identity header field, this specification also describes a + parameter of the Identity header field that can be used by the + recipient of a request to recover the credentials of the signer. Note that the scope of this document is limited to providing an identity assurance for SIP requests; solving this problem for SIP responses is outside the scope of this work (see [RFC4916]). Future work might specify ways that a SIP implementation could gateway - PASSporT objects to other protocols. + PASSporTs to other protocols. 4. Identity Header Field Syntax The Identity and Identity-Info header fields that were previously defined in RFC4474 are here deprecated. This revised specification collapses the grammar of Identity-Info into the Identity header field via the "info" parameter. Note that unlike the prior specification in RFC4474, the Identity header field is now allowed to appear more than one time in a SIP request. The revised grammar for the Identity header field builds on the ABNF [RFC5234] in RFC 3261 [RFC3261] Section 25. It is as follows: - Identity = "Identity" HCOLON signed-identity-digest SEMI \ + Identity = "Identity" HCOLON signed-identity-digest SEMI ident-info *( SEMI ident-info-params ) - signed-identity-digest = LDQUOT *base64-char RDQUOT + signed-identity-digest = *base64-char ident-info = "info" EQUAL ident-info-uri ident-info-uri = LAQUOT absoluteURI RAQUOT - ident-info-params = ident-info-alg / ident-type / \ - canonical-str / ident-info-extension + ident-info-params = ident-info-alg / ident-type / + ident-info-extension ident-info-alg = "alg" EQUAL token ident-type = "ppt" EQUAL token - canonical-str = "canon" EQUAL LDQUOT *base64-char RDQUOT ident-info-extension = generic-param base64-char = ALPHA / DIGIT / "/" / "+" In addition to the "info" parameter, and the "alg" parameter previously defined in RFC4474, this specification defines the - optional "canon" and "ppt" parameters. The 'absoluteURI' portion of - ident-info-uri MUST contain a URI; see Section 7.3 for more on - choosing how to advertise credentials through this parameter. + optional "ppt" parameter. The 'absoluteURI' portion of ident-info- + uri MUST contain a URI; see Section 7.3 for more on choosing how to + advertise credentials through this parameter. - The signed-identity-digest is the PASSporT signature component of a - PASSporT object [I-D.ietf-stir-passport], a signature which PASSporT - generates over the JSON header and payload objects; some header and - claim element values will mirror values of the SIP request. In order - to generate that signature, an implementation must construct a - complete PASSporT object. + The signed-identity-digest contains a base64 encoding of a PASSporT + [I-D.ietf-stir-passport], which secures the request with a signature + that PASSporT generates over the JSON header and payload objects; + some of those header and claim element values will mirror values of + the SIP request. 4.1. PASSporT Construction For SIP implementations to populate the PASSporT header JSON object - with fields from a SIP request, the following elements message MUST - be placed as the values corresponding to the designated JSON keys: + with fields from a SIP request, the following elements MUST be placed + as the values corresponding to the designated JSON keys: - First, per baseline [I-D.ietf-stir-passport], the JSON key "typ" - key MUST have the value "passport". + First, per baseline [I-D.ietf-stir-passport], the JSON "typ" key + MUST have the value "passport". Second, the JSON key "alg" MUST mirror the value of the optional "alg" parameter in the SIP Identity header field. Note if the "alg" parameter is absent from the Identity header, the default value is "ES256". Third, the JSON key "x5u" MUST have a value equivalent to the - quoted URI in the "info" parameter. + quoted URI in the "info" parameter, per the simple string + comparison rules of [RFC3986] section 6.2.1. Fourth, if a PASSporT extension is in use, then the optional JSON key "ppt" MUST be present and have a value equivalent to the quoted value of the "ppt" parameter of the Identity header field. An example of the PASSporT header JSON object without any extension is: { "typ":"passport", "alg":"ES256", @@ -317,123 +318,119 @@ To populate the PASSporT payload JSON object from a SIP request, the following elements MUST be placed as values corresponding to the designated JSON keys: First, the JSON "orig" array MUST be populated. If the originating identity is a telephone number, then the array MUST be populated with a "tn" claim with a value set to the value of the quoted originating identity, a canonicalized telephone number (see Section 8.3). Otherwise, the array MUST be populated with a "uri" claim, set to the value of the AoR of the UA sending the message - as taken from addr-spec of the From header field, per the + as taken from the addr-spec of the From header field, per the procedures in Section 8.5. Second, the JSON "dest" array MUST be populated. If the destination identity is a telephone number, then the array MUST be populated with a "tn" claim with a value set to the value of the quoted destination identity, a canonicalized telephone number (see Section 8.3). Otherwise, the array MUST be populated with a "uri" claim, set to the value of the addr-spec component of the To header field, which is the AoR to which the request is being sent, per the procedures in Section 8.5. - Third, the JSON key "iat" MUST appear, set to the value of a - quoted encoding of the value of the SIP Date header field as a - JSON NumericDate (as UNIX time, per [RFC7519] Section 2). + Third, the JSON key "iat" MUST appear. The authentication service + SHOULD set the value of "iat" to a quoted encoding of the value of + the SIP Date header field as a JSON NumericDate (as UNIX time, per + [RFC7519] Section 2), though an authentication service MAY set the + value of "iat" to its own current clock time. The authentication + service MUST NOT generate a PASSporT for a SIP request if the Date + header is outside of its local policy for freshness (recommended + sixty seconds). Fourth, if the request contains an SDP message body, and if that SDP contains one or more "a=fingerprint" attributes, then the JSON key "mky" MUST appear with the algorithm(s) and value(s) of the fingerprint attributes (if they differ), following the format given in [I-D.ietf-stir-passport] Section 4.2.2. For example: { "orig":{"tn":"12155551212"}, "dest":{"tn":"12155551213"}, "iat":"1443208345" } For information on the security properties of these SIP message elements, and why their inclusion mitigates replay attacks, see - Section 12. Note that future extensions to the PASSporT object could - introduce new claims, and that further SIP procedures could be - required to extract information from the SIP request to populate the - values of those claims; see Section 9. + Section 12. Note that future extensions to PASSporT could introduce + new claims, and that further SIP procedures could be required to + extract information from the SIP request to populate the values of + those claims; see Section 9. The "orig" and "dest" arrays may contain identifiers of heterogeneous type; for example, the "orig" array might contain a "tn" claim, while the "dest" contains a "uri" claim. Also note that in some cases, the - "orig" and "dest" arrays might be populated with more than one value. - This could for example occur when multiple "dest" identities are - specified in a meshed conference. Defining how a SIP implementation - would provision multiple originating or destination identities is - left as a subject for future specification. + "dest" array may be populated with more than one value. This could + for example occur when multiple "dest" identities are specified in a + meshed conference. Defining how a SIP implementation would align + multiple destination identities in PASSporT with such systems is left + as a subject for future specification. - After these two JSON objects, the header and the paylod, have been - constructed and base64-encoded, they must each be hashed per - [I-D.ietf-stir-passport] Section 5. The signed value of those - concatenated hashes then becomes the signed-identity-string of the - Identity header field. The hashing and signing algorithm is - specified by the 'alg' parameter of the Identity header field and the - mirrored "alg" parameter of PASSporT. This specification inherits - from the PASSporT specification one value for the 'alg' parameter: + After these two JSON objects, the header and the payload, have been + constructed and base64-encoded, they must each be hashed and signed + per [I-D.ietf-stir-passport] Section 5. The header, payload and + signature components comprise a full PASSporT object. The resulting + PASSporT may be carried in SIP in either a full form, which includes + the header and payload as well as the signature, or a compact form + which only carries the signature per [I-D.ietf-stir-passport] + Section 6. The hashing and signing algorithm is specified by the + 'alg' parameter of the Identity header field and the mirrored "alg" + parameter of PASSporT. All implementations of this specification + MUST support the required signing algorithms of PASSporT. At present + there is one mandatory-to-support value for the 'alg' parameter: 'ES256', as defined in [RFC7519], which connotes an ECDSA P-256 - digital signature. All implementations of this specification MUST - support the required signing algorithms of PASSporT. - - The PASSporT signature that serves as the signed-identity-digest for - the SIP Identity header field constitutes only the base64 encoded - signed hash, omitting the leading '.' of JWS. - - The complete form of the Identity header field will therefore look - like the following example: - - Identity: "sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/Hmty \ - NS7Ltrg9dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21y \ - NDo2ER/Ovgtw0Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0 \ - gfUs=";info=;alg=ES256 + digital signature. -4.1.1. 'canon' and PASSporT +4.1.1. Example Full and Compact Forms of PASSporT in Identity As Appendix F of the JWS specification [RFC7515] notes, there are cases where "it is useful to integrity-protect content that is not itself contained in a JWS." Since the fields that make up the majority of the PASSporT header and payload have values replicated in the SIP request, the SIP usage of PASSporT may exclude the base64 encoded version of the header and payload JSON objects from the - Identity header field and instead present a detached signature. Only - the signature component of the PASSporT is REQUIRED in SIP, as it - forms the contents of the signed-identity-digest field. Optionally, - as a debugging measure or optimization, the base64-encoded - concatenation of the JSON header and payload MAY be included as the - value of a "canon" parameter of the Identity header field. Note - however that the use of some future extensions could require "canon" - (see Section 9). + Identity header field and instead present a detached signature: what + PASSporT calls its compact form, see [I-D.ietf-stir-passport] + Section 6. - When the "canon" parameter is present, it MUST contain the base64 - encoded header and payload of the PASSporT token per - [I-D.ietf-stir-passport]; following JWS, the header and payload are - separated by a single '.'. However, no trailing '.' is included in - the "canon": the string consists solely of the base64 encoded JSON - header object, followed by a '.', followed by the base64 encoded - payload JSON object, as follows: + When an authentication service constructs an Identity header, the + contents of the signed-identity-digest field MUST contain either a + full or compact PASSporT. Use of the compact form is RECOMMENDED in + order to reduce message size, but note that extensions often require + the full form (see Section 9). - Identity: "rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpj \ - lk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w"; \ - info=;alg=ES256;canon= \ - "eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cH \ - M6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7 \ - InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI6IjE0NDM \ - yMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0" + For example, a full form of PASSporT in an Identity header might look + as follows: - Note that the presence of the "canon" parameter adds considerably to - the length of the Identity header field value. + Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1I \ + joiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJ \ + kZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdC \ + I6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.r \ + q3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \ + ojNCpTzO3QfPOlckGaS6hEck7w;info= + + The compact form of the same PASSporT object would appear in the + Identity header as: + + Identity: ..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qj \ + pjlk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w; \ + info= 5. Example of Operations This section provides an informative (non-normative) high-level example of the operation of the mechanisms described in this document. Imagine a case where Bob, who has the home proxy of example.com and the address-of-record sip:12155551212@example.com, wants to communicate with Alice at sip:alice@example.org. They have no prior @@ -463,32 +460,32 @@ . | | | |. . | | . . | Bob | +-------+. . | Alice | . . | UA | . . | UA | . . | | . . | | . . +-------+ . . +-------+ . . Domain A . . Domain B . ............................ .............................. The proxy authenticates Bob, and validates that he is authorized to assert the identity that he populated in the From header field. The - proxy authentication service then constructs a PASSporT object which + proxy authentication service then constructs a PASSporT which contains a JSON representation of values which mirror certain parts of the SIP request, including the identity in the From header field - value. As a part of generating the PASSporT object, the - authentication service signs a hash of that JSON header and payload - with the private key associated with the appropriate credential for - the identity (in this example, a certificate with authority to sign - for numbers in a range from 12155551000 to 121555519999), and the - signature is inserted by the proxy server into the Identity header - field value of the request. Optionally, the JSON header and payload - themselves may also be included in the object, encoded in the "canon" - parameter of the Identity header field. + value. As a part of generating the PASSporT, the authentication + service signs a hash of that JSON header and payload with the private + key associated with the appropriate credential for the identity (in + this example, a certificate with authority to sign for numbers in a + range from 12155551000 to 121555519999), and the signature is + inserted by the proxy server into the Identity header field value of + the request as a compact form of PASSporT. Alternatively, the JSON + header and payload themselves might also have been included in the + object when using the full form of PASSporT. The proxy authentication service, as the holder of a private key with authority over Bob's telephone number, is asserting that the originator of this request has been authenticated and that he is authorized to claim the identity that appears in the From header field. The proxy inserts an "info" parameter into the Identity header field that tells Alice how to acquire keying material necessary to validate its credentials (a public key), in case she doesn't already have it. @@ -539,27 +536,27 @@ {"dest":{"uri":["sip:alice@example.com"]},"iat":"1443208345", "orig":{"tn":"12155551212"}} The authentication service would then generate the signature over the object following the procedures in [I-D.ietf-stir-passport] Section 5. That signature would look as follows: rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \ ojNCpTzO3QfPOlckGaS6hEck7w - An authentication service signing this request would thus generate - and add to the request an Identity header field of the following - form: + An authentication service signing this request and using the compact + form of PASSporT would thus generate and add to the request an + Identity header field of the following form: - Identity: "rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpj \ - lk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w"; \ - info= + Identity: ..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpj \ + lk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w; \ + info= 6. Signature Generation and Validation SIP entities that instantiate the authentication service and verification service roles will, respectively, generate and validate the Identity header and the signature it contains. 6.1. Authentication Service Behavior Any entity that instantiates the authentication service role MUST @@ -655,60 +652,61 @@ and the current time fall within the validity period of its credential. See Section 12.1 for information on how the Date header field assists verifiers. Step 4: Populate and Add the Identity Header Subsequently, the authentication service MUST form a PASSporT object and add a corresponding Identity header field to the request - containing this signature. For the baseline PASSporT header (headers - containing no "ppt" parameter), this follows the procedures in - Section 4; if the authentication service is using an alternative - "ppt" format, it MUST add an appropriate "ppt" parameter and follow - the procedures associated with that extension (see Section 9). After - the Identity header field has been added to the request, the - authentication service MUST also add a "info" parameter to the - Identity header field. The "info" parameter contains a URI from - which the authentication service's credential can be acquired; see - Section 7.3 for more on credential acquisition. + containing either the full or compact form of PASSporT. For the + baseline PASSporT header (headers containing no "ppt" parameter), + this follows the procedures in Section 4; if the authentication + service is using an alternative "ppt" format, it MUST add an + appropriate "ppt" parameter and follow the procedures associated with + that extension (see Section 9). After the Identity header field has + been added to the request, the authentication service MUST also add a + "info" parameter to the Identity header field. The "info" parameter + contains a URI from which the authentication service's credential can + be acquired; see Section 7.3 for more on credential acquisition. - Step 5: Add "canon", if Needed + An authentication service MAY use the full form of the PASSporT in + the Identity header field. The presence of the full form is OPTIONAL + because the information carried in the baseline PASSporT object's + headers and claims is usually redundant with information already + carried elsewhere in the SIP request. Using the compact form can + significantly reduce SIP message size, especially when the PASSporT + object contains media keys. The syntax of the compact form is given + in [I-D.ietf-stir-passport] Section 6; essentially, it contains a + base64 encoding of the JSON header and payload in the PASSporT + object. - An authentication service MAY add a "canon" parameter to the Identity - header field. The presence of "canon" is OPTIONAL because the - information carried in the baseline PASSporT object's headers and - claims is usually redundant with information already carried - elsewhere in the SIP request. Omitting "canon" can significantly - reduce SIP message size, especially when the PASSporT object contains - media keys. The syntax of "canon" is given in Section 4.1.1; - essentially, it contains a base64 encoding of the JSON header and - payload in the PASSporT object. + Note that per the behavior specified in [I-D.ietf-stir-passport], use + of the full form is mandatory when optional extensions are included. + See Section 9. - When however an authentication service creates a PASSporT object that - uses extension claims beyond the baseline PASSporT object, including - "canon" is REQUIRED in order for the verification service to be - capable of validating the signature. See Section 9. +6.1.1. Handling Repairable Errors Also, in some cases, a request signed by an authentication service will be rejected by the verification service on the receiving side, and the authentication service will receive a SIP 4xx status code in the backwards direction, such as a 438 indicating a verification failure. If the authentication service did not originally send the - Identity header field with the "canon" parameter, it SHOULD retry a - request once after receiving a 438 response, this time including the - "canon". The information in "canon" is useful on the verification - side for debugging errors, and there are some known causes of - verification failures (such as the Date header field value changing - in transit, see Section 12.1 for more information) that can be - resolved by the inclusion of "canon". + full form of the PASSporT object in the Identity header field, it + SHOULD retry the request with the full form after receiving a 438 + response; however implementations SHOULD NOT retry the request more + than once. The information in the full form is useful on the + verification side for debugging errors, and there are some known + causes of verification failures (such as the Date header field value + changing in transit, see Section 12.1 for more information) that can + be resolved by the inclusion of the full form of PASSporT. Finally, the authentication service forwards the message normally. 6.2. Verifier Behavior This document specifies a logical role for SIP entities called a verification service, or verifier. When a verifier receives a SIP message containing one or more Identity header fields, it inspects the signature(s) to verify the identity of the originator of the message. The results of a verification are provided as input to an @@ -720,22 +718,22 @@ support an Identity header field "ppt" parameter which is present, or if no Identity header field is present at all, and the presence of an Identity header field is required by local policy (for example, based on a per-sending-domain policy, or a per-sending-user policy), then a 428 'Use Identity Header' response MUST be sent in the backwards direction. For more on this and other verifier responses, see Section 6.2.2. In order to verify an Identity header field in a message, an entity acting as a verifier MUST perform the following steps, in the order - here specified. Note that when an Identity header field contains the - optional "canon" parameter, the verifier MUST follow the additional + here specified. Note that when an Identity header field contains a + full form PASSporT object, the verifier MUST follow the additional procedures in Section 6.2.3. Step 1: Check for an Unsupported "ppt" The verifier MUST inspect any optional "ppt" parameter appearing in the Identity request. If no "ppt" parameter is present, then the verifier proceeds normally below. If a "ppt" parameter value is present, and the verifier does not support it, it MUST ignore the Identity header field. If a supported "ppt" parameter value is present, the verifier proceeds with Step 2, and will ultimately @@ -755,32 +753,31 @@ The verifier must ensure that it possesses the proper keying material to validate the signature in the Identity header field, which usually involves dereferencing a URI in the "info" parameter of the Identity header field. See Section 7.2 for more information on these procedures. If the verifier does not support the credential described in the "info" parameter, then it treats the credential for this header field as unsupported. Step 4: Check the Freshness of Date - The verifier furthermore ensures that the value of the Date header field of the request meets local policy for freshness (sixty seconds is RECOMMENDED) and that it falls within the validity period of the credential used to sign the Identity header field. For more on the - attacks this prevents, see Section 12.1. If the "canon" parameter is - present, the verifier SHOULD compare the "iat" value in the "canon" - to the Date header field value in the request. If the two are - different, and the "iat" value is later but within verification - service policy for freshness, the verification service SHOULD perform - the computation required by Step 5 using the "iat" value instead of - the Date header field value. + attacks this prevents, see Section 12.1. If the full form of the + PASSporT is present, the verifier SHOULD compare the "iat" value in + the PASSporT to the Date header field value in the request. If the + two are different, and the "iat" value is later but within + verification service policy for freshness, the verification service + SHOULD perform the computation required by Step 5 using the "iat" + value instead of the Date header field value. Step 5: Validate the Signature The verifier MUST validate the signature in the Identity header field over the PASSporT object. For baseline PASSporT objects (with no Identity header field "ppt" parameter) the verifier MUST follow the procedures for generating the signature over a PASSporT object described in Section 4. If a "ppt" parameter is present (and per Step 1, is supported), the verifier follows the procedures for that "ppt" (see Section 9). If a verifier determines that the that the @@ -802,22 +799,26 @@ forwarding decisions in intermediary implementations, or changing how the user is alerted, or how identity is rendered, in user agent implementations. The presence of multiple Identity header fields within a message raises the prospect that a verification services could receive a message containing some valid and some invalid Identity header fields. As a guideline, this specification recommends that only if a verifier determines all Identity header fields within a message are invalid should the request be considered to have an invalid identity. + If at least one Identity header field value is valid and from a + trusted source, then relying parties can use that header for + authorization decisions regardless of whether other untrusted or + invalid Identity headers appear in a request. -6.2.2. Response Codes Sent by a Verification Service +6.2.2. Failure Response Codes Sent by a Verification Service RFC4474 originally defined four response codes for failure conditions specific to the Identity header field and its original mechanism. These status codes are retained in this specification, with some slight modifications. Also, this specification details responding with 403 when a stale Date header field value is received. A 428 response will be sent (per Section 6.2) when an Identity header field is required, but no Identity header field without a "ppt" parameter, or with a supported "ppt" value, has been received. In @@ -848,51 +849,55 @@ with which the credential was signed. The 438 'Invalid Identity Header' response indicates that of the set of Identity header fields in a request, no header field with a valid and supported PASSporT object has been received. Like the 428 response, this is sent by a verification service when its local policy dictates that a broken signature in an Identity header field is grounds for rejecting a request. Note that in some cases, an Identity header field may be broken for other reasons than that an originator is attempting to spoof an identity: for example, when a - transit network alters the Date header field of the request. Relying - on the full PASSporT object presented through the "canon" parameter - can repair some of these conditions (see Section 6.2.3), so the - recommended way to attempt to repair this failure is to retry the - request with "canon". + transit network alters the Date header field of the request. Sending + a full form PASSporT can repair some of these conditions (see + Section 6.2.3), so the recommended way to attempt to repair this + failure is to retry the request with the full form of PASSporT if it + had originally been sent with the compact form. The alternative + reason phrase 'Invalid PASSporT' SHOULD be used when an extended full + form PASSporT lacks required headers or claims, or when an extended + full form PASSporT signaled with the "ppt" parameter lacks required + claims for that extension. - Finally, a 403 response with the special reason phase 'Stale Date" + Finally, a 403 response with the special reason phrase 'Stale Date" may be sent when the verification service receives a request with a Date header field value that is older than the local policy for freshness permits. The same response may be used when the "iat" in - the "canon" parameter of a request has a value older than the local - policy for freshness permits. + the full form of a PASSporT has a value older than the local policy + for freshness permits. -6.2.3. Handling 'canon' parameters +6.2.3. Handling the full form of PASSporT - If the optional "canon" parameter of the Identity header field is - present, it contains a base64 encoding of the header and claim - component of the PASSporT object constructed by the authentication - service (as detailed in Section 4.1.1). The verification service can - thus extract from it the canonical telephone number created by the - authentication service, as well as an "iat" claim corresponding to - the Date header field that the authentication service used. These - may be used to debug canonicalization problems, or to avoid - unnecessary signature breakage caused by intermediaries that alter - the Date header field value in transit. + If the full form of PASSporT is present in an Identity header, this + permits the use of optional extensions as described in + [I-D.ietf-stir-passport] Section 7.3. The verification service can + extract from the "orig" element" a canonical telephone number created + by the authentication service, as well as an "iat" claim + corresponding to the Date header field that the authentication + service used. These may be used to debug canonicalization problems, + or to avoid unnecessary signature breakage caused by intermediaries + that alter the Date header field value in transit. - As an optimization, when "canon" is present, the verification service - MAY compute its own canonicalization of an originating telephone - number and compare it to the values in the "canon" parameter before - performing any cryptographic functions in order to ascertain whether - or not the two ends agree on the canonical number form. + As an optimization, when the full form is present, the verification + service MAY compute its own canonicalization of an originating + telephone number and compare it to the values in the "orig" element + of PASSporT before performing any cryptographic functions in order to + ascertain whether or not the two ends agree on the canonical number + form. 7. Credentials This section gives general guidance on the use of credential systems by authentication and verification services, as well as requirements that must be met by credential systems that conform with this architecture. It does not mandate any specific credential system. Furthermore, this specification allows either a user agent or a proxy server to provide the authentication service function and/or the @@ -1091,24 +1096,24 @@ header field value instead of the From header field value. In some trusted environments, the P-Asserted-Identity header field is used in lieu of the From header field to convey the address-of-record or telephone number of the originator of a request; where it does, local policy might therefore dictate that the canonical identity derives from the P-Asserted-Identity header field rather than the From header field. Ultimately, in any case where local policy canonicalizes the identity into a form different from how it appears in the From header field, - the use of the "canon" parameter by authentication services is - RECOMMENDED, but because "canon" itself could then divulge - information about users or networks, implementers should be mindful - of the guidelines in Section 11. + the use of the full form of PASSporT by authentication services is + RECOMMENDED, but because the "orig" claim of PASSporT could itself + could then divulge information about users or networks, implementers + should be mindful of the guidelines in Section 11. 8.1. Differentiating Telephone Numbers from URIs It may not be trivial to tell if a given URI contains a telephone number. In order to determine whether or not the user portion of a SIP URI is a telephone number, authentication services and verification services MUST perform the following procedure on any SIP URI they inspect which contains a numeric user part. Note that the same procedures are followed for creating the canonical form of URIs found in the From header field as they are in the To header field or @@ -1134,22 +1139,22 @@ number, or even a private branch exchange number. Once a telephone number has been detected, implementations should follow the procedures in Section 8.3. If the URI field does not contain a telephone number, or if the result of the canonicalization of the From header field value does not form a valid E.164 telephone number, the authentication service and/or verification service SHOULD treat the entire URI as a SIP URI, and apply the procedures in Section 8.5. These URI normalization procedures are invoked to canonicalize the URI before it is included - in a PASSporT object in, for example, an "uri" claim. See - Section 8.5 for that behavior. + in a PASSporT object in, for example, a "uri" claim. See Section 8.5 + for that behavior. 8.2. Authority for Telephone Numbers In order for telephone numbers to be used with the mechanism described in this document, authentication services must receive credentials from an authority for telephone numbers or telephone number ranges, and verification services must trust the authority employed by the authentication service that signs a request. Per Section 7.4, enrollment procedures and credential management are outside the scope of this document; approaches to credential @@ -1172,33 +1177,34 @@ Next, an implementation must assess if the number string is a valid, globally-routable number with a leading country code. If not, implementations SHOULD convert the number into E.164 format, adding a country code if necessary; this may involve transforming the number from a dial string (see [RFC3966]), removing any national or international dialing prefixes or performing similar procedures. It is only in the case that an implementation cannot determine how to convert the number to a globally-routable format that this step may be skipped. This will be the case, for example, for nationally-specific service numbers (e.g. 911, 112); - however, the routing procedures associated with those numbers will - likely make sure that the verification service understands the - context of their use. + however, calls to those numbers are routed in a very strict + fashion which ordinarily prevents them from reaching entities that + don't understand the numbers. - Other transformations during canonicalization MAY be made in - accordance with specific policies used within a local domain. For - example, one domain may only use local number formatting and need - to convert all To/From header field user portions to E.164 by - prepending country-code and region code digits; another domain - might have prefixed usernames with trunk-routing codes, in which - case the canonicalization will need to remove the prefix. This - specification cannot anticipate all of the potential - transformations that might be useful. + Some domains may need to take unique steps to convert their + numbers into a global format, and such transformations during + canonicalization can also be made in accordance with specific + policies used within a local domain. For example, one domain may + only use local number formatting and need to convert all To/From + header field user portions to E.164 by prepending country-code and + region code digits; another domain might have prefixed usernames + with trunk-routing codes, in which case the canonicalization will + need to remove the prefix. This specification cannot anticipate + all of the potential transformations that might be useful. The resulting canonical number string will be used as input to the hash calculation during signing and verifying processes. The ABNF of this number string is: tn-spec = [ "#" / "*" ] 1*DIGIT The resulting number string is used in the construction of the telephone number field(s) in a PASSporT object. @@ -1297,21 +1303,26 @@ component. A more exact definition is left to future specifications. 9. Extensibility As future requirements may warrant increasing the scope of the Identity mechanism, this specification specifies an optional "ppt" parameter of the Identity header field, which mirrors the "ppt" header in PASSporT. The "ppt" parameter value MUST consist of a token containing an extension specification, which denotes an extended set of one or more signed claims per the type extensibility - mechanism specified in [I-D.ietf-stir-passport] Section 6. + mechanism specified in [I-D.ietf-stir-passport] Section 7. Note that + per the guidance in that section, "ppt" is used only to enforce a + mandatory extension: optional claims may be added to any PASSporT + object without requiring the use of "ppt", but the compact form of + PASSporT MUST NOT be used when optional claims are present in the + PASSporT payload. The potential for extensions is one the primary motivations for allowing the presence of multiple Identity header fields in the same SIP request. It is envisioned that future extensions might allow for alternate information to be signed, or to explicitly allow different parties to provide the signatures than the authorities envisioned by baseline STIR. A request might, for example, have one Identity added by an authentication service at the originating administrative domain, and then another Identity header field added by some further intermediary using a PASSporT extension. While this specification @@ -1319,42 +1330,36 @@ header fields, implementations MUST support receiving multiple header fields for future compatibility reasons. An authentication service cannot assume that verifiers will understand any given extension. Verifiers that do support an extension may then trigger appropriate application-level behavior in the presence of an extension; authors of extensions should provide appropriate extension-specific guidance to application developers on this point. - If any claim in an extension contains a JSON value that does not - correspond to a field of the SIP request, and the extension does not - otherwise explain how a verification service could derive or acquire - that value, then the optional "canon" parameter MUST be used for the - Identity header field containing that extension. - -10. Backwards Compatibililty with RFC4474 +10. Backwards Compatibility with RFC4474 This specification introduces several significant changes from the RFC4474 version of the Identity header field. However, due to the problems enumerated in [I-D.rosenberg-sip-rfc4474-concerns], it is not believed that the original Identity header field has seen any deployment, or even implementation in deployed products. As such, this mechanism contains no provisions for signatures generated with this specification to work with RFC4474-compliant implementations, nor any related backwards-compatibility provisions. Hypothetically, were an RFC4474-compliant implementation to receive messages containing this revised version of the Identity header - field, it would likely fail the request due to the absence of an - Identity-Info header field with a 436 response code. Implementations - of this specification, for debugging purposes, might interpret a 436 + field, it would likely fail the request with a 436 response code due + to the absence of an Identity-Info header field. Implementations of + this specification, for debugging purposes, might interpret a 436 with a reason phrase of "Bad Identity-Info" as an indication that the request has failed because it reached a (hypothetical) RFC4474-compliant verification service. 11. Privacy Considerations The purpose of this mechanism is to provide a reliable identification of the originator of a SIP request, specifically a cryptographic assurance that an authority asserts the originator can claim the URI the identity stipulated in the request. This URI may contain or @@ -1412,41 +1416,41 @@ beyond what appears in the From header field; P-Asserted-Identity holds a definitive identity for the originator that is somehow known to a closed network of intermediaries. Presumably, that network will use this identity for billing or security purposes. The danger of this network-specific information leaking outside of the closed network motivated the "id" priv-value token. The "id" priv-value token has no implications for the Identity header field, and privacy services MUST NOT remove the Identity header field when a priv-value of "id" appears in a Privacy header field. - The optional "canon" parameter of the Identity header field specified - in this document provides the complete JSON objects used to generate - the signed-identity-digest of the Identity header field value, - including the canonicalized form of the telephone number of the - originator of a call, if the signature is over a telephone number. - In some contexts, local policy may require a canonicalization which - differs substantially from the original From header field. Depending - on those policies, potentially the "canon" parameter might divulge - information about the originating network or user that might not - appear elsewhere in the SIP request. Were it to be used to reflect - the contents of the P-Asserted-Identity header field, for example, - then "canon" would need to be removed when the P-Asserted-Identity - header is removed to avoid any such leakage outside of a trust - domain. Since, in those contexts, the canonical form of the - originator's identity could not be reassembled by a verifier, and - thus the Identity signature validation process would fail, using P- - Asserted-Identity with the Identity "canon" parameter in this fashion - is NOT RECOMMENDED outside of environments where SIP requests will - never leave the trust domain. As a side note, history shows that - closed networks never stay closed and one should design their - implementation assuming connectivity to the broader Internet. + The full form of the PASSporT object provides the complete JSON + objects used to generate the signed-identity-digest of the Identity + header field value, including the canonicalized form of the telephone + number of the originator of a call, if the signature is over a + telephone number. In some contexts, local policy may require a + canonicalization which differs substantially from the original From + header field. Depending on those policies, potentially the full form + of PASSporT might divulge information about the originating network + or user that might not appear elsewhere in the SIP request. Were it + to be used to reflect the contents of the P-Asserted-Identity header + field, for example, then the object would need to be converted to the + compact form when the P-Asserted-Identity header is removed to avoid + any such leakage outside of a trust domain. Since, in those + contexts, the canonical form of the originator's identity could not + be reassembled by a verifier, and thus the Identity signature + validation process would fail, using P-Asserted-Identity with the + full form of PASSporT in this fashion is NOT RECOMMENDED outside of + environments where SIP requests will never leave the trust domain. + As a side note, history shows that closed networks never stay closed + and one should design their implementation assuming connectivity to + the broader Internet. Finally, note that unlike [RFC3325], the mechanism described in this specification adds no information to SIP requests that has privacy implications - apart from disclosing that an authentication service is willing to sign for an originator. 12. Security Considerations This document describes a mechanism that provides a signature over the Date header field of SIP requests, parts of the To and From @@ -1485,26 +1489,26 @@ received requests, and thus if an Identity header field is replayed by an attacker within the Date interval, verifiers can detect that it is spoofed because a message with an identical Date from the same source had recently been received. It has been observed in the wild that some networks change the Date header field value of SIP requests in transit, and that alternative behavior might be necessary to accommodate that use case. Verification services that observe a signature validation failure MAY therefore reconstruct the Date header field component of the - signature from the "iat" carried in PASSporT via the "canon" - parameter: provided that time recorded by "iat" falls within the - local policy for freshness that would ordinarily apply to the Date - header, the verification service MAY treat the signature as valid, - provided it keeps adequate state to detect recent replays. Note that - this will require the inclusion of the "canon" parameter by + signature from the "iat" carried in the full form of PASSporT: + provided that time recorded by "iat" falls within the local policy + for freshness that would ordinarily apply to the Date header, the + verification service MAY treat the signature as valid, provided it + keeps adequate state to detect recent replays. Note that this will + require the inclusion of the full form of the PASSporT object by authentication services in networks where such failures are observed. The To header field value provides the identity of the SIP user that this request originally targeted. Covering the identity in the To header field with the Identity signature serves two purposes. First, it prevents cut-and-paste attacks in which an Identity header field from a legitimate request for one user is cut-and-pasted into a request for a different user. Second, it preserves the starting URI scheme of the request, which helps prevent downgrade attacks against the use of SIPS. The To identity offers additional protection @@ -1643,22 +1647,22 @@ Without TLS, the various header field values and the body of the request will not have integrity protection when the request arrives at an authentication service. Accordingly, a prior legitimate or illegitimate intermediary could modify the message arbitrarily. Of these two concerns, the first is most material to the intended scope of this mechanism. This mechanism is intended to prevent impersonation attacks, not man-in-the-middle attacks; integrity over - parts of the the header and body is provided by this mechanism only - to prevent replay attacks. However, it is possible that applications + parts of the header and body is provided by this mechanism only to + prevent replay attacks. However, it is possible that applications relying on the presence of the Identity header field could leverage this integrity protection for services other than replay protection. Accordingly, direct TLS connections SHOULD be used between the UAC and the authentication service whenever possible. The opportunistic nature of this mechanism, however, makes it very difficult to constrain UAC behavior, and moreover there will be some deployment architectures where a direct connection is simply infeasible and the UAC cannot act as an authentication service itself. Accordingly, when a direct connection and TLS are not possible, a UAC should use @@ -1757,48 +1761,52 @@ The 437 "Unsupported Certificate" default reason phrase should be changed to "Unsupported Credential". 13.3. Identity-Info Parameters The IANA manages a registry for Identity-Info parameters. The specification asks the IANA to change the name of this registry to "Identity Parameters". - This specification defines two new values for the registry: "canon" - as defined in this specification in Section 4.1.1; and "info" as + The "alg" parameter entry in the registry should be updated to + reference [RFCThis] as its specification. + + This specification defines one new value for the registry: "info" as defined in this specification in Section 7.3. 13.4. Identity-Info Algorithm Parameter Values This IANA manages an Identity-Info Algorithm Parameter Values - registry which this specification deprecates. Since the algorithms - for signing PASSporT objects are defined in PASSporT rather than in - this specification, there is no longer a need for an algorithm - parameter registry for the Identity header field. + registry which this specification deprecates. We request that the + IANA delete this registry. Since the algorithms for signing + PASSporTs are defined in [I-D.ietf-stir-passport] rather than in this + specification, there is no longer a need for an algorithm parameter + registry for the Identity header field. 14. Acknowledgments - The authors would like to thank Olle Jacobson, Dave Frankel, Robert - Sparks, Dave Crocker, Stephen Kent, Brian Rosen, Alex Bobotek, Paul - Kyzviat, Jonathan Lennox, Richard Shockey, Martin Dolly, Andrew - Allen, Hadriel Kaplan, Sanjay Mishra, Anton Baskov, Pierce Gorman, - David Schwartz, Eric Burger, Alan Ford, Christer Holmberg, Philippe - Fouquart, Michael Hamer, Henning Schulzrinne, and Richard Barnes for - their comments. + The authors would like to thank Syed Ali, Olle Jacobson, Dave + Frankel, Robert Sparks, Dave Crocker, Stephen Kent, Brian Rosen, Alex + Bobotek, Paul Kyzviat, Jonathan Lennox, Richard Shockey, Martin + Dolly, Andrew Allen, Hadriel Kaplan, Sanjay Mishra, Anton Baskov, + Pierce Gorman, David Schwartz, Eric Burger, Alan Ford, Christer + Holmberg, Philippe Fouquart, Michael Hamer, Henning Schulzrinne, and + Richard Barnes for their comments. 15. Changes from RFC4474 The following are salient changes from the original RFC 4474: Generalized the credential mechanism; credential enrollment, acquisition and trust is now outside the scope of this document + Reduced the scope of the Identity signature to remove CSeq, Call- ID, Contact, and the message body; signing of key fingerprints in SDP is now included Deprecated the Identity-Info header field and relocated its components into parameters of the Identity header field (which obsoletes the previous version of the header field) The Identity header field can now appear multiple times in one request @@ -1861,21 +1868,21 @@ [I-D.ietf-iri-comparison] Masinter, L. and M. DĂźrst, "Comparison, Equivalence and Canonicalization of Internationalized Resource Identifiers", draft-ietf-iri-comparison-02 (work in progress), October 2012. [I-D.ietf-stir-certificates] Peterson, J. and S. Turner, "Secure Telephone Identity Credentials: Certificates", draft-ietf-stir- - certificates-07 (work in progress), July 2016. + certificates-08 (work in progress), September 2016. [I-D.kaplan-stir-cider] Kaplan, H., "A proposal for Caller Identity in a DNS-based Entrusted Registry (CIDER)", draft-kaplan-stir-cider-00 (work in progress), July 2013. [I-D.peterson-sipping-retarget] Peterson, J., "Retargeting and Security in SIP: A Framework and Requirements", draft-peterson-sipping- retarget-00 (work in progress), February 2005. @@ -1969,33 +1976,33 @@ Authors' Addresses Jon Peterson Neustar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US Email: jon.peterson@neustar.biz + Cullen Jennings Cisco 400 3rd Avenue SW, Suite 350 Calgary, AB T2P 4H2 Canada - Email: fluffy@iii.ca + Email: fluffy@cisco.com Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 USA Email: ekr@rtfm.com - Chris Wendt Comcast One Comcast Center Philadelphia, PA 19103 USA Email: chris-ietf@chriswendt.net