< draft-fries-sipping-identity-enterprise-scenario-00.txt   draft-fries-sipping-identity-enterprise-scenario-01.txt >
SIPPING S. Fries SIPPING S. Fries
Internet-Draft H. Tschofenig Internet-Draft H. Tschofenig
Expires: January 12, 2006 Siemens Expires: April 16, 2006 Siemens
July 11, 2005 October 13, 2005
SIP Identity Usage in Enterprise Scenarios SIP Identity Usage in Enterprise Scenarios
draft-fries-sipping-identity-enterprise-scenario-00.txt draft-fries-sipping-identity-enterprise-scenario-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 12, 2006. This Internet-Draft will expire on April 16, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes a scenario for the SIP identity work This document describes a scenario for the SIP identity work
involving certificate management in enterprise environments. A involving certificate management in enterprise environments. A
discussion of possible solutions is included. discussion of possible solutions is included.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scenario Overview . . . . . . . . . . . . . . . . . . . . . . 3 2. Scenario Overview . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Description . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Description . . . . . . . . . . . . . . . . . . . . . 3
4. Solution Approaches . . . . . . . . . . . . . . . . . . . . . 5 4. Solution Approaches . . . . . . . . . . . . . . . . . . . . . 5
4.1 Associating user identity and device credentials 4.1. Associating user identity and device credentials for
within the session . . . . . . . . . . . . . . . . . . . . 5 session duration . . . . . . . . . . . . . . . . . . . . . 5
4.2 Associating user identity and device credentials 4.2. Associating user identity and device credentials
upfront . . . . . . . . . . . . . . . . . . . . . . . . . 6 upfront . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3 Potential enhancements to SIP Identity . . . . . . . . . . 6 4.3. Potential enhancements to SIP Identity . . . . . . . . . . 6
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1 Normative References . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2 Informative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10
1. Introduction 1. Introduction
In current enterprise environments certificates are used to provide In current enterprise environments certificates are used to provide
secure access to web servers, to protect server-to-server secure access to web servers, to protect server-to-server
communication, and for administrative purposes. In certain communication, and for administrative purposes. In certain
scenarios, authentication of the access device as well as the user is scenarios, authentication of the access device as well as the user is
important. In order to support such scenarios, IP-based enterprise important. In order to support such scenarios, IP-based enterprise
systems may be equipped with device certificates. Several enterprise systems may be equipped with device certificates. Several enterprise
networks already have a device authorization infrastructure. This networks already have a device authorization infrastructure. This
infrastructe is based on device and software properties and infrastructure is based on device and software properties and
characteristics. characteristics.
This document discusses the usage of device certificates in an This document discusses the usage of certificates with a limited
enterprise environment in the context of SIP. In particular, this applicability, e.g., device certificates or self-signed certificates
document focuses on the binding of device certificates to user in an enterprise environment in the context of SIP. In particular,
identities. this document focuses on the session binding of these certificates to
user identities.
2. Scenario Overview 2. Scenario Overview
The scenario, which is the focus of this discussion, can be described The scenario, which is the focus of this discussion, can be described
as follows. as follows.
o A user is connected to the corporate LAN with his destop PC or o A user is connected to the corporate LAN with his destop PC or
laptop and may possess a user certificate for certain laptop and may possess a user certificate for certain
applications. applications.
o Additionally, the user has been assigned a hardware-based phone. o Additionally, the user has been assigned a hardware-based phone.
The hardware-based phone is equipped with an appropriate device The hardware-based phone is equipped with an appropriate device
certificate in order to enable secure communication and certificate in order to enable secure communication and
maintainance. maintainance.
o Using the phone requires the user to authenticate himself based on o Using the phone requires the user to authenticate himself based on
a username and a password for VoIP service access, intead of a a username and a password for VoIP service access, instead of a
user certificate. The reason why it is assumed that the user user certificate. The reason why it is assumed that the user
cannot authenticate himself based on a certificate is the lack of cannot authenticate himself based on a certificate is the lack of
appropriate interfaces in order to accomplish the necessary appropriate interfaces in order to accomplish the necessary
certificate provision to the phone (e.g. using smart cards or certificate provision to the phone (e.g. using smart cards or
secure USB tokens). Additionally, as the user might not have secure USB tokens). Additionally, as the user might not have
complete control over the phone, and as the phone may be shared complete control over the phone, and as the phone may be shared
among multiple user, it is not desireable to expose private keys among multiple user, it is not desireable to expose private keys
to the phone. to the phone.
3. Problem Description 3. Problem Description
SIPPING-CERTS [I-D.ietf-sipping-certs] and SIP Identity [I-D.ietf- SIPPING-CERTS [I-D.ietf-sipping-certs] and SIP Identity [I-D.ietf-
sip-identity] are two promising approaches that help to deal with the sip-identity] are two promising approaches that help to deal with the
problem that deployment of end user certificates and a world wide PK problem that deployment of end user certificates and a global PK
infrastructure is not available. infrastructure is not available.
[I-D.ietf-sipping-certs] is suitable for an enterprise environment to [I-D.ietf-sipping-certs] is suitable for an enterprise environment to
provide certificate information to the end hosts and end users via a provide certificate information to the end hosts and end users via a
credential server. UAs can fetch certificates and use them as credential server. UAs can fetch certificates and use them as
necessary. UAs may also store their own credentials on the necessary. UAs may also store their own credentials on the
credential server. credential server.
This approach works nicely in many environments but suffers from the This approach works nicely in many environments but suffers from the
following limitations. following limitations.
skipping to change at page 4, line 25 skipping to change at page 4, line 28
o In order to use the credential server in a way in which o In order to use the credential server in a way in which
certificates are globally accessible it is necessary to put the certificates are globally accessible it is necessary to put the
credential server on the public Internet. This is in order to credential server on the public Internet. This is in order to
enable persons from outside to access the certificate information enable persons from outside to access the certificate information
before making or answering a call. This apporach may not be before making or answering a call. This apporach may not be
feasible for all enterprises, as there are certain regulations feasible for all enterprises, as there are certain regulations
regarding the safeguarding of employee information. Usually the regarding the safeguarding of employee information. Usually the
corporate directory is not accessible by people outside the corporate directory is not accessible by people outside the
enterprise. enterprise.
[I-D.ietf-sip-identity] introduces an entity, called the [I-D.ietf-sip-identity] introduces a new entity, called the
authentication server, which provides assurance about the identity in authentication server, which provides assurance about the identity in
the FROM field of a SIP request (such as an INVITE). The the FROM field of a SIP request (such as an INVITE). The
authentication service adds an assertion to the SIP header field in a authentication service adds an assertion to the SIP header field in a
SIP request. This assertion also provides integrity protection for SIP request. This assertion also provides integrity protection for
certain header fields and the body of the SIP request. This certain header fields and the body of the SIP request. This
assertion is added after authenticatiing and authorizing the assertion is added after authenticatiing and authorizing the
signaling session initiator. signaling session initiator.
The combination of both concepts, namely SIP Identity and SIPPING- The combination of both concepts, namely SIP Identity and SIPPING-
CERTS, provides the possiblity to route a NOTIFY, which contains a CERTS, provides the possiblity to route a NOTIFY, which contains a
skipping to change at page 4, line 51 skipping to change at page 5, line 5
A precondition is that the UA and the authentication server trust the A precondition is that the UA and the authentication server trust the
same root CA. same root CA.
This latter approach would not work when a UA uses device This latter approach would not work when a UA uses device
certificates, as the receiving UA would not be able to match the AOR certificates, as the receiving UA would not be able to match the AOR
value, which must be checked according to Section 10.6 of [I-D.ietf- value, which must be checked according to Section 10.6 of [I-D.ietf-
sipping-certs]. The approach of using device certificates could sipping-certs]. The approach of using device certificates could
serve as an option to provide security services during the session. serve as an option to provide security services during the session.
Devices certificates may not be used for user authentication. Devices certificates may not be used for user authentication.
Users might not want to provide certicates to a hardware based phone Users might not want to provide certicates and corresponding private
using SIPPING-CERT [I-D.ietf-sipping-certs]. Even if the credentials keys to a hardware based phone using SIPPING-CERT [I-D.ietf-sipping-
are ephemeral it may not be desirable to store them at a device that certs]. Even if the credentials are ephemeral it may not be
is not under the control of the user. Severely limiting the lifetime desirable to store them at a device that is not under the control of
of the credentials is often not an option since the user may not know the user. Severely limiting the lifetime of the credentials (e.g.,
in advance how long the credentials are needed. just for the duration of the session) is often not an option since
the user may not know in advance how long the credentials are needed
(i.e., how long a session may last).
4. Solution Approaches 4. Solution Approaches
4.1 Associating user identity and device credentials within the session 4.1. Associating user identity and device credentials for session
duration
As devices may already possess device certificates, a UA may want to As devices may already possess device certificates, a UA may want to
bind these credentials to the identity of the registering user for bind these credentials to the identity of the registering user for
the duration of the registration. During the registration, the the duration of the registration. During the registration, the
registrar may authenticate the device in addition to the user. The registrar may authenticate the device in addition to the user. The
registrar is therefore able to associate the user authentication registrar is therefore able to associate the user authentication
(e.g. using SIP digest authentication) with the certificate-based (e.g. using SIP digest authentication) with the certificate-based
device authentication which has beed performed as part of the TLS device authentication which has beed performed as part of the TLS
handshake. If the authentication server and the registrar are co- handshake. If the authentication server and the registrar are co-
located then the authentication server has access to the credentials located then the authentication server has access to the credentials
skipping to change at page 5, line 41 skipping to change at page 5, line 46
the body and thus the certificate has not been tampered with while in the body and thus the certificate has not been tampered with while in
transit, and that it was provided by a particular entity (as transit, and that it was provided by a particular entity (as
indicated in the assertion). indicated in the assertion).
This is important, as the receiving client may not be able to verify This is important, as the receiving client may not be able to verify
the certificate provided by the initiator of the communication (for the certificate provided by the initiator of the communication (for
example, because it was created by an enterprise CA and the root example, because it was created by an enterprise CA and the root
certificate of the issuing CA cannot be validated). In-band certificate of the issuing CA cannot be validated). In-band
certificate provision may be done as described in RFC 3261 for self- certificate provision may be done as described in RFC 3261 for self-
signed certificates or by using the recently proposed new MIKEY signed certificates or by using the recently proposed new MIKEY
option [I-D.ignjatic-msec-mikey-rsa-r] for key management, allowing option [I-D.ietf-msec-mikey-rsa-r] for key management, allowing the
the certificate transport as part of a MIKEY message, which in turn certificate transport as part of a MIKEY message, which in turn can
can be transmitted in SIP using the [I-D.ietf-mmusic-kmgmt-ext] be transmitted in SIP using the [I-D.ietf-mmusic-kmgmt-ext] approach.
approach.
In any case, using the approach decribed in [I-D.ietf-sip-identity], In any case, using the approach decribed in [I-D.ietf-sip-identity],
the authentication service, through the signature over the body, the authentication service, through the signature over the body,
implicitly asserts that the identity in the FROM field is somehow implicitly asserts that the identity in the FROM field is somehow
connected to a certificate in the body. According to [I-D.ietf-sip- connected to a certificate in the body. According to [I-D.ietf-sip-
identity] the authentication service is responsible to make sure that identity] the authentication service is responsible to make sure that
the user is allowed to use the stated identity in the FROM field the user is allowed to use the stated identity in the FROM field
within the domain of the server's authority. within the domain of the server's authority.
4.2 Associating user identity and device credentials upfront 4.2. Associating user identity and device credentials upfront
Another approach would be that the UA uploads the credentials to the Another approach would be that the UA uploads the credentials to the
credential server also for the duration of the registration, which credential server also for the duration of the registration, which
enables other UAs to fetch the certificate upfront, before starting enables other UAs to fetch the certificate upfront, before starting
communication with the target UA. This approach is supported by the communication with the target UA. This approach is supported by the
usage of [I-D.ietf-sipping-certs]. A limitation, which has been usage of [I-D.ietf-sipping-certs]. A limitation, which has been
stated in the Overview section above is that it might not be suitable stated in the Overview section above is that it might not be suitable
for external parties as they may not be allowed to obtain the for external parties as they may not be allowed to obtain the
appropriate certificates from a corporate server. appropriate certificates from a corporate server.
4.3 Potential enhancements to SIP Identity 4.3. Potential enhancements to SIP Identity
As required by [I-D.ietf-sip-identity], the authentication server has As required by [I-D.ietf-sip-identity], the authentication server has
to authenticate the user whose identity appears in the FROM field of to authenticate the user whose identity appears in the FROM field of
the SIP request by some means, e.g. by challenging the user. the SIP request by some means, e.g. by challenging the user.
Additionally, the authentication server may also check and assert, Additionally, the authentication server may also check and assert,
that a dedicated certificate was used during registration over a TLS that a dedicated certificate was used during registration over a TLS
protected link for the authentication on the TLS level. This would protected link for the authentication on the TLS level. This would
not be possible with the current [I-D.ietf-sip-identity] draft and not be possible with the current [I-D.ietf-sip-identity] draft and
would require further specification. SIP-SAML [I-D.tschofenig-sip- would require further specification. SIP-SAML [I-D.tschofenig-sip-
skipping to change at page 7, line 26 skipping to change at page 7, line 34
Response identity e.g. for the mutual exchange of certificates, Response identity e.g. for the mutual exchange of certificates,
cannot be achieved using the approach described in [I-D.ietf-sip- cannot be achieved using the approach described in [I-D.ietf-sip-
identity]. identity].
7. IANA Considerations 7. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
8. Acknowledgments 8. Acknowledgments
The authors would like to thank Jon Peterson and Cullen Jennings for The authors would like to thank Jon Peterson and Cullen Jennings as
the discussions in context of SIP identity. Additionally, we would well as John Elwell and Francois Audet for the discussions in context
like to thank Andreas Pashalidis for his comments. of SIP identity. Additionally, we would like to thank Andreas
Pashalidis for his comments.
9. References 9. References
9.1 Normative References 9.1. Normative References
[I-D.ietf-sip-identity] [I-D.ietf-sip-identity]
Peterson, J. and C. Jennings, "Enhancements for Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", draft-ietf-sip-identity-05 Initiation Protocol (SIP)", draft-ietf-sip-identity-05
(work in progress), May 2005. (work in progress), May 2005.
9.2 Informative References 9.2. Informative References
[I-D.ietf-mmusic-kmgmt-ext] [I-D.ietf-mmusic-kmgmt-ext]
Arkko, J., "Key Management Extensions for Session Arkko, J., "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", draft-ietf-mmusic-kmgmt-ext-15 (work in Protocol (RTSP)", draft-ietf-mmusic-kmgmt-ext-15 (work in
progress), June 2005. progress), June 2005.
[I-D.ietf-msec-mikey-rsa-r]
Ignjatic, D., "An additional mode of key distribution in
MIKEY: MIKEY-RSA-R", draft-ietf-msec-mikey-rsa-r-00 (work
in progress), July 2005.
[I-D.ietf-sipping-certs] [I-D.ietf-sipping-certs]
Jennings, C. and J. Peterson, "Certificate Management Jennings, C. and J. Peterson, "Certificate Management
Service for The Session Initiation Protocol (SIP)", Service for The Session Initiation Protocol (SIP)",
draft-ietf-sipping-certs-01 (work in progress), draft-ietf-sipping-certs-02 (work in progress), July 2005.
February 2005.
[I-D.ignjatic-msec-mikey-rsa-r]
Ignjatic, D. and L. Dondeti, "An additional mode of key
distribution in MIKEY", draft-ignjatic-msec-mikey-rsa-r-00
(work in progress), January 2005.
[I-D.tschofenig-sip-saml] [I-D.tschofenig-sip-saml]
Tschofenig, H., "Using SAML for SIP", Tschofenig, H., "Using SAML for SIP",
draft-tschofenig-sip-saml-03 (work in progress), draft-tschofenig-sip-saml-04 (work in progress),
July 2005. July 2005.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. August 2004.
Authors' Addresses Authors' Addresses
Steffen Fries Steffen Fries
Siemens Siemens
 End of changes. 23 change blocks. 
47 lines changed or deleted 50 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/