SIPPING S. Fries
Internet-Draft H. Tschofenig
Expires: August 23, 2006 Siemens
February 19, 2006
SIP Identity Usage in Enterprise Scenarios
draft-fries-sipping-identity-enterprise-scenario-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 23, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes a use case for the SIP Identity document
involving certificate management with the focus on enterprise
environments. It provides a best current practice document for
binding an identity to a certificate for the duration of a session.
The certificate may then be used to bootstrap further security
parameters, e.g., for securing media data. A discussion of possible
enhancements is included in the appendix.
Fries & Tschofenig Expires August 23, 2006 [Page 1]
Internet-Draft SIP Identity Usage February 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Existing Building Blocks . . . . . . . . . . . . . . . . . . . 4
4. Scenario and Profile . . . . . . . . . . . . . . . . . . . . . 5
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Alternative Approaches . . . . . . . . . . . . . . . 8
A.1. Associating user identity and credentials upfront . . . . 8
A.2. Enhancements to SIP Identity using SIP SAML . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Fries & Tschofenig Expires August 23, 2006 [Page 2]
Internet-Draft SIP Identity Usage February 2006
1. Introduction
In current enterprise environments certificates are used to provide
secure access to web servers, to protect server-to-server
communication, and for administrative purposes. In certain
scenarios, authentication of the access device as well as the user is
important. In order to support such scenarios, IP-based enterprise
systems may be equipped with device certificates. Several enterprise
networks already have a device authorization infrastructure.
This security often is restricted to the perimeter of the corporate
network, as peers outside the corporate network may not be able to
verify a certificate given by a corporate CA.
For user-to-user communication, the receiving side needs to be able
to validate a certificate as belonging to the sending side. A device
certificate is not ideally suited to this purpose since it contains a
device specific identifier. Although user certificates would seem to
be a better alternative, there are certain difficulties with this at
present. Users often use different devices at different times, and
to facilitate this (and also prevent unauthorised use of a
certificate in the absence of a user), private keys and certificates
may be provided on smart cards. However, this almost rules out the
simultaneous usage of this card in two devices (e.g., hard phone and
PC). As a complete role out of a PKI providing server and user
certificates that are globally usable is not likely in the near
future (at least for user certificates), intermediate steps need to
be taken.
This document discusses the usage of certificates with a limited
applicability, e.g., device certificates or self-signed certificates
in an enterprise environment in the context of SIP. In particular,
this document focuses on the session binding of these certificates to
user identities.
The scenario, which is the focus of this document, can be described
as follows. Note that the applicability of the approach is not
restricted to this example use case.
A user in a corporate environment has been assigned a hardware-based
phone. With this phone the user may initiate and receive calls
inside the corporate environment and also to/from the outside. Since
the corporate policy requires certain security services to be in
place, e.g., media encryption, for internal as well as external
calls, the phone needs to support security parameter negotiation
between the participants of a call. To achieve this negotiation
securely, the phone typically needs to be equipped with an
appropriate certificate. Note that since the phone may be shared by
Fries & Tschofenig Expires August 23, 2006 [Page 3]
Internet-Draft SIP Identity Usage February 2006
several users, the phone may even be able to generate certificates
for the user currently associated with this phone.
Using the phone, i.e., the voice service, requires the user to
authenticate himself, often based on a username and a password. One
reason why it is assumed that the user does not authenticate using a
certificate and corresponding private key is the lack of an
appropriate interface in order to accomplish the necessary
certificate provision to the phone (e.g., using smart cards or secure
USB tokens). Even with such an interface, the enterprise may not be
able to issue globally resolvable certificates due to technical or
financial reasons.
A certificate based on the phone can be used to secure the exchange
of security parameters. The problem to be solved here is the binding
of available certificate material to a user identity for the duration
of the session concerned.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Existing Building Blocks
RFC 3261 [RFC3261] already describes the transport of certificates
within the SDP body of a message using the S/MIME Key Exchange
approach described in Section 23.2 of [RFC3261]. Here, a user may
submit a self-signed certificate. It is even allowed that the
subjectname field be different from the AoR submitted in the From
header field. The drawback is that the receiver may not be able to
verify the validity of the embedded key and associate it with a
particular user identity.
[I-D.ietf-sip-identity] introduces a new entity, called the
authentication service, which provides assurance about the identity
in the From header field of a SIP request (such as an INVITE
request). The authentication service does this by adding an
assertion to the SIP header in a SIP request. This assertion
provides integrity protection for certain header fields and also for
the body of the SIP request. The assertion is added after
authenticating (and authorizing) the request initiator, e.g., by HTTP
digest authentication.
Fries & Tschofenig Expires August 23, 2006 [Page 4]
Internet-Draft SIP Identity Usage February 2006
4. Scenario and Profile
Subsequently, a profile is described for a BCP providing an implicit
binding of a user identity to the available certificate for the
duration of a session. The profile ensures interoperability of
different vendor's products regarding the described scenario. The
profile does not define any new messages or parameters. It rather
takes existing options from RFC 3261 and appropriate SIP extensions
to achieve the binding.
Devices may already possess certificates or may generate self-signed
certificates on logon of a new user or on request. A UA may want to
bind these credentials to the identity of the registering user for
the duration of the registration or just for the duration of a
session. When the UA issues a SIP request, the outbound proxy /
registrar will authenticate the UA as having the credentials
associated with the user identified in the From header field. For
example, the UA may be challenged to provide HTTP digest
authentication. Alternatively, if the request is received over a TLS
connection on which the UA has been authenticated previously, then
further authentication may not be necessary. Having authenticated
the UA, any certificate conveyed in that request can be implicitly
associated with that UA and hence with the authenticated user,
provided the request has been integrity protected (e.g., through the
use of TLS). An authentication service, as defined in [I-D.ietf-sip-
identity], can then verify that the URI in the From header field
corresponds to an AoR that the authenticated user is allowed to use,
and on this basis can provide an assertion in the forwarded request
that the From header field URI does indeed identify the origin of the
request. This assertion is in the form of an inserted Identity
header field in the INVITE message. This provides a signature over
some of the header fields in the forwarded request and over the
entire body, using the domain's private key. Thus, if a certificate
is included in a body, it will be integrity protected and any
recipient of the request can be sure that the certificate originated
at a device having the credentials of the user identified in the From
header field, provided the signature can be verified and validated.
This can be facilitated if the authentication service uses a
certificate signed by a well know CA.
An extension, allowing the authentication service to add a
fingerprint of a certificate used during the user authentication is
described in Appendix A of this document. The signature of the
authentication service enables the receiving UAC to verify that the
body and thus the certificate has not been tampered with while in
transit from the authentication server to the recipient, and that it
was provided by a particular entity stated in the FROM field (as
indicated in the assertion). The message integrity together with the
Fries & Tschofenig Expires August 23, 2006 [Page 5]
Internet-Draft SIP Identity Usage February 2006
assertion create a temporary binding (identity, certificate) at the
receiver side.
This is important, as the receiving client may not be able to verify
the certificate provided by the initiator of the communication (for
example, because it was created by an enterprise CA and the root
certificate of the issuing CA cannot be validated). In-band
certificate provision may be done as described in RFC 3261 [RFC3261]
for self-signed certificates or by using the recently proposed new
MIKEY option [I-D.ietf-msec-mikey-rsa-r] for key management, allowing
the certificate transport as part of a MIKEY message, which in turn
can be transmitted in SIP using the [I-D.ietf-mmusic-kmgmt-ext]
approach.
After verifying the signature, the receiving client can store the
certificate associated with the identity stated in the FROM header
field for the duration of the session. After the session ends the
receiving UA SHOULD delete the association.
In any case, using the approach described in [I-D.ietf-sip-identity],
the authentication service, through the signature over the body,
implicitly asserts that the identity in the FROM field is somehow
connected to a certificate in the body.
Note that the authentication service may not be held responsible for
attacks on the path between the UAC and the authentication server via
the SIP proxy. As this approach is provided in-band it only requires
an [I-D.ietf-sip-identity] compliant authentication service to be in
place as additional component.
5. Conclusion
In this document we propose to use the scenario and profile described
above to enable in-band certificate exchange and association with an
identity in the FROM header field as a best current practice use case
for [I-D.ietf-sip-identity]. It would require a UACs to store an
association of identity and certificate for the duration of a
session. This is done in order for the receiver to ensure that
during the entire session the same certificate/private key is used
for cryptographic purposes with the calling UA. This creates a
temporary binding (identity, certificate) at the receiver side.
Alternative approaches are described in Appendix A. These
alternatives, however, suffer from some limitations or require
protocol extensions.
Fries & Tschofenig Expires August 23, 2006 [Page 6]
Internet-Draft SIP Identity Usage February 2006
6. Security Considerations
To avoid the use of a dedicated certificate and private key pair from
several users, the device needs to ensure that a fresh key pair is
generated upon user login. The lifetime of the certificate may be
rather short. A new certificate may be generated during the period
of registration if a certificate expires.
If a certificate is compromised, it needs to be revoked and a new
certificate has to be issued to the device. Following the approach
in [I-D.ietf-sipping-certs] a notification with an empty body is sent
to indicate that the certificate is no longer valid.
Response identity, e.g., for the mutual exchange of certificates,
cannot be achieved using the approach described in [I-D.ietf-sip-
identity]. Here, a the recently submitted ID handling connected SIP
identity [I-D.elwell-sip-connected-identity] may provide a solution.
This ID describes an approach for targeting the authenticated
connected identity provisioning using [I-D.ietf-sip-identity].
7. IANA Considerations
This document does not require actions by IANA.
8. Acknowledgments
The authors would like to thank Jon Peterson and Cullen Jennings as
well as John Elwell and Francois Audet for the discussions in context
of SIP identity. Additionally, we would like to thank Andreas
Pashalidis for his comments.
9. References
9.1. Normative References
[I-D.elwell-sip-connected-identity]
Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", draft-elwell-sip-connected-identity-00
(work in progress), October 2005.
[I-D.ietf-sip-identity]
Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", draft-ietf-sip-identity-06
(work in progress), October 2005.
Fries & Tschofenig Expires August 23, 2006 [Page 7]
Internet-Draft SIP Identity Usage February 2006
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
9.2. Informative References
[I-D.ietf-mmusic-kmgmt-ext]
Arkko, J., "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", draft-ietf-mmusic-kmgmt-ext-15 (work in
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-02 (work
in progress), February 2006.
[I-D.ietf-sipping-certs]
Jennings, C. and J. Peterson, "Certificate Management
Service for The Session Initiation Protocol (SIP)",
draft-ietf-sipping-certs-02 (work in progress), July 2005.
[I-D.tschofenig-sip-saml]
Tschofenig, H., "Using SAML for SIP",
draft-tschofenig-sip-saml-04 (work in progress),
July 2005.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
Appendix A. Alternative Approaches
A.1. Associating user identity and credentials upfront
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
problem that deployment of end user certificates and a global PK
infrastructure is not available.
[I-D.ietf-sipping-certs] is suitable for an enterprise environment to
provide certificate information to the end hosts and end users via a
credential server. UAs can fetch certificates and use them as
Fries & Tschofenig Expires August 23, 2006 [Page 8]
Internet-Draft SIP Identity Usage February 2006
necessary. UAs may also store their own credentials on the
credential server. This may be done also (only) for the duration of
a registration, which enables other UAs to fetch the certificate
upfront, before starting communication with the target UA. This
approach requires that both parties have sufficient access to a
credential server. Besides the credential server, also an
authentication server may be needed to support certain scenarios.
This approach works nicely in many environments but there may be
limitations is others
In order to use the credential server in a way in which certificates
are globally accessible it is necessary to put the credential server
on the public Internet. This is in order to enable persons from
outside to access the certificate information before making or
answering a call. This approach may not be feasible for all
enterprises, as there are certain company based regulations regarding
the safeguarding of employee information. A corporate directory for
instance is normally not accessible by people outside the enterprise.
The combination of both concepts, namely SIP Identity and SIPPING-
CERTS, provides the possibility to route a NOTIFY, which contains a
certificate from the credential server, via the authentication
service to the UA. As stated in [I-D.ietf-sipping-certs], if the
identity asserted by the authentication service matches the AOR that
the UA subscribed to, the certificate in the NOTIFY can be treated as
valid and may be used for the protection of subsequent communication.
A general precondition is that the UA and the authentication server
trust the same root CA.
This latter approach requires the certificate SubjectAltName to match
a given AoR, as described in Section 8.10 of [I-D.ietf-sipping-
certs], thus leaving certain device certificates or certain self-
signed certificates outside the possible solution.
A.2. Enhancements to SIP Identity using SIP SAML
As required by [I-D.ietf-sip-identity], the authentication server has
to authenticate the user whose identity appears in the FROM field of
the SIP request by some means, e.g., by challenging the user.
Additionally, an authentication server may also check and assert,
that a dedicated certificate was used during registration over a TLS
protected link for the authentication on the TLS level. This
approach is currently not be possible with [I-D.ietf-sip-identity]
and would require further specification.
Fries & Tschofenig Expires August 23, 2006 [Page 9]
Internet-Draft SIP Identity Usage February 2006
A document supporting this approach is provided in SIP-SAML
[I-D.tschofenig-sip-saml], which enables SAML assertions and
artifacts to be carried in SIP. This document offers a mechanism to
deliver additional information about previously executed
authentication.
Fries & Tschofenig Expires August 23, 2006 [Page 10]
Internet-Draft SIP Identity Usage February 2006
Authors' Addresses
Steffen Fries
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: steffen.fries@siemens.com
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@siemens.com
Fries & Tschofenig Expires August 23, 2006 [Page 11]
Internet-Draft SIP Identity Usage February 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Fries & Tschofenig Expires August 23, 2006 [Page 12]