idnits 2.17.1 draft-asveren-stir-p-charge-info-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8225]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 8, 2018) is 2178 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC8224' is mentioned on line 165, but not defined == Missing Reference: 'RFCXXX' is mentioned on line 117, but not defined == Missing Reference: 'RFCThis' is mentioned on line 193, but not defined == Unused Reference: 'RFC2119' is defined on line 220, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 STIR T. Asveren 3 Internet-Draft Ribbon 4 Intended status: Standards Track May 8, 2018 5 Expires: November 9, 2018 7 PASSPorT Extension for P-Charge-Info Header 8 draft-asveren-stir-p-charge-info-00 10 Abstract 12 This document extends the PASSporT (Personal Assertion Token) 13 specification defined in [RFC8225] to allow the inclusion of 14 cryptographically signed assertions of authorization for the values 15 populated in the 'Session Initiation Protocol (SIP) P-Charge-Info' 16 header, which is used for conveying information about the entity to 17 be charged for a particular real time session. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 9, 2018. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 55 3. PASSPortT 'pci' Claim . . . . . . . . . . . . . . . . . . . . 3 56 4. Using 'pci' in SIP . . . . . . . . . . . . . . . . . . . . . 3 57 4.1. Authentication Service Behavior . . . . . . . . . . . . . 4 58 4.2. Verification Service Behavior . . . . . . . . . . . . . . 4 59 4.3. Other Behavior . . . . . . . . . . . . . . . . . . . . . 4 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 63 8. Informative References . . . . . . . . . . . . . . . . . . . 5 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 PASSporT RFC 8225 [RFC8225] is a token format based on JSON Web Token 69 (JWT) RFC 7519 [RFC7519] for conveying cryptographically signed 70 information about the identities involved in personal communications; 71 it is used with STIR RFC 8224 [RFC8224] to convey a signed assertion 72 of the identity of the participants in real-time communications 73 established via a protocol like SIP RFC 3261 [RFC3261]. This 74 specification extends PASSporT to allow cryptographic-signing of the 75 'SIP P-Charge-Info' header [RFCXXX], which is used to provide 76 information about the party to be charged for a real time session. 78 'SIP P-Charge-Info' header could be spoofed and abused by 79 unauthorized entities. Compromise of the 'SIP P-Charge-Info' header 80 would allow charging fraud. 82 Extension mechanisms defined in RFC8225 can be utilized to 83 cyrptographically sign the 'SIP P-Charge-Info' header. This would 84 allow a receiving entity to verify the validity of this header. 86 This specification documents an extension to PASSporT and the 87 associated STIR mechanisms to provide a function to sign the 'SIP P- 88 Charge-Info' header. 90 2. Requirements Language 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119. 96 3. PASSPortT 'pci' Claim 98 This specification defines a new JSON Web Token claim for "pci", 99 which provides an assertion for information in 'SIP P-Charge-Info' 100 header. 102 The creator of a PASSporT object adds a "ppt" value of "pci" to the 103 header of a PASSporT object, in which case the PASSporT claims MUST 104 contain a "pci" claim, and any entities verifying the PASSporT object 105 will be required to understand the "ppt" extension in order to 106 process the PASSporT in question. A PASSPorT header with the "ppt" 107 included will look as follows: 109 { 110 "typ":"passport", 111 "ppt":"pci", 112 "alg":"ES256", 113 "x5u":"https://www.example.org/cert.cer" 114 } 116 The "pci" claim will provide an assertion for information in the 'SIP 117 P-Charge-Info' header as defined in [RFCXXX] . 119 After the header and claims PASSporT objects have been constructed, 120 their signature is generated normally per the guidance in [RFC8225]. 121 The credentials (i.e., Certificate) used to create the signature must 122 have authority over the "pci" claim and there is only one authority 123 per claim. If P-Charge-Info header is added or by the intermediaries 124 along the path, intermediaries must generate a new "pci" header and 125 sign the claim with its own authority. 127 The following is an example "pci" claim for a 'SIP P-Charge-Info' 128 header field with a value of "12125550100" 130 { 131 "orig":{"tn":"12155550112"}, 132 "dest":{["tn":"12125550113"]}, 133 "iat":1443208345, 134 "pci":{["tn": "12125550100"]} 135 } 137 4. Using 'pci' in SIP 139 This section specifies SIP-specific usage for the "pci" PASSporT type 140 and its handling in the SIP Identity header field "ppt" parameter 141 value. Other using protocols of PASSporT may define behavior 142 specific to their use of the "pci" claim. 144 4.1. Authentication Service Behavior 146 An authentication service adds an Identity header field containing 147 the "pci" PASSporT type to an SIP request only if it adds a P-Charge- 148 Info header to the request. Whether to add such an Identity header 149 is controlled by local policy. When adding an Identity header field 150 with a PASSporT object containing a "pci" claim, SIP authentication 151 services MUST also add a "ppt" parameter to that Identity header with 152 a value of "pci". The resulting Identity header field to add to the 153 message might look as follows: 155 Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1I \ 156 joiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJ \ 157 kZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdC \ 158 I6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.r \ 159 q3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \ 160 ojNCpTzO3QfPOlckGaS6hEck7w;info=;alg=ES256;ppt="pci" 163 4.2. Verification Service Behavior 165 RFC 8224 [RFC8224] Section 6.2 Step 5 requires that specifications 166 defining "ppt" values describe any additional verifier behavior. The 167 behavior specified for the "pci" value of "ppt" is as follows. The 168 verification service MUST extract the value associated with the "pci" 169 key in a PASSPorT with a "ppt" value of "pci". If the signature 170 validates, then the verification service can use the value of the 171 "pci" claim as validation that P-Charge-Info in the received request 172 is authentic. The verifier MUST also ensure that the generator of 173 Identity header is authorized to declare the value used for P-Charge- 174 Info as the party to be charged. How this can be achieved is out of 175 the scope of this specification. 177 4.3. Other Behavior 179 An entity dropping P-Charge-Info MUST drop the corresponding Identity 180 header with "ppt" parameter value of "pci". 182 5. IANA Considerations 184 This specification requests that the IANA add a new claim to the JSON 185 Web Token Claims registry as defined in RFC 7519 [RFC7519]. 187 Claim Name: "pci" 189 Claim Description: Party to be charged for a session 191 Change Controller: IESG 193 Specification Document(s): [RFCThis] 195 6. Security Considerations 197 This specification describes a security feature, and is primarily 198 concerned with increasing security for information regarding the 199 party to be charged for a real time session. 201 A malicious entity may add a P-Charge-Info value and a corresponding 202 Identity header for charge abuse. This would be detected either 203 because the signature validation fails or because the malicious 204 entity does not have authority to declare the value of P-Charge-Info 205 as the party to be charged. 207 A malicious entity may drop the P-Charge-Info and the corresponding 208 Identity header. This would cause infoirmation about the actual 209 party to cherge not being present for a receiver entity which 210 otherwise would use it for billing purposes. One way to avoid this 211 type of attack would be, for example, to enforce presence of P- 212 Charge-Info header by the billing entity and reject the session if 213 there is none. This check may be performed only for certain sessions 214 based on origination and/or destination identity for the call. 216 7. Acknowledgements 218 8. Informative References 220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 221 Requirement Levels", BCP 14, RFC 2119, 222 DOI 10.17487/RFC2119, March 1997, 223 . 225 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 226 A., Peterson, J., Sparks, R., Handley, M., and E. 227 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 228 DOI 10.17487/RFC3261, June 2002, 229 . 231 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 232 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 233 . 235 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 236 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 237 . 239 Author's Address 241 Tolga Asveren 242 Ribbon Communications 243 Freehold, NJ 07728 244 USA 246 Email: tasveren@rbbn.com