idnits 2.17.00 (12 Aug 2021) /tmp/idnits39376/draft-fries-sipping-identity-enterprise-scenario-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 450. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 427. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 434. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 440. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 : ---------------------------------------------------------------------------- No issues found here. 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 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 19, 2006) is 5928 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: 'RFC3830' is defined on line 331, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-elwell-sip-connected-identity-00 -- Possible downref: Normative reference to a draft: ref. 'I-D.elwell-sip-connected-identity' == Outdated reference: draft-ietf-sip-identity has been published as RFC 4474 == Outdated reference: draft-ietf-mmusic-kmgmt-ext has been published as RFC 4567 == Outdated reference: draft-ietf-msec-mikey-rsa-r has been published as RFC 4738 == Outdated reference: A later version (-03) exists of draft-ietf-sipping-certs-02 == Outdated reference: A later version (-05) exists of draft-tschofenig-sip-saml-04 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING S. Fries 3 Internet-Draft H. Tschofenig 4 Expires: August 23, 2006 Siemens 5 February 19, 2006 7 SIP Identity Usage in Enterprise Scenarios 8 draft-fries-sipping-identity-enterprise-scenario-02.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 23, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document describes a use case for the SIP Identity document 42 involving certificate management with the focus on enterprise 43 environments. It provides a best current practice document for 44 binding an identity to a certificate for the duration of a session. 45 The certificate may then be used to bootstrap further security 46 parameters, e.g., for securing media data. A discussion of possible 47 enhancements is included in the appendix. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Existing Building Blocks . . . . . . . . . . . . . . . . . . . 4 54 4. Scenario and Profile . . . . . . . . . . . . . . . . . . . . . 5 55 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 58 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 59 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 61 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 62 Appendix A. Alternative Approaches . . . . . . . . . . . . . . . 8 63 A.1. Associating user identity and credentials upfront . . . . 8 64 A.2. Enhancements to SIP Identity using SIP SAML . . . . . . . 9 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 66 Intellectual Property and Copyright Statements . . . . . . . . . . 12 68 1. Introduction 70 In current enterprise environments certificates are used to provide 71 secure access to web servers, to protect server-to-server 72 communication, and for administrative purposes. In certain 73 scenarios, authentication of the access device as well as the user is 74 important. In order to support such scenarios, IP-based enterprise 75 systems may be equipped with device certificates. Several enterprise 76 networks already have a device authorization infrastructure. 78 This security often is restricted to the perimeter of the corporate 79 network, as peers outside the corporate network may not be able to 80 verify a certificate given by a corporate CA. 82 For user-to-user communication, the receiving side needs to be able 83 to validate a certificate as belonging to the sending side. A device 84 certificate is not ideally suited to this purpose since it contains a 85 device specific identifier. Although user certificates would seem to 86 be a better alternative, there are certain difficulties with this at 87 present. Users often use different devices at different times, and 88 to facilitate this (and also prevent unauthorised use of a 89 certificate in the absence of a user), private keys and certificates 90 may be provided on smart cards. However, this almost rules out the 91 simultaneous usage of this card in two devices (e.g., hard phone and 92 PC). As a complete role out of a PKI providing server and user 93 certificates that are globally usable is not likely in the near 94 future (at least for user certificates), intermediate steps need to 95 be taken. 97 This document discusses the usage of certificates with a limited 98 applicability, e.g., device certificates or self-signed certificates 99 in an enterprise environment in the context of SIP. In particular, 100 this document focuses on the session binding of these certificates to 101 user identities. 103 The scenario, which is the focus of this document, can be described 104 as follows. Note that the applicability of the approach is not 105 restricted to this example use case. 107 A user in a corporate environment has been assigned a hardware-based 108 phone. With this phone the user may initiate and receive calls 109 inside the corporate environment and also to/from the outside. Since 110 the corporate policy requires certain security services to be in 111 place, e.g., media encryption, for internal as well as external 112 calls, the phone needs to support security parameter negotiation 113 between the participants of a call. To achieve this negotiation 114 securely, the phone typically needs to be equipped with an 115 appropriate certificate. Note that since the phone may be shared by 116 several users, the phone may even be able to generate certificates 117 for the user currently associated with this phone. 119 Using the phone, i.e., the voice service, requires the user to 120 authenticate himself, often based on a username and a password. One 121 reason why it is assumed that the user does not authenticate using a 122 certificate and corresponding private key is the lack of an 123 appropriate interface in order to accomplish the necessary 124 certificate provision to the phone (e.g., using smart cards or secure 125 USB tokens). Even with such an interface, the enterprise may not be 126 able to issue globally resolvable certificates due to technical or 127 financial reasons. 129 A certificate based on the phone can be used to secure the exchange 130 of security parameters. The problem to be solved here is the binding 131 of available certificate material to a user identity for the duration 132 of the session concerned. 134 2. Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [RFC2119]. 140 3. Existing Building Blocks 142 RFC 3261 [RFC3261] already describes the transport of certificates 143 within the SDP body of a message using the S/MIME Key Exchange 144 approach described in Section 23.2 of [RFC3261]. Here, a user may 145 submit a self-signed certificate. It is even allowed that the 146 subjectname field be different from the AoR submitted in the From 147 header field. The drawback is that the receiver may not be able to 148 verify the validity of the embedded key and associate it with a 149 particular user identity. 151 [I-D.ietf-sip-identity] introduces a new entity, called the 152 authentication service, which provides assurance about the identity 153 in the From header field of a SIP request (such as an INVITE 154 request). The authentication service does this by adding an 155 assertion to the SIP header in a SIP request. This assertion 156 provides integrity protection for certain header fields and also for 157 the body of the SIP request. The assertion is added after 158 authenticating (and authorizing) the request initiator, e.g., by HTTP 159 digest authentication. 161 4. Scenario and Profile 163 Subsequently, a profile is described for a BCP providing an implicit 164 binding of a user identity to the available certificate for the 165 duration of a session. The profile ensures interoperability of 166 different vendor's products regarding the described scenario. The 167 profile does not define any new messages or parameters. It rather 168 takes existing options from RFC 3261 and appropriate SIP extensions 169 to achieve the binding. 171 Devices may already possess certificates or may generate self-signed 172 certificates on logon of a new user or on request. A UA may want to 173 bind these credentials to the identity of the registering user for 174 the duration of the registration or just for the duration of a 175 session. When the UA issues a SIP request, the outbound proxy / 176 registrar will authenticate the UA as having the credentials 177 associated with the user identified in the From header field. For 178 example, the UA may be challenged to provide HTTP digest 179 authentication. Alternatively, if the request is received over a TLS 180 connection on which the UA has been authenticated previously, then 181 further authentication may not be necessary. Having authenticated 182 the UA, any certificate conveyed in that request can be implicitly 183 associated with that UA and hence with the authenticated user, 184 provided the request has been integrity protected (e.g., through the 185 use of TLS). An authentication service, as defined in [I-D.ietf-sip- 186 identity], can then verify that the URI in the From header field 187 corresponds to an AoR that the authenticated user is allowed to use, 188 and on this basis can provide an assertion in the forwarded request 189 that the From header field URI does indeed identify the origin of the 190 request. This assertion is in the form of an inserted Identity 191 header field in the INVITE message. This provides a signature over 192 some of the header fields in the forwarded request and over the 193 entire body, using the domain's private key. Thus, if a certificate 194 is included in a body, it will be integrity protected and any 195 recipient of the request can be sure that the certificate originated 196 at a device having the credentials of the user identified in the From 197 header field, provided the signature can be verified and validated. 198 This can be facilitated if the authentication service uses a 199 certificate signed by a well know CA. 201 An extension, allowing the authentication service to add a 202 fingerprint of a certificate used during the user authentication is 203 described in Appendix A of this document. The signature of the 204 authentication service enables the receiving UAC to verify that the 205 body and thus the certificate has not been tampered with while in 206 transit from the authentication server to the recipient, and that it 207 was provided by a particular entity stated in the FROM field (as 208 indicated in the assertion). The message integrity together with the 209 assertion create a temporary binding (identity, certificate) at the 210 receiver side. 212 This is important, as the receiving client may not be able to verify 213 the certificate provided by the initiator of the communication (for 214 example, because it was created by an enterprise CA and the root 215 certificate of the issuing CA cannot be validated). In-band 216 certificate provision may be done as described in RFC 3261 [RFC3261] 217 for self-signed certificates or by using the recently proposed new 218 MIKEY option [I-D.ietf-msec-mikey-rsa-r] for key management, allowing 219 the certificate transport as part of a MIKEY message, which in turn 220 can be transmitted in SIP using the [I-D.ietf-mmusic-kmgmt-ext] 221 approach. 223 After verifying the signature, the receiving client can store the 224 certificate associated with the identity stated in the FROM header 225 field for the duration of the session. After the session ends the 226 receiving UA SHOULD delete the association. 228 In any case, using the approach described in [I-D.ietf-sip-identity], 229 the authentication service, through the signature over the body, 230 implicitly asserts that the identity in the FROM field is somehow 231 connected to a certificate in the body. 233 Note that the authentication service may not be held responsible for 234 attacks on the path between the UAC and the authentication server via 235 the SIP proxy. As this approach is provided in-band it only requires 236 an [I-D.ietf-sip-identity] compliant authentication service to be in 237 place as additional component. 239 5. Conclusion 241 In this document we propose to use the scenario and profile described 242 above to enable in-band certificate exchange and association with an 243 identity in the FROM header field as a best current practice use case 244 for [I-D.ietf-sip-identity]. It would require a UACs to store an 245 association of identity and certificate for the duration of a 246 session. This is done in order for the receiver to ensure that 247 during the entire session the same certificate/private key is used 248 for cryptographic purposes with the calling UA. This creates a 249 temporary binding (identity, certificate) at the receiver side. 250 Alternative approaches are described in Appendix A. These 251 alternatives, however, suffer from some limitations or require 252 protocol extensions. 254 6. Security Considerations 256 To avoid the use of a dedicated certificate and private key pair from 257 several users, the device needs to ensure that a fresh key pair is 258 generated upon user login. The lifetime of the certificate may be 259 rather short. A new certificate may be generated during the period 260 of registration if a certificate expires. 262 If a certificate is compromised, it needs to be revoked and a new 263 certificate has to be issued to the device. Following the approach 264 in [I-D.ietf-sipping-certs] a notification with an empty body is sent 265 to indicate that the certificate is no longer valid. 267 Response identity, e.g., for the mutual exchange of certificates, 268 cannot be achieved using the approach described in [I-D.ietf-sip- 269 identity]. Here, a the recently submitted ID handling connected SIP 270 identity [I-D.elwell-sip-connected-identity] may provide a solution. 271 This ID describes an approach for targeting the authenticated 272 connected identity provisioning using [I-D.ietf-sip-identity]. 274 7. IANA Considerations 276 This document does not require actions by IANA. 278 8. Acknowledgments 280 The authors would like to thank Jon Peterson and Cullen Jennings as 281 well as John Elwell and Francois Audet for the discussions in context 282 of SIP identity. Additionally, we would like to thank Andreas 283 Pashalidis for his comments. 285 9. References 287 9.1. Normative References 289 [I-D.elwell-sip-connected-identity] 290 Elwell, J., "Connected Identity in the Session Initiation 291 Protocol (SIP)", draft-elwell-sip-connected-identity-00 292 (work in progress), October 2005. 294 [I-D.ietf-sip-identity] 295 Peterson, J. and C. Jennings, "Enhancements for 296 Authenticated Identity Management in the Session 297 Initiation Protocol (SIP)", draft-ietf-sip-identity-06 298 (work in progress), October 2005. 300 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 301 Requirement Levels", BCP 14, RFC 2119, March 1997. 303 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 304 A., Peterson, J., Sparks, R., Handley, M., and E. 305 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 306 June 2002. 308 9.2. Informative References 310 [I-D.ietf-mmusic-kmgmt-ext] 311 Arkko, J., "Key Management Extensions for Session 312 Description Protocol (SDP) and Real Time Streaming 313 Protocol (RTSP)", draft-ietf-mmusic-kmgmt-ext-15 (work in 314 progress), June 2005. 316 [I-D.ietf-msec-mikey-rsa-r] 317 Ignjatic, D., "An additional mode of key distribution in 318 MIKEY: MIKEY-RSA-R", draft-ietf-msec-mikey-rsa-r-02 (work 319 in progress), February 2006. 321 [I-D.ietf-sipping-certs] 322 Jennings, C. and J. Peterson, "Certificate Management 323 Service for The Session Initiation Protocol (SIP)", 324 draft-ietf-sipping-certs-02 (work in progress), July 2005. 326 [I-D.tschofenig-sip-saml] 327 Tschofenig, H., "Using SAML for SIP", 328 draft-tschofenig-sip-saml-04 (work in progress), 329 July 2005. 331 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 332 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 333 August 2004. 335 Appendix A. Alternative Approaches 337 A.1. Associating user identity and credentials upfront 339 SIPPING-CERTS [I-D.ietf-sipping-certs] and SIP Identity [I-D.ietf- 340 sip-identity] are two promising approaches that help to deal with the 341 problem that deployment of end user certificates and a global PK 342 infrastructure is not available. 344 [I-D.ietf-sipping-certs] is suitable for an enterprise environment to 345 provide certificate information to the end hosts and end users via a 346 credential server. UAs can fetch certificates and use them as 347 necessary. UAs may also store their own credentials on the 348 credential server. This may be done also (only) for the duration of 349 a registration, which enables other UAs to fetch the certificate 350 upfront, before starting communication with the target UA. This 351 approach requires that both parties have sufficient access to a 352 credential server. Besides the credential server, also an 353 authentication server may be needed to support certain scenarios. 355 This approach works nicely in many environments but there may be 356 limitations is others 358 In order to use the credential server in a way in which certificates 359 are globally accessible it is necessary to put the credential server 360 on the public Internet. This is in order to enable persons from 361 outside to access the certificate information before making or 362 answering a call. This approach may not be feasible for all 363 enterprises, as there are certain company based regulations regarding 364 the safeguarding of employee information. A corporate directory for 365 instance is normally not accessible by people outside the enterprise. 367 The combination of both concepts, namely SIP Identity and SIPPING- 368 CERTS, provides the possibility to route a NOTIFY, which contains a 369 certificate from the credential server, via the authentication 370 service to the UA. As stated in [I-D.ietf-sipping-certs], if the 371 identity asserted by the authentication service matches the AOR that 372 the UA subscribed to, the certificate in the NOTIFY can be treated as 373 valid and may be used for the protection of subsequent communication. 374 A general precondition is that the UA and the authentication server 375 trust the same root CA. 377 This latter approach requires the certificate SubjectAltName to match 378 a given AoR, as described in Section 8.10 of [I-D.ietf-sipping- 379 certs], thus leaving certain device certificates or certain self- 380 signed certificates outside the possible solution. 382 A.2. Enhancements to SIP Identity using SIP SAML 384 As required by [I-D.ietf-sip-identity], the authentication server has 385 to authenticate the user whose identity appears in the FROM field of 386 the SIP request by some means, e.g., by challenging the user. 388 Additionally, an authentication server may also check and assert, 389 that a dedicated certificate was used during registration over a TLS 390 protected link for the authentication on the TLS level. This 391 approach is currently not be possible with [I-D.ietf-sip-identity] 392 and would require further specification. 394 A document supporting this approach is provided in SIP-SAML 395 [I-D.tschofenig-sip-saml], which enables SAML assertions and 396 artifacts to be carried in SIP. This document offers a mechanism to 397 deliver additional information about previously executed 398 authentication. 400 Authors' Addresses 402 Steffen Fries 403 Siemens 404 Otto-Hahn-Ring 6 405 Munich, Bavaria 81739 406 Germany 408 Email: steffen.fries@siemens.com 410 Hannes Tschofenig 411 Siemens 412 Otto-Hahn-Ring 6 413 Munich, Bavaria 81739 414 Germany 416 Email: Hannes.Tschofenig@siemens.com 418 Intellectual Property Statement 420 The IETF takes no position regarding the validity or scope of any 421 Intellectual Property Rights or other rights that might be claimed to 422 pertain to the implementation or use of the technology described in 423 this document or the extent to which any license under such rights 424 might or might not be available; nor does it represent that it has 425 made any independent effort to identify any such rights. Information 426 on the procedures with respect to rights in RFC documents can be 427 found in BCP 78 and BCP 79. 429 Copies of IPR disclosures made to the IETF Secretariat and any 430 assurances of licenses to be made available, or the result of an 431 attempt made to obtain a general license or permission for the use of 432 such proprietary rights by implementers or users of this 433 specification can be obtained from the IETF on-line IPR repository at 434 http://www.ietf.org/ipr. 436 The IETF invites any interested party to bring to its attention any 437 copyrights, patents or patent applications, or other proprietary 438 rights that may cover technology that may be required to implement 439 this standard. Please address the information to the IETF at 440 ietf-ipr@ietf.org. 442 Disclaimer of Validity 444 This document and the information contained herein are provided on an 445 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 446 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 447 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 448 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 449 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 450 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 452 Copyright Statement 454 Copyright (C) The Internet Society (2006). This document is subject 455 to the rights, licenses and restrictions contained in BCP 78, and 456 except as set forth therein, the authors retain all their rights. 458 Acknowledgment 460 Funding for the RFC Editor function is currently provided by the 461 Internet Society.