idnits 2.17.1 draft-ietf-sip-authid-body-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2003) is 7742 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) == Unused Reference: '2' is defined on line 394, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-sipping-3pcc-02 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP WG J. Peterson 3 Internet-Draft NeuStar 4 Expires: August 2, 2003 February 2003 6 SIP Authenticated Identity Body (AIB) Format 7 draft-ietf-sip-authid-body-01 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 2, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 RFC3261 introduces the concept of adding an S/MIME body to a SIP 39 request or response in order to provide reference integrity over its 40 headers. This document provides a more specific mechanism to derive 41 integrity and authentication properties from an 'authenticated 42 identity body', a digitally-signed SIP message or message fragment. 43 A standard format for such bodies (known as Authenticated Identity 44 Bodies, or AIBs) is given in this document. Some considerations for 45 the processing of AIBs by recipients of SIP messages with such bodies 46 are also given. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. AIB Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Example of a Request with AIB . . . . . . . . . . . . . . . . 5 53 4. Special Cases of INVITE Requests . . . . . . . . . . . . . . . 6 54 5. Identity in non-INVITE Requests . . . . . . . . . . . . . . . 6 55 6. Identity in Responses . . . . . . . . . . . . . . . . . . . . 7 56 7. Receiving an AIB . . . . . . . . . . . . . . . . . . . . . . . 7 57 8. Encryption of Identity . . . . . . . . . . . . . . . . . . . . 8 58 9. Example of Encryption . . . . . . . . . . . . . . . . . . . . 8 59 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 60 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 61 Normative References . . . . . . . . . . . . . . . . . . . . . 10 62 Informative References . . . . . . . . . . . . . . . . . . . . 10 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 64 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11 66 1. Introduction 68 Section 23.4 of RFC3261 [1] describes an integrity mechanism that 69 relies on signing tunneled 'message/sip' MIME bodies within SIP 70 requests. The purpose of this mechanism is to replicate the headers 71 of a SIP request within a body carried in that request in order to 72 provide a digital signature over these headers. The signature on 73 this body also provides authentication. 75 The core requirement that motivates this mechanism is the problem of 76 providing a cryptographically verifiable identity within a SIP 77 request. The baseline SIP protocol allows a user agent to express 78 the identity of its user in any of a number of headers. The primary 79 place for identity information asserted by the sender of a request is 80 the From header. The From header field contains a URI (like 81 'sip:alice@atlanta.com') and an optional display-name (like "Alice") 82 that identifies the originator of the request. A user may have many 83 identities that are used in different contexts. 85 Typically, this URI is an address-of-record that can be dereferenced 86 in order to contact the originator of the request; specifically, it 87 is usually the same address-of-record under which a user registers 88 their devices in order to receive incoming requests. This address- 89 of-record is assigned and maintained by the administrator of the SIP 90 service in the domain identified by the host portion of the address- 91 of-record. However, the From field of a request can usually be set 92 arbitrarily by the user of a SIP user agent; the From header of a 93 message provides no internal assurance that the originating user can 94 legitimately claim the given identity. Nevertheless, many SIP user 95 agents will obligingly display the contents of the From field as the 96 identity of the originator of a received request (as a sort of 97 'Caller-ID' function), much as email implementations display the From 98 field as the sender's identity 100 In order to provide the recipient of a SIP message with greater 101 assurance of the identity of the sender, a cryptographic signature 102 can be provided over the headers of the SIP request, which allows the 103 signer to assert a verifiable identity. Unfortunately, a signature 104 over the From header alone is insufficient because it could be cut- 105 and-pasted into a replay or forwarding attack, and more headers are 106 therefore needed to correlated a signature with a request. RFC3261 107 therefore recommends copying all of the headers from the request into 108 a signed MIME body; however, SIP messages can also be large, and many 109 of the headers in a SIP message would not be relevant to determining 110 the identity of the sender or assuring reference integrity with the 111 request, and moreover some headers may change in transit. It is 112 therefore desirable to find a happy medium - to provide a way of 113 signing just enough headers that the identity of the sender can be 114 ascertained and correlated with the request. 'message/sipfrag' [3] 115 provides a way for a subset of SIP headers to be included in a MIME 116 body; the AIB format described in Section 2 is based on 'message/ 117 sipfrag'. 119 For reasons of end-to-end privacy, it may also be desirable to 120 encrypt AIBs; procedures for this encryption are given in Section 8. 122 2. AIB Format 124 As a way of sharing authenticated identity among parties in the 125 network, a special type of MIME body format, the Authenticated 126 Identity Body (AIB) format, is defined in this section. AIBs allow a 127 party in a SIP transaction to cryptographically sign the headers that 128 assert the identity of the originator of a message, and provide some 129 other headers necessary for reference integrity. 131 An AIB is a MIME body of type 'message/sip' or 'message/sipfrag' (see 132 [3]). This body MUST have a Content-Disposition disposition-type of 133 'aib', a new value defined in this document specifically for 134 authenticated identity bodies. The Content-Disposition header SHOULD 135 also contain a 'handling' parameter indicating that this MIME body is 136 optional (i.e. if this mechanism is not supported by the user agent 137 server, it can still attempt to process the request). 139 AIBs using the 'message/sipfrag' MIME type MUST contain the following 140 headers when providing identity for an INVITE request: From, Date and 141 Call-ID; they SHOULD also contain the To, Contact and CSeq header. 142 AIBs MAY contain any other headers that help to uniquely identify the 143 transaction or provide related reference integrity. An example of 144 the AIB format for an INVITE is: 146 Content-Type: message/sipfrag 147 Content-Disposition: aib; handling=optional 149 From: Alice 150 To: Bob 151 Contact: 152 Date: Thu, 21 Feb 2002 13:02:03 GMT 153 Call-ID: a84b4c76e66710 154 CSeq: 314159 INVITE 156 Unsigned AIBs MUST NOT be honored by any recipients. After the AIB 157 has been signed, it SHOULD be added it to any existing MIME bodies in 158 the request (such as SDP), if necessary by transitioning the 159 outermost MIME body to a 'multipart/mixed' format. 161 3. Example of a Request with AIB 163 The following shows a full SIP INVITE request with an AIB: 165 INVITE sip:bob@biloxi.com SIP/2.0 166 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 167 To: Bob 168 From: Alice ;tag=1928301774 169 Call-ID: a84b4c76e66710 170 CSeq: 314159 INVITE 171 Max-Forwards: 70 172 Date: Thu, 21 Feb 2002 13:02:03 GMT 173 Contact: 174 Content-Type: multipart/mixed; boundary=unique-boundary-1 176 --unique-boundary-1 178 Content-Type: application/sdp 179 Content-Length: 147 181 v=0 182 o=UserA 2890844526 2890844526 IN IP4 here.com 183 s=Session SDP 184 c=IN IP4 pc33.atlanta.com 185 t=0 0 186 m=audio 49172 RTP/AVP 0 187 a=rtpmap:0 PCMU/8000 189 --unique-boundary-1 190 Content-Type: multipart/signed; 191 protocol="application/pkcs7-signature"; 192 micalg=sha1; boundary=boundary42 193 Content-Length: 608 195 --boundary42 196 Content-Type: message/sipfrag 197 Content-Disposition: aib; handling=optional 199 From: Alice 200 To: Bob 201 Contact: 202 Date: Thu, 21 Feb 2002 13:02:03 GMT 203 Call-ID: a84b4c76e66710 204 CSeq: 314159 INVITE 206 --boundary42 207 Content-Type: application/pkcs7-signature; name=smime.p7s 208 Content-Transfer-Encoding: base64 209 Content-Disposition: attachment; filename=smime.p7s; 210 handling=required 212 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 213 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 214 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 215 7GhIGfHfYT64VQbnj756 217 --boundary42-- 219 --unique-boundary-1-- 221 4. Special Cases of INVITE Requests 223 There are special-case uses of the INVITE method in which some SIP 224 messages are exchanged before an INVITE is sent, and the identity of 225 a party from the prior exchange needs to be carried in the subsequent 226 INVITE. 228 The use of the REFER [4] method, for example, has a requirement for 229 the recipient of an INVITE to ascertain the identity of the referrer 230 who caused the INVITE to be sent. In this instance, the From header 231 of the INVITE would indicate the referee, and whereas separate header 232 would indicated the referrer. 234 Third-party call control (3PCC [5]) has an even more complicated 235 identity problem. A central controller INVITEs one party, gathers 236 identity information (and session context) from that party, and then 237 uses this information to INVITE another party. Ideally, the 238 controller would also have a way to share a cryptographic identity 239 signature given by the first party INVITEd by the controller to the 240 second party invited by the controller. 242 In both of these cases, the Call-ID and CSeq of the original request 243 (3PCC INVITE or REFER) will not correpond with that of the request in 244 by the subsequent INVITE, nor would the To and From. In both the 245 REFER case and the 3PCC case, the Call-ID and CSeq cannot be used to 246 determine reference integrity, and it is therefore much harder to 247 correlated an AIB to a subsequent INVITE request. Some other special 248 headers MAY be used to provide reference integrity between the 249 headers in an AIB with the headers of a 3PCC or REFER-generated 250 INVITE, but this usage is outside of the scope of this document. 252 5. Identity in non-INVITE Requests 254 The requirements for populating an AIB in requests within a dialog 255 generally parallel those of the INVITE: From, Call-ID and Date are 256 REQUIRED. 258 Some non-INVITE requests, however, may have different identity 259 requirements. New methods should identify any special identity 260 requirements in the Security Considerations of their specification. 262 6. Identity in Responses 264 Many of the practices described in the preceding sections can be 265 applied to responses as well as requests. Note that a new set of 266 headers must be generated to populate the AIB in a response. The 267 From header field of the AIB in the response to an INVITE SHOULD 268 correspond to the address-of-record of the responder, NOT to the From 269 header field received in the request. The To header field of the 270 request MUST NOT be included. A new Date header field and Contact 271 header field should be generated for the AIB in a response. The 272 Call-ID and CSeq should, however, be copied from the request. 274 Generally, the To header field of the request will correspond to the 275 address-of-record of the responder. In some architectures where 276 redirection is used, however, this need not be the case. Some 277 recipients of response AIBs may consider it a cause for security 278 concern if the To header field of the request is not the same as the 279 address-of-record in the From header field of the AIB in a response. 281 7. Receiving an AIB 283 When a user agent receives a request containing an AIB, it should 284 verify the signature, including validating the certificate of the 285 signer, and compare the identity of the signer (the subjectAltName) 286 with, in the INVITE case, the From header field of the request (for 287 non-INVITE requests, other headers may be used). The two should 288 correspond exactly; if they do not, the user agent should report this 289 condition to its user before proceeding. User agents may distinguish 290 between plausibly minor variations (the difference between 291 'atlanta.com' and 'sip.atlanta.com') and major variations 292 ('atlanta.com' vs. 'evil.tv') when reporting these discrepancies in 293 order to give the user some idea of how to handle this situation. 294 Similar comparison of the Call-ID header is necessary for INVITE 295 requests. The freshness of the Date header should also be evaluated, 296 following the guidance in RFC3261. 298 When the originating user agent of a request receives a response 299 containing an AIB, it SHOULD compare the identity in the To header 300 field of the AIB of the response with the original value of the To 301 header field in the request. If these represent different 302 identities, the user agent SHOULD render the identity in the AIB of 303 the response to its user. Note that a discrepancy in these identity 304 fields is not necessary an indication of a security breach; normal 305 retargeting may simply have directed the request to a different final 306 destination. 308 8. Encryption of Identity 310 Many SIP entities that support the use of S/MIME for signatures also 311 support S/MIME encryption, as described in RFC3261 Section 23.4.3. 313 While encryption of AIBs entails that only the holder of a specific 314 key can decrypt the body, that single key could be distributed 315 throughout a network of hosts that exist under common policies. The 316 security of the AIB is therefore predicated on the secure 317 distribution of the key. However, for some networks (in which there 318 are federations of trusted hosts under a common policy), the 319 widespread distribution of a decryption key could be appropriate. 320 Some telephone networks, for example, might require this model. 322 When an AIB is encrypted, the AIB SHOULD always be encrypted before 323 it is signed. Note that this means that the recipients of the 324 request, even if they are unable to inspect the AIBF, will still be 325 able to see who signed that body (although it will not necessarily be 326 obvious that the body contains an AIB). 328 9. Example of Encryption 330 The following is an example of an encrypted and signed AIB (without 331 any of the preceding SIP headers). In a rendition of this body sent 332 over the wire, the text wrapped in asterisks would be in ciphertext. 334 Content-Type: multipart/signed; 335 protocol="application/pkcs7-signature"; 336 micalg=sha1; boundary=boundary42 337 Content-Length: 568 339 --boundary42 341 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; 342 name=smime.p7m 343 Content-Transfer-Encoding: base64 344 Content-Disposition: attachment; filename=smime.p7m 345 handling=required 346 Content-Length: 231 348 *********************************************************** 349 * Content-Type: message/sipfrag * 350 * Content-Disposition: aib; handling=optional * 351 * * 352 * From: sip:alice@atlanta.com * 353 * Call-ID: a84b4c76e66710 * 354 * Date: Thu, 21 Feb 2002 13:02:03 GMT * 355 *********************************************************** 357 --boundary42 359 Content-Type: application/pkcs7-signature; name=smime.p7s 360 Content-Transfer-Encoding: base64 361 Content-Disposition: attachment; filename=smime.p7s; 362 handling=required 364 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 365 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 366 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 367 7GhIGfHfYT64VQbnj756 369 --boundary42-- 371 10. Security Considerations 373 This document recommends the inclusion of the Contact, CSeq and To 374 headers in AIBs when 'message/sipfrag' is used. If these headers are 375 omitted, some important security properties of AIB are lost. For 376 example, the Contact header determines how new requests in a dialog 377 are routed. If an attacker were to modify the Contact header of a 378 SIP request in transit, and that header were not protected by the 379 AIBF, then new requests might not return to the originator of the 380 request. 382 11. IANA Considerations 384 This document defines a new MIME Content-Disposition disposition-type 385 value of 'aib'. This value is reserved for MIME bodies that contain 386 an authenticated identity, as described in section Section 2. 388 Normative References 390 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 391 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 392 Session Initiation Protocol", RFC 3261, May 2002. 394 [2] Bradner, S., "Key words for use in RFCs to indicate requirement 395 levels", RFC 2119, March 1997. 397 [3] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, 398 September 2002. 400 Informative References 402 [4] Sparks, R., "The SIP Refer Method", draft-ietf-sip-refer-07 403 (work in progress), November 2002. 405 [5] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo, 406 "Best Current Practices for Third-Party Call Control in the 407 Session Initiation Protocol", draft-ietf-sipping-3pcc-02 (work 408 in progress), June 2002. 410 Author's Address 412 Jon Peterson 413 NeuStar, Inc. 414 1800 Sutter St 415 Suite 570 416 Concord, CA 94520 417 US 419 Phone: +1 925/363-8720 420 EMail: jon.peterson@neustar.biz 421 URI: http://www.neustar.biz/ 423 Full Copyright Statement 425 Copyright (C) The Internet Society (2003). All Rights Reserved. 427 This document and translations of it may be copied and furnished to 428 others, and derivative works that comment on or otherwise explain it 429 or assist in its implementation may be prepared, copied, published 430 and distributed, in whole or in part, without restriction of any 431 kind, provided that the above copyright notice and this paragraph are 432 included on all such copies and derivative works. However, this 433 document itself may not be modified in any way, such as by removing 434 the copyright notice or references to the Internet Society or other 435 Internet organizations, except as needed for the purpose of 436 developing Internet standards in which case the procedures for 437 copyrights defined in the Internet Standards process must be 438 followed, or as required to translate it into languages other than 439 English. 441 The limited permissions granted above are perpetual and will not be 442 revoked by the Internet Society or its successors or assigns. 444 This document and the information contained herein is provided on an 445 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 446 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 447 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 448 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 449 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 451 Acknowledgement 453 Funding for the RFC Editor function is currently provided by the 454 Internet Society.