draft-ietf-stir-passport-rcd-08.txt   draft-ietf-stir-passport-rcd-09.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft Neustar Inc. Internet-Draft Neustar Inc.
Intended status: Standards Track C. Wendt Intended status: Standards Track C. Wendt
Expires: May 20, 2021 Comcast Expires: May 20, 2021 Comcast
November 16, 2020 November 16, 2020
PASSporT Extension for Rich Call Data PASSporT Extension for Rich Call Data
draft-ietf-stir-passport-rcd-08 draft-ietf-stir-passport-rcd-09
Abstract Abstract
This document extends PASSporT, a token for conveying This document extends PASSporT, a token for conveying
cryptographically-signed call information about personal cryptographically-signed call information about personal
communications, to include rich meta-data about a call and caller communications, to include rich meta-data about a call and caller
that can be signed and integrity protected, transmitted, and that can be signed and integrity protected, transmitted, and
subsequently rendered to users. This framework is intended to extend subsequently rendered to users. This framework is intended to extend
caller and call specific information beyond human-readable display caller and call specific information beyond human-readable display
name comparable to the "Caller ID" function common on the telephone name comparable to the "Caller ID" function common on the telephone
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of the use of the Rich Call Data PASSporT extension 4 3. Overview of the use of the Rich Call Data PASSporT extension 4
4. Overview of Rich Call Data integrity . . . . . . . . . . . . 5 4. Overview of Rich Call Data integrity . . . . . . . . . . . . 5
5. PASSporT Claims . . . . . . . . . . . . . . . . . . . . . . . 6 5. PASSporT Claims . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. PASSporT "rcd" Claim . . . . . . . . . . . . . . . . . . 6 5.1. PASSporT "rcd" Claim . . . . . . . . . . . . . . . . . . 6
5.1.1. "nam" key . . . . . . . . . . . . . . . . . . . . . . 6 5.1.1. "nam" key . . . . . . . . . . . . . . . . . . . . . . 6
5.1.2. "jcd" key . . . . . . . . . . . . . . . . . . . . . . 6 5.1.2. "jcd" key . . . . . . . . . . . . . . . . . . . . . . 6
5.1.3. "jcl" key . . . . . . . . . . . . . . . . . . . . . . 6 5.1.3. "jcl" key . . . . . . . . . . . . . . . . . . . . . . 7
5.1.4. "rcdi" RCD integrity Claim . . . . . . . . . . . . . 7 5.1.4. "rcdi" RCD integrity Claim . . . . . . . . . . . . . 7
5.1.5. Creation of the "rcd" digest . . . . . . . . . . . . 7 5.1.5. Creation of the "rcd" digest . . . . . . . . . . . . 7
5.1.6. JWT Constraint for "rcdi" claim . . . . . . . . . . . 9 5.1.6. JWT Constraint for "rcdi" claim . . . . . . . . . . . 9
5.2. PASSporT "crn" claim - Call Reason . . . . . . . . . . . 9 5.2. PASSporT "crn" claim - Call Reason . . . . . . . . . . . 9
5.2.1. JWT Constraint for "cdn" claim . . . . . . . . . . . 9 5.2.1. JWT Constraint for "cdn" claim . . . . . . . . . . . 10
6. "rcd" and "crn" Claims Usage . . . . . . . . . . . . . . . . 9 6. "rcd" and "crn" Claims Usage . . . . . . . . . . . . . . . . 10
6.1. Example "rcd" PASSporTs . . . . . . . . . . . . . . . . . 10 6.1. Example "rcd" PASSporTs . . . . . . . . . . . . . . . . . 10
7. Compact form of "rcd" PASSporT . . . . . . . . . . . . . . . 12 7. Compact form of "rcd" PASSporT . . . . . . . . . . . . . . . 12
7.1. Compact form of the "rcd" PASSporT claim . . . . . . . . 12 7.1. Compact form of the "rcd" PASSporT claim . . . . . . . . 13
7.2. Compact form of the "rcdi" PASSporT claim . . . . . . . . 12 7.2. Compact form of the "rcdi" PASSporT claim . . . . . . . . 13
7.3. Compact form of the "crn" PASSporT claim . . . . . . . . 12 7.3. Compact form of the "crn" PASSporT claim . . . . . . . . 13
8. Further Information Associated with Callers . . . . . . . . . 13 8. Further Information Associated with Callers . . . . . . . . . 13
9. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 13 9. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Signing as a Third Party . . . . . . . . . . . . . . . . 15 9.1. Signing as a Third Party . . . . . . . . . . . . . . . . 15
10. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 15 10. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 16
11. Using "rcd" in SIP . . . . . . . . . . . . . . . . . . . . . 16 11. Using "rcd" in SIP . . . . . . . . . . . . . . . . . . . . . 16
11.1. Authentication Service Behavior . . . . . . . . . . . . 16 11.1. Authentication Service Behavior . . . . . . . . . . . . 16
11.2. Verification Service Behavior . . . . . . . . . . . . . 16 11.2. Verification Service Behavior . . . . . . . . . . . . . 17
12. Using "rcd" as additional claims to other PASSporT extensions 18 12. Using "rcd" as additional claims to other PASSporT extensions 18
12.1. Procedures for applying "rcd" as claims only . . . . . . 18 12.1. Procedures for applying "rcd" as claims only . . . . . . 18
12.2. Example for applying "rcd" as claims only . . . . . . . 18 12.2. Example for applying "rcd" as claims only . . . . . . . 19
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
14.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 19 14.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 20
14.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 20 14.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 20
14.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 20 14.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 20
15. Security Considerations . . . . . . . . . . . . . . . . . . . 20 15. Security Considerations . . . . . . . . . . . . . . . . . . . 21
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
16.1. Normative References . . . . . . . . . . . . . . . . . . 20 16.1. Normative References . . . . . . . . . . . . . . . . . . 21
16.2. Informative References . . . . . . . . . . . . . . . . . 22 16.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
PASSporT [RFC8225] is a token format based on JWT [RFC7519] for PASSporT [RFC8225] is a token format based on JWT [RFC7519] for
conveying cryptographically-signed information about the people conveying cryptographically-signed information about the people
involved in personal communications; it is used to convey a signed involved in personal communications; it is used to convey a signed
assertion of the identity of the participants in real-time assertion of the identity of the participants in real-time
communications established via a protocol like SIP [RFC8224]. The communications established via a protocol like SIP [RFC8224]. The
skipping to change at page 6, line 21 skipping to change at page 6, line 21
This specification defines a new JSON Web Token claim for "rcd", Rich This specification defines a new JSON Web Token claim for "rcd", Rich
Call Data, the value of which is a JSON object that can contain one Call Data, the value of which is a JSON object that can contain one
or more key value pairs. This document defines a default set of key or more key value pairs. This document defines a default set of key
values. values.
5.1.1. "nam" key 5.1.1. "nam" key
The "nam" key value is a display name, associated with the originator The "nam" key value is a display name, associated with the originator
of personal communications, which may for example derive from the of personal communications, which may for example derive from the
display-name component of the From header field value of a SIP display-name component of the From header field value of a SIP
request, or a similar field in other PASSporT using protocols. This request or alternatively from the P-Asserted-Identity header field
value, or a similar field in other PASSporT using protocols. This
key MUST be included once and MUST be included as part of the "rcd" key MUST be included once and MUST be included as part of the "rcd"
claim value JSON object. If there is no string associated with a claim value JSON object. If there is no string associated with a
display name, the claim value SHOULD then be an empty string. display name, the claim value SHOULD then be an empty string.
5.1.2. "jcd" key 5.1.2. "jcd" key
The "jcd" key value is defined to contain a value of a jCard The "jcd" key value is defined to contain a value of a jCard
[RFC7095] JSON object. This jCard object is intended to represent [RFC7095] JSON object. This jCard object is intended to represent
and derives from the Call-Info header field value defined in and derives from the Call-Info header field value defined in
[I-D.ietf-sipcore-callinfo-rcd] with a type of "jcard". As also [I-D.ietf-sipcore-callinfo-rcd] with a type of "jcard". As also
skipping to change at page 6, line 51 skipping to change at page 7, line 9
Note: even though we refer to [I-D.ietf-sipcore-callinfo-rcd] as the Note: even though we refer to [I-D.ietf-sipcore-callinfo-rcd] as the
definition of the jcard properties for usage in a "rcd" PASSporT, definition of the jcard properties for usage in a "rcd" PASSporT,
other protocols can be adapted for use of "jcd" (or similarly "jcl" other protocols can be adapted for use of "jcd" (or similarly "jcl"
below) key beyond SIP and Call-Info. below) key beyond SIP and Call-Info.
5.1.3. "jcl" key 5.1.3. "jcl" key
The "jcl" key value is defined to contain a HTTPS URL that refers the The "jcl" key value is defined to contain a HTTPS URL that refers the
recipient to a jCard [RFC7095] JSON object hosted on a HTTPS enabled recipient to a jCard [RFC7095] JSON object hosted on a HTTPS enabled
web server. This link may derive from the Call-Info header field web server. The web server MUST use the MIME media type for JSON
value defined in [I-D.ietf-sipcore-callinfo-rcd] with a type of text as application/json with a default encoding of UTF-8 [RFC4627].
"jcard". As also defined in [I-D.ietf-sipcore-callinfo-rcd], format This link may derive from the Call-Info header field value defined in
of the jCard and properties used should follow the normative usage [I-D.ietf-sipcore-callinfo-rcd] with a type of "jcard". As also
and formatting rules and procedures. The "jcl" key is optional. If defined in [I-D.ietf-sipcore-callinfo-rcd], format of the jCard and
included, this key MUST only be included once in the "rcd" JSON properties used should follow the normative usage and formatting
object and MUST NOT be included if there is a "jcd" key included. rules and procedures. The "jcl" key is optional. If included, this
The "jcd" and "jcl" keys MUST be used mutually exclusively. key MUST only be included once in the "rcd" JSON object and MUST NOT
be included if there is a "jcd" key included. The "jcd" and "jcl"
keys MUST be used mutually exclusively.
5.1.4. "rcdi" RCD integrity Claim 5.1.4. "rcdi" RCD integrity Claim
The "rcdi" claim is an optional claim that SHOULD be included if the The "rcdi" claim is an optional claim that SHOULD be included if the
application requires integrity to be applied to the content of the application requires integrity to be applied to the content of the
"rcd" claim and if included MUST be included only once with a "rcd" claim and if included MUST be included only once with a
corresponding "rcd" claim. The value of the "rcdi" key pair should corresponding "rcd" claim. The value of the "rcdi" key pair should
contain a string that is defined as follows. contain a string that is defined as follows.
The first part of the string should define the crypto algorithm used The first part of the string should define the crypto algorithm used
skipping to change at page 10, line 26 skipping to change at page 10, line 41
After the header and claims PASSporT objects have been constructed, After the header and claims PASSporT objects have been constructed,
their signature is generated normally per the guidance in [RFC8225]. their signature is generated normally per the guidance in [RFC8225].
6.1. Example "rcd" PASSporTs 6.1. Example "rcd" PASSporTs
An example of a "nam" only PASSporT claims obejct is shown next (with An example of a "nam" only PASSporT claims obejct is shown next (with
line breaks for readability only). line breaks for readability only).
{ "orig":{"tn":"12025551000"}, { "orig":{"tn":"12025551000"},
"dest":{"tn":"12025551001"}, "dest":{"tn":["12025551001"]},
"iat":1443208345, "iat":1443208345,
"rcd":{"nam":"James Bond"} } "rcd":{"nam":"James Bond"} }
An example of a "nam" only PASSporT claims object with an "rcdi" An example of a "nam" only PASSporT claims object with an "rcdi"
claim is shown next (with line breaks for readability only). claim is shown next (with line breaks for readability only).
{ "orig":{"tn":"12025551000"}, { "orig":{"tn":"12025551000"},
"dest":{"tn":"12025551001"}, "dest":{"tn":["12025551001"]},
"iat":1443208345, "iat":1443208345,
"rcd":{"nam":"James Bond"} "rcd":{"nam":"James Bond"}
"rcdi":"sha256-H8BRh8j48O9oYatfu5AZzq6A9R6dQZngK7T62em8MUt1FLm52" "rcdi":"sha256-H8BRh8j48O9oYatfu5AZzq6A9R6dQZngK7T62em8MUt1FLm52"
} }
An example of a PASSporT claims object that includes the "jcd" which An example of a PASSporT claims object that includes the "jcd" which
is optional, but will also include the mandatory "nam" object is is optional, but will also include the mandatory "nam" object is
shown next (with line breaks for readability only). shown next (with line breaks for readability only).
{ "orig":{"tn":"12025551000"}, { "orig":{"tn":"12025551000"},
"dest":{"tn":"12155551001"}, "dest":{"tn":["12155551001"]},
"iat":1443208345, "iat":1443208345,
"rcd":{"nam":"James Bond","jcd":["vcard",[["version",{},"text", "rcd":{"nam":"James Bond","jcd":["vcard",[["version",{},"text",
"4.0"], "4.0"],
["fn",{},"text", "James Bond"], ["fn",{},"text", "James Bond"],
["n",{},"text",["Bond","James","","","Mr."]], ["n",{},"text",["Bond","James","","","Mr."]],
["adr",{"type":"work"},"text", ["adr",{"type":"work"},"text",
["","","3100 Massachusetts Avenue NW","Washington","DC", ["","","3100 Massachusetts Avenue NW","Washington","DC",
"20008","USA"] "20008","USA"]
], ],
["email",{},"text","007@mi6-hq.com"], ["email",{},"text","007@mi6-hq.com"],
skipping to change at page 16, line 24 skipping to change at page 16, line 44
11.1. Authentication Service Behavior 11.1. Authentication Service Behavior
An authentication service creating a PASSporT containing a "rcd" An authentication service creating a PASSporT containing a "rcd"
claim MAY include a "ppt" for "rcd" or not. Third-party claim MAY include a "ppt" for "rcd" or not. Third-party
authentication services following the behavior in Section 9.1 MUST authentication services following the behavior in Section 9.1 MUST
include a "ppt" of "rcd". If "ppt" does contain a "rcd", then any include a "ppt" of "rcd". If "ppt" does contain a "rcd", then any
SIP authentication services MUST add a "ppt" parameter to the SIP authentication services MUST add a "ppt" parameter to the
Identity header containing that PASSporT with a value of "rcd". The Identity header containing that PASSporT with a value of "rcd". The
resulting Identity header might look as follows: resulting Identity header might look as follows:
Identity: sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9 Identity: sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9
dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0 dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgt
Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=; \ w0Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=; \
info=<https://biloxi.example.org/biloxi.cer>;alg=ES256;ppt=rcd info=<https://biloxi.example.org/biloxi.cer>;alg=ES256;ppt=rcd
This specification assumes that by default, a SIP authentication This specification assumes that by default, a SIP authentication
service will derive the value of "rcd", specifically only for the service will derive the value of "rcd", specifically only for the
"nam" key value, from the display-name component of the From header "nam" key value, from the display-name component of the From header
field value of the request, alternatively for some calls this may field value of the request, alternatively for some calls this may
come from the P-Asserted-ID header. It is however a matter of come from the P-Asserted-ID header. It is however a matter of
authentication service policy to decide how it populates the value of authentication service policy to decide how it populates the value of
"rcd" and "nam" key, which MAY also derive from other fields in the "rcd" and "nam" key, which MAY also derive from other fields in the
request, from customer profile data, or from access to external request, from customer profile data, or from access to external
services. If the authentication service generates a PASSporT object services. If the authentication service generates a PASSporT object
skipping to change at page 21, line 16 skipping to change at page 21, line 36
Rescorla, E. and J. Peterson, "STIR Out-of-Band Rescorla, E. and J. Peterson, "STIR Out-of-Band
Architecture and Use Cases", draft-ietf-stir-oob-07 (work Architecture and Use Cases", draft-ietf-stir-oob-07 (work
in progress), March 2020. in progress), March 2020.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627,
DOI 10.17487/RFC4627, July 2006,
<https://www.rfc-editor.org/info/rfc4627>.
[RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words
for Use in RFCs to Indicate Requirement Levels", RFC 6919, for Use in RFCs to Indicate Requirement Levels", RFC 6919,
DOI 10.17487/RFC6919, April 2013, DOI 10.17487/RFC6919, April 2013,
<https://www.rfc-editor.org/info/rfc6919>. <https://www.rfc-editor.org/info/rfc6919>.
[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
DOI 10.17487/RFC7095, January 2014, DOI 10.17487/RFC7095, January 2014,
<https://www.rfc-editor.org/info/rfc7095>. <https://www.rfc-editor.org/info/rfc7095>.
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
 End of changes. 17 change blocks. 
31 lines changed or deleted 39 lines changed or added

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