idnits 2.17.1 draft-peterson-stir-cnam-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 31, 2016) is 2732 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCThis' is mentioned on line 296, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-stir-passport-09 == Outdated reference: A later version (-16) exists of draft-ietf-stir-rfc4474bis-14 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Peterson 3 Internet-Draft Neustar 4 Intended status: Informational C. Wendt 5 Expires: May 4, 2017 Comcast 6 October 31, 2016 8 PASSporT Extension for Caller Name 9 draft-peterson-stir-cnam-01.txt 11 Abstract 13 This document extends the PASSporT object, which conveys 14 cryptographically-signed information about the people involved in 15 personal communications, to include a human-readable display name 16 comparable to the "Caller ID" function common on the telephone 17 network. The element defined for this purpose is extensible to 18 include related information callers. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 4, 2017. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. PASSporT 'cna' Claim . . . . . . . . . . . . . . . . . . . . 3 57 4. Using 'cna' in SIP . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. Authentication Service Behavior . . . . . . . . . . . . . 4 59 4.2. Verification Service Behavior . . . . . . . . . . . . . . 4 60 5. Third Party Uses . . . . . . . . . . . . . . . . . . . . . . 5 61 6. Further Information Associated with Callers . . . . . . . . . 6 62 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 8.1. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 6 65 8.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 6 66 8.3. PASSporT CNA Types . . . . . . . . . . . . . . . . . . . 7 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 10. Informative References . . . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 PASSporT [I-D.ietf-stir-passport] is a token format based on JWT 74 [RFC7519] for conveying cryptographically-signed information about 75 the people involved in personal communications; it is used with STIR 76 [I-D.ietf-stir-rfc4474bis] to convey a signed assertion of the 77 identity of the participants in real-time communications established 78 via a protocol like SIP. This specification extends PASSporT to 79 carry the name of the person on one side of a communications session, 80 along with related display information that would typically be 81 rendered to the called party during alerting. This format is 82 designed to be extended with additional elements to convey richer 83 information. 85 In the traditional telephone network, the display name associated 86 with a call is typically provided in one of three ways: by the 87 originator of a call, by a third-party service queried by the 88 terminating side, or through a local address book maintained by a 89 device on the terminating side. The STIR architecture lends itself 90 especially to the first of these approaches, as it assumes that an 91 authority on the originating side of the call provides a 92 cryptographic assurance of the validity of the calling party number 93 in order to prevent impersonation attacks. That same authority could 94 sign for a display name associated with that number, which the 95 terminating side could render to the user when the call is alerting. 96 But even when the originating side cannot provide a display name for 97 the caller, the cryptographic attestation of the validity of the 98 number provided by STIR allows the terminating side to query a local 99 or remote service for a name associated with that number without fear 100 that the number has been impersonated. This specification also 101 outlines various ways that a display name for a calling party could 102 be associated with a call on the terminating side in a secure 103 fashion. 105 The STIR problem statement [RFC7340] notes that securing the display 106 name of callers is outside of STIR's immediate scope, so it includes 107 no core feature for caller name. This specification documents an 108 optional extension to PASSporT and the associated STIR mechanisms to 109 provide this function. 111 2. Terminology 113 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 114 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 115 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 116 described in RFC 2119 [RFC2119] and RFC 6919 [RFC6919]. 118 3. PASSporT 'cna' Claim 120 This specification defines a new JSON Web Token claim for "cna", 121 which provides a display name associated with the originator of 122 personal communications. This name may for example derive from the 123 display-name component of the From header field value of a SIP 124 request, or a similar field in other PASSporT using protocols. 126 The "cna" claim may appear in the PASSporT claim as an optional 127 element. The creator of a PASSporT object can however add a "ppt" 128 value of "cna" to the header of a PASSporT object as well, in which 129 case the PASSporT claims MUST contain a "cna" claim, and any entities 130 verifying the PASSporT object will be required to understand the 131 "ppt" extension in order to process the PASSporT in question. A 132 header wih the "ppt" included will look as follows: 134 { "typ":"passport", 135 "ppt":"cna", 136 "alg":"RS256", 137 "x5u":"https://www.example.com/cert.cer" } 139 The PASSporT claims object will then contain the "cna" key with its 140 corresponding value. The value of "cna" is an array of JSON objects, 141 of which one, the "nam" object, is mandatory. The key syntax of 142 "nam" follows the display-name ABNF given in [RFC3261]. 144 { "orig":{"tn":"12155551212"}, 145 "dest":{"tn":"12155551213"}, 146 "iat":1443208345, 147 "cna":{"nam":"Alice A"} } 149 After the header and claims PASSporT objects have been constructed, 150 their signature is generated normally per the guidance in 151 [I-D.ietf-stir-passport]. 153 4. Using 'cna' in SIP 155 This section specifies SIP-specific usage for the "cna" claim in 156 PASSporT, and in the SIP Identity header field value. Other using 157 protocols of PASSporT may define their own usages for the "cna" 158 claim. 160 4.1. Authentication Service Behavior 162 A PASSporT containing a "cna" claim may contain a "ppt" for "cna" or 163 not. If "ppt" does contain a "cna", then any SIP authentication 164 services MUST add a "ppt" parameter to the Identity header containing 165 that PASSporT with a value of "cna". The resulting Identity header 166 might look as follows: 168 Identity: "sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo 169 eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp 170 pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs="; \ 171 info=;alg=RS256;ppt="cna" 173 Otherwise, there is no no need for the "ppt" parameter of the SIP 174 Identity header. 176 A SIP authentication service typically will derive the value of "cna" 177 from the display-name component of the From header field value. It 178 is however a matter of authentication service policy to decide how it 179 populates the value of "cna", which might also derive from other 180 fields in the request, from customer profile data or from access to 181 external services. If the authentication service generates a 182 PASSporT object containing "cna" with a value that is not equivalent 183 to the From header field display-name value, it MUST use the full 184 form of the PASSporT object. 186 4.2. Verification Service Behavior 188 [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires that 189 specifications defining "ppt" values describe any additional verifier 190 behavior. The behavior specified for the "ppt" values of "cna" is as 191 follows. If the PASSporT is in compact form, then the verification 192 service SHOULD extract the display-name from the From header field 193 value, if any, and use that as the value for the "cna" key when it 194 recomputes the header and claims of the PASSporT object. If the 195 signature validates over the recomputed object, then the verification 196 should be considered successful. 198 However, if the PASSport is in full form with a "ppt" value of "cna", 199 then the verification service MUST extract the value associated with 200 the "cna" "nam" key in the object. If the signature validates, then 201 the verification service can use the value of the "cna" "nam" key as 202 the display name of calling party, which would in turn be rendered to 203 alerted users or otherwise leveraged in accordance with local policy. 204 This will allow SIP networks that convey the display name through a 205 field other than the From header field to interoperate with this 206 specification. 208 The behavior of a SIP UAS upon receiving an INVITE containing a 209 PASSporT object with a "cna" claim will largely remain a matter of 210 implementation policy. In most cases, implementations would render 211 this calling party name information to the user while alerting. Any 212 user interface additions to express confidence in the veracity of 213 this information are outside the scope of this specification. 215 5. Third Party Uses 217 When calling name information cannot be provided on the originating 218 side, a third-party information service may be queried by the 219 terminating side with the calling party's number in order to learn 220 the name of the calling party. This query could come from an 221 intermediary on the terminating side, or from the terminating user 222 agent, such as a smart phone. 224 An intermediary use case might look as follows: a SIP INVITE carries 225 a display name in its From header field value and an initial PASSporT 226 object without the "cna" claim. When the terminating verification 227 service receives this request, and determines that the signature is 228 valid, it might query a third-party service that maps telephone 229 numbers to calling party names. Upon receiving the response, the 230 terminating side could add a new Identity to the request (effectively 231 acting as an authentication service) which contains a "cna" PASSporT 232 object provided by the third-party service. If the display name in 233 the "cna" PASSporT object matches the display name in the INVITE, 234 then the name would presumably be rendered to the end user by the 235 terminating user agent. 237 Alternatively, it might be the terminating user agent that queries a 238 third-party service. In this case, no new Identity header would be 239 gneerated, though the terminating user agent might receive a PASSporT 240 object in return from the third-party service, and use the "cna" 241 field in the object as a calling name to render to users during 242 alerting. 244 Detailed behavior for third-party uses is left for future versions of 245 this specification. 247 6. Further Information Associated with Callers 249 Beyond naming information, there may be additional information about 250 the calling party that should be rendered to the end user. This may 251 include information related to the location of the caller, or to any 252 institutions that the caller is associated with, or even categories 253 of institutions. All of these data elements would benefit from the 254 secure attestations provided by the STIR and PASSporT frameworks. 255 The specification of the "cna" claim could entail the optional 256 presence of one or more such additional information fields. 258 A new IANA registry has been defined to hold potential values of the 259 "cna" array; see Section 8.3. Details of extensions to the "cna" 260 claim to encompass other data elements are left for future version of 261 this specification. 263 7. Acknowledgments 265 We would like to thank YOU for contributions to this problem 266 statement and framework. 268 8. IANA Considerations 270 8.1. JSON Web Token Claims 272 This specification requests that the IANA add a new claim to the JSON 273 Web Token Claims registry as defined in [RFC7519]. 275 Claim Name: "cna" 277 Claim Description: Caller Name Information 279 Change Controller: IESG 281 Specification Document(s): [RFCThis] 283 8.2. PASSporT Types 285 This specification requests that the IANA add a new entry to the 286 PASSporT Types registry for the type "cna" which is specified in 287 [RFCThis]. 289 8.3. PASSporT CNA Types 291 This document requests that the IANA create a new registry for 292 PASSporT CNA types. Registration of new PASSporT CNA types shall be 293 under the Specification Required policy. 295 This registry is to be initially populated with a single value for 296 "nam" which is specified in [RFCThis]. 298 9. Security Considerations 300 TBD. 302 10. Informative References 304 [I-D.ietf-stir-passport] 305 Wendt, C. and J. Peterson, "Personal Assertion Token 306 (PASSporT)", draft-ietf-stir-passport-09 (work in 307 progress), October 2016. 309 [I-D.ietf-stir-rfc4474bis] 310 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 311 "Authenticated Identity Management in the Session 312 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-14 313 (work in progress), October 2016. 315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 316 Requirement Levels", BCP 14, RFC 2119, 317 DOI 10.17487/RFC2119, March 1997, 318 . 320 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 321 A., Peterson, J., Sparks, R., Handley, M., and E. 322 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 323 DOI 10.17487/RFC3261, June 2002, 324 . 326 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 327 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 328 DOI 10.17487/RFC6919, April 2013, 329 . 331 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 332 Telephone Identity Problem Statement and Requirements", 333 RFC 7340, DOI 10.17487/RFC7340, September 2014, 334 . 336 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 337 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 338 . 340 Authors' Addresses 342 Jon Peterson 343 Neustar, Inc. 344 1800 Sutter St Suite 570 345 Concord, CA 94520 346 US 348 Email: jon.peterson@neustar.biz 350 Chris Wendt 351 Comcast 352 One Comcast Center 353 Philadelphia, PA 19103 354 USA 356 Email: chris-ietf@chriswendt.net