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