idnits 2.17.00 (12 Aug 2021) /tmp/idnits54609/draft-fries-sipping-identity-enterprise-scenario-00.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 372. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 362. ** 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 (July 11, 2005) is 6158 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: 'I-D.tschofenig-sip-saml' is defined on line 313, but no explicit reference was found in the text == Unused Reference: 'RFC3830' is defined on line 318, but no explicit reference was found in the text == 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: A later version (-03) exists of draft-ietf-sipping-certs-01 == Outdated reference: A later version (-05) exists of draft-tschofenig-sip-saml-03 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 7 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: January 12, 2006 Siemens 5 July 11, 2005 7 SIP Identity Usage in Enterprise Scenarios 8 draft-fries-sipping-identity-enterprise-scenario-00.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 January 12, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document describes a scenario for the SIP identity work 42 involving certificate management in enterprise environments. A 43 discussion of possible solutions is included. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Scenario Overview . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Problem Description . . . . . . . . . . . . . . . . . . . . . 3 50 4. Solution Approaches . . . . . . . . . . . . . . . . . . . . . 5 51 4.1 Associating user identity and device credentials 52 within the session . . . . . . . . . . . . . . . . . . . . 5 53 4.2 Associating user identity and device credentials 54 upfront . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 4.3 Potential enhancements to SIP Identity . . . . . . . . . . 6 56 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 59 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 60 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 9.1 Normative References . . . . . . . . . . . . . . . . . . . 7 62 9.2 Informative References . . . . . . . . . . . . . . . . . . 7 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 64 Intellectual Property and Copyright Statements . . . . . . . . 9 66 1. Introduction 68 In current enterprise environments certificates are used to provide 69 secure access to web servers, to protect server-to-server 70 communication, and for administrative purposes. In certain 71 scenarios, authentication of the access device as well as the user is 72 important. In order to support such scenarios, IP-based enterprise 73 systems may be equipped with device certificates. Several enterprise 74 networks already have a device authorization infrastructure. This 75 infrastructe is based on device and software properties and 76 characteristics. 78 This document discusses the usage of device certificates in an 79 enterprise environment in the context of SIP. In particular, this 80 document focuses on the binding of device certificates to user 81 identities. 83 2. Scenario Overview 85 The scenario, which is the focus of this discussion, can be described 86 as follows. 87 o A user is connected to the corporate LAN with his destop PC or 88 laptop and may possess a user certificate for certain 89 applications. 90 o Additionally, the user has been assigned a hardware-based phone. 91 The hardware-based phone is equipped with an appropriate device 92 certificate in order to enable secure communication and 93 maintainance. 94 o Using the phone requires the user to authenticate himself based on 95 a username and a password for VoIP service access, intead of a 96 user certificate. The reason why it is assumed that the user 97 cannot authenticate himself based on a certificate is the lack of 98 appropriate interfaces in order to accomplish the necessary 99 certificate provision to the phone (e.g. using smart cards or 100 secure USB tokens). Additionally, as the user might not have 101 complete control over the phone, and as the phone may be shared 102 among multiple user, it is not desireable to expose private keys 103 to the phone. 105 3. Problem Description 107 SIPPING-CERTS [I-D.ietf-sipping-certs] and SIP Identity [I-D.ietf- 108 sip-identity] are two promising approaches that help to deal with the 109 problem that deployment of end user certificates and a world wide PK 110 infrastructure is not available. 112 [I-D.ietf-sipping-certs] is suitable for an enterprise environment to 113 provide certificate information to the end hosts and end users via a 114 credential server. UAs can fetch certificates and use them as 115 necessary. UAs may also store their own credentials on the 116 credential server. 118 This approach works nicely in many environments but suffers from the 119 following limitations. 120 o Users may not want to download their credentials to end hosts over 121 which they do not have administrative control. This restricts the 122 applicability of the approach of storing credentials in an 123 enterprise environment where IP-based phones might not be 124 associated with a single person. 125 o In order to use the credential server in a way in which 126 certificates are globally accessible it is necessary to put the 127 credential server on the public Internet. This is in order to 128 enable persons from outside to access the certificate information 129 before making or answering a call. This apporach may not be 130 feasible for all enterprises, as there are certain regulations 131 regarding the safeguarding of employee information. Usually the 132 corporate directory is not accessible by people outside the 133 enterprise. 135 [I-D.ietf-sip-identity] introduces an entity, called the 136 authentication server, which provides assurance about the identity in 137 the FROM field of a SIP request (such as an INVITE). The 138 authentication service adds an assertion to the SIP header field in a 139 SIP request. This assertion also provides integrity protection for 140 certain header fields and the body of the SIP request. This 141 assertion is added after authenticatiing and authorizing the 142 signaling session initiator. 144 The combination of both concepts, namely SIP Identity and SIPPING- 145 CERTS, provides the possiblity to route a NOTIFY, which contains a 146 certificate from the credential server, via the authentication 147 service to the UA. As stated in [I-D.ietf-sipping-certs], if the 148 identity asserted by the authentication service matches the AOR that 149 the UA subscribed to, the certificate in the NOTIFY can be treated as 150 valid and may be used for the protection of subsequent communication. 151 A precondition is that the UA and the authentication server trust the 152 same root CA. 154 This latter approach would not work when a UA uses device 155 certificates, as the receiving UA would not be able to match the AOR 156 value, which must be checked according to Section 10.6 of [I-D.ietf- 157 sipping-certs]. The approach of using device certificates could 158 serve as an option to provide security services during the session. 159 Devices certificates may not be used for user authentication. 161 Users might not want to provide certicates to a hardware based phone 162 using SIPPING-CERT [I-D.ietf-sipping-certs]. Even if the credentials 163 are ephemeral it may not be desirable to store them at a device that 164 is not under the control of the user. Severely limiting the lifetime 165 of the credentials is often not an option since the user may not know 166 in advance how long the credentials are needed. 168 4. Solution Approaches 170 4.1 Associating user identity and device credentials within the session 172 As devices may already possess device certificates, a UA may want to 173 bind these credentials to the identity of the registering user for 174 the duration of the registration. During the registration, the 175 registrar may authenticate the device in addition to the user. The 176 registrar is therefore able to associate the user authentication 177 (e.g. using SIP digest authentication) with the certificate-based 178 device authentication which has beed performed as part of the TLS 179 handshake. If the authentication server and the registrar are co- 180 located then the authentication server has access to the credentials 181 that were used during authentication. The authentication server may 182 then be in a position to assert the identity used in the FROM header. 183 SIP Identity [I-D.ietf-sip-identity] can fulfill this task. 185 Furthermore, if certificates are carried inside the SIP/SDP payload 186 (as part of the end-to-end communication) then the assertion added by 187 the authentication service can also cover it. The signature of the 188 authentication service would enable the receiving UAC to verify that 189 the body and thus the certificate has not been tampered with while in 190 transit, and that it was provided by a particular entity (as 191 indicated in the assertion). 193 This is important, as the receiving client may not be able to verify 194 the certificate provided by the initiator of the communication (for 195 example, because it was created by an enterprise CA and the root 196 certificate of the issuing CA cannot be validated). In-band 197 certificate provision may be done as described in RFC 3261 for self- 198 signed certificates or by using the recently proposed new MIKEY 199 option [I-D.ignjatic-msec-mikey-rsa-r] for key management, allowing 200 the certificate transport as part of a MIKEY message, which in turn 201 can be transmitted in SIP using the [I-D.ietf-mmusic-kmgmt-ext] 202 approach. 204 In any case, using the approach decribed in [I-D.ietf-sip-identity], 205 the authentication service, through the signature over the body, 206 implicitly asserts that the identity in the FROM field is somehow 207 connected to a certificate in the body. According to [I-D.ietf-sip- 208 identity] the authentication service is responsible to make sure that 209 the user is allowed to use the stated identity in the FROM field 210 within the domain of the server's authority. 212 4.2 Associating user identity and device credentials upfront 214 Another approach would be that the UA uploads the credentials to the 215 credential server also for the duration of the registration, which 216 enables other UAs to fetch the certificate upfront, before starting 217 communication with the target UA. This approach is supported by the 218 usage of [I-D.ietf-sipping-certs]. A limitation, which has been 219 stated in the Overview section above is that it might not be suitable 220 for external parties as they may not be allowed to obtain the 221 appropriate certificates from a corporate server. 223 4.3 Potential enhancements to SIP Identity 225 As required by [I-D.ietf-sip-identity], the authentication server has 226 to authenticate the user whose identity appears in the FROM field of 227 the SIP request by some means, e.g. by challenging the user. 229 Additionally, the authentication server may also check and assert, 230 that a dedicated certificate was used during registration over a TLS 231 protected link for the authentication on the TLS level. This would 232 not be possible with the current [I-D.ietf-sip-identity] draft and 233 would require further specification. SIP-SAML [I-D.tschofenig-sip- 234 saml] enables SAML assertions and artifacts to be carried in SIP. 235 This draft offers a mechanism to deliver additional information about 236 previously executed authentication. 238 5. Conclusion 240 In this draft we propose to use the scenario described in section 4.1 241 above, and thereby enables in-band certificate exchange, as a best 242 current practice use case for [I-D.ietf-sip-identity] in enterprise 243 environments. It would require a UACs to store an association of 244 FROM field and certificate for the duration of a session. This is 245 done in order for the receiver to ensure that during the entire 246 session the same certificate/private key is used for cryptographic 247 purposes. This creates a binding (identity, device-based 248 certificate) at the receiver side. The approach of Section 4.3 may 249 enhance this solution but requires further specification. 251 6. Security Considerations 253 Storing device certificates on a credential server may lead to 254 additional effort for certificate revocation, as the device 255 certificate may be compromised during a session with user A and 256 should therefore not be used in a later communication session with 257 user B. Usually, the binding of a device certificate to an identity 258 would be valid only for the duration of the registration, i.e. a UAC 259 would provide the certificate related to the user's AoR to the 260 certificate server upon registration with the SIP registrar. In 261 order to prevent impersonation attacks, after de-registration the 262 certificate should be withdrawn from the certificate server. 264 If a device certificate is compromised, systems management is 265 responsible to revoke it and issue a new certificate to that device. 266 Following the approach of [I-D.ietf-sipping-certs] the notifier sends 267 a notification with an empty body to indicate that the device 268 certificate is no longer valid. 270 Response identity e.g. for the mutual exchange of certificates, 271 cannot be achieved using the approach described in [I-D.ietf-sip- 272 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 for 281 the discussions in context of SIP identity. Additionally, we would 282 like to thank Andreas Pashalidis for his comments. 284 9. References 286 9.1 Normative References 288 [I-D.ietf-sip-identity] 289 Peterson, J. and C. Jennings, "Enhancements for 290 Authenticated Identity Management in the Session 291 Initiation Protocol (SIP)", draft-ietf-sip-identity-05 292 (work in progress), May 2005. 294 9.2 Informative References 296 [I-D.ietf-mmusic-kmgmt-ext] 297 Arkko, J., "Key Management Extensions for Session 298 Description Protocol (SDP) and Real Time Streaming 299 Protocol (RTSP)", draft-ietf-mmusic-kmgmt-ext-15 (work in 300 progress), June 2005. 302 [I-D.ietf-sipping-certs] 303 Jennings, C. and J. Peterson, "Certificate Management 304 Service for The Session Initiation Protocol (SIP)", 305 draft-ietf-sipping-certs-01 (work in progress), 306 February 2005. 308 [I-D.ignjatic-msec-mikey-rsa-r] 309 Ignjatic, D. and L. Dondeti, "An additional mode of key 310 distribution in MIKEY", draft-ignjatic-msec-mikey-rsa-r-00 311 (work in progress), January 2005. 313 [I-D.tschofenig-sip-saml] 314 Tschofenig, H., "Using SAML for SIP", 315 draft-tschofenig-sip-saml-03 (work in progress), 316 July 2005. 318 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 319 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 320 August 2004. 322 Authors' Addresses 324 Steffen Fries 325 Siemens 326 Otto-Hahn-Ring 6 327 Munich, Bavaria 81739 328 Germany 330 Email: steffen.fries@siemens.com 332 Hannes Tschofenig 333 Siemens 334 Otto-Hahn-Ring 6 335 Munich, Bavaria 81739 336 Germany 338 Email: Hannes.Tschofenig@siemens.com 340 Intellectual Property Statement 342 The IETF takes no position regarding the validity or scope of any 343 Intellectual Property Rights or other rights that might be claimed to 344 pertain to the implementation or use of the technology described in 345 this document or the extent to which any license under such rights 346 might or might not be available; nor does it represent that it has 347 made any independent effort to identify any such rights. Information 348 on the procedures with respect to rights in RFC documents can be 349 found in BCP 78 and BCP 79. 351 Copies of IPR disclosures made to the IETF Secretariat and any 352 assurances of licenses to be made available, or the result of an 353 attempt made to obtain a general license or permission for the use of 354 such proprietary rights by implementers or users of this 355 specification can be obtained from the IETF on-line IPR repository at 356 http://www.ietf.org/ipr. 358 The IETF invites any interested party to bring to its attention any 359 copyrights, patents or patent applications, or other proprietary 360 rights that may cover technology that may be required to implement 361 this standard. Please address the information to the IETF at 362 ietf-ipr@ietf.org. 364 Disclaimer of Validity 366 This document and the information contained herein are provided on an 367 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 368 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 369 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 370 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 371 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 372 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 374 Copyright Statement 376 Copyright (C) The Internet Society (2005). This document is subject 377 to the rights, licenses and restrictions contained in BCP 78, and 378 except as set forth therein, the authors retain all their rights. 380 Acknowledgment 382 Funding for the RFC Editor function is currently provided by the 383 Internet Society.