Certificate Authentication in SIP
draft-dotson-sip-certificate-auth-04

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 May 9, 2008.

Abstract

This document defines requirements for adding certificate authentication to the Session Initiation Protocol (SIP). The use case addressed is that of a SIP device authenticating on behalf of configured users using a device certificate for purposes such as registration. This document is being presented with the intention of providing requirements to any potential solutions specifying certificate authentication within SIP networks. Supporting certificate authentication in SIP would provide strong authentication and increase the types of possible deployment scenarios.

Table of Contents

1.  Introduction
    1.1.  Overview
    1.2.  Use Cases
    1.3.  Terminology
2.  Existing Work
3.  Requirements and Recommendations
4.  IANA Considerations
5.  Security Considerations
6.  Normative References
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

SIP enables many real-time IP communications architectures. While it offers many advantages, it is restrictive regarding the types of credentials supported. As of this writing, it only provides for username and pre-shared key based credentials. The lack of stronger credential types, specifically certificate-based credentials, is restricting certain deployment scenarios and the advantages that can be realized by them.

Certificates have been successfully deployed in many networks, such as PacketCable. They offer two distinct advantages, among others, over username and password based credentials:

• They provide relatively stronger authentication, for example, when compared to usernames and passwords (as used commonly)
• They allow authentication in scenarios where the clients are not pre-configured in the SIP network (using the Public Key Infrastructure, PKI)

Thus, SIP deployments would greatly benefit from certificate-based authentication in SIP networks. However, this requires careful consideration. This document presents such considerations, requirements, and recommendations. It does not present any solutions, which are considered out-of-scope for this document.

1.1.  Overview

The sections in the document mirror the work that was done to create the document. The use cases that were the catalyst for the document are described. The use cases in turn drove the requirements. Existing standardized solutions were then evaluated to determine their ability to meet the requirements.

1.2.  Use Cases

The primary use case for the requirements discussed in this document is that of a UA registering with a SIP Registrar, where the UA has only a certificate for authentication to the network, or possibly multiple credentials with one credential being a certificate. The following diagram shows the message flows during a registration as currently defined in RFC 3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261].

   User                          SIP Server
     |                               |
     |          REGISTER             |
     |------------------------------>|
     |                               |
     |      401 Unauthorized         |
     |<------------------------------|
     |                               |
     |          REGISTER             |
     |------------------------------>|
     |                               |
     |            200 OK             |
     |<------------------------------|
     |                               |

In this call flow, a user sends a SIP REGISTER request to the SIP Server which includes the user's identity. The SIP server provides a challenge to the user. The user uses the challenge and its credentials to create a challenge response and sends this back to the SIP server. The SIP server validates the user's credentials.

There may be multiple proxies between the UA and the Registrar. In this case, the UA needs to be able to authenticate with the Registrar using a public certificate. The following figure uses the previous example with the addition of an intermediate proxy.

   User                        Proxy Server              SIP Server

     |                               |                            |
     |          REGISTER             |           REGISTER         |
     |------------------------------>|--------------------------->|
     |                               |                            |
     |      401 Unauthorized         |       401 Unauthorized     |
     |<------------------------------|<---------------------------|
     |                               |                            |
     |          REGISTER             |           REGISTER         |
     |------------------------------>|--------------------------->|
     |                               |                            |
     |            200 OK             |            200 OK          |
     |<------------------------------|<---------------------------|
     |                               |                            |

In this example, a proxy server is situated between the User and the SIP Server. The proxy does not have access to the user's subscription data. If confidentiality is used, the User and Proxy would terminate the confidentiality protection.

In regards to the entity being authenticated, there are several deployment scenarios that can be readily identified.

• The entity may be a device, in which case the certificate would contain information related to the device identity (e.g., MAC address, FQDN, etc).
• The entity may be a user, in which case the certificate would contain information related to the user identity (e.g., SIP URI, etc).

For the purposes of this document, only the device certificate use case is considered. The registrar contains information mapping the unique device identification asserted in the certificate to authorized SIP identities for that device. These identities can then be mapped to users of the device, or user devices connected to the device such as phone handsets, as shown in the following figure.

                                     Authentication
                                <======================>
 +--------+
 | Phone  |        +------------+
 | Alice  |--------|            |       +-------+       +-----------+
 +--------+        |            |       |       |       |           |
                   | SIP Device |-------| Proxy |-------| Registrar |
 +--------+        |            |       |       |       |           |
 | Phone  |--------|            |       +-------+       +-----------+
 |  Bob   |        +------------+
 +--------+

1.3.  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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

This document borrows SIP related terminology as specified in RFC 3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261].

Certificate: A PKIX (Housley, R., Polk, W., Ford, W., and D. Solo, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” April 2002.) [RFC3280] style certificate containing a public key and a list of identities in the subjectAltName that are bound to this key.

End entity: User of X.509 certificates and/or end user system that is represented by the certificate.

2.  Existing Work

Currently, RFC 3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] defines procedures for performing SIP Digest authentication using usernames and passwords. SIP Digest is a challenge based mechanism for authentication. Any time a UA or proxy server receives a request it may challenge the initiator of the request to provide assurance of its identity.

SIP Digest utilizes a challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. The Digest scheme challenges using a nonce value. A valid response contains a checksum of the password, username, the provided nonce value, and other parameters. As a result, the password is never sent in the clear. SIP Digest provides authentication and replay detection. Because it is based on passwords, it suffers from the security weaknesses of password based systems.

The genesis for this document was the lack of an existing solution for authentication from a UA to a registrar using a public key certificate within SIP messaging. While there are mechanisms related to SIP and certificates, and SIP and authentication, none of these, as currently specified, are able to meet all the requirements of this document. The following existing solutions were reviewed:

• TLS
• SIP S/MIME
• AIB
• SIP Identity
• SIP Security Agreement

Following is an analysis of existing work in the IETF in relation to the requirements presented in this document.

RFC 4346 (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.1,” April 2006.) [RFC4346] describes Transport Layer Security (TLS) between a client and a server. TLS provides privacy and data integrity between two communiticating applications. TLS is currently required to be supported by RFC 3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] proxy servers and registrars. Mutual TLS could be performed between the UA and it's nearest proxy in order to authenticate the UA to the proxy, and the proxy could then assert the identity of the UA through SIP Identity (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.) [RFC4474] or RFC 4474 (Jennings, C., Peterson, J., and M. Watson, “Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks,” November 2002.) [RFC3325] P-Asserted-Identity headers to the registrar. In this model, the edge proxy performing the authentication is part of the operator's trusted network.

• Because device certificates contain the identity of a device (e.g., MAC address), and the registrar contains the mapping of device certificate to authorized identities, extra signaling from proxy to registrar may be needed in order to convey the device identity from the certificate to the registrar.
• RFC 3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] does not define the use of client certificates for mutual TLS and SIP.

RFC 3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] discusses the use of S/MIME and certificates to provide confidentiality, integrity and authentication of UAs. The procedures are based on the use of the CMS content types signedData, for signing messages, and enveloped data, for encrypting data.

• S/MIME is not based on challenge/response, requiring the UA to always send dialog requests S/MIME protected. This is even more of an issue where authentication of non-REGISTERs (e.g., INVITEs) is desired.
• RFC 3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] does not define the use of using S/MIME to authenticate a UA to a registrar.
• S/MIME may have issues with network intermediaries that must view or modify the bodies of SIP messages (especially SDP).
• S/MIME does not have a means to negotiate authentication methods (assuming the authentication would be between the UA and registrar, and a UA may contain multiple credential types).

RFC 3893 (Peterson, J., “Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format,” September 2004.) [RFC3893] Authenticated Identity Body (AIB) Format defines a more specific mechansim than the S/MIME solution in RFC 3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261]. It changes the MIME type and reduces the number of headers included in the cryptographic operation from those recommended in RFC 3261. As the solution is similar to RFC 3261 S/MIME in relation to the requirements in this document, the solution has the same deficiencies as S/MIME described in the previous paragraph.

RFC 4474 (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.) [RFC4474] SIP Identity provides a mechanism to cryptographically assure the identity of originators of SIP messages. As described in Section 5, Identity uses a private key and a certificate associated with the domain indicated in the From header. An authentication service authenticates the UAC and then inserts an Identity header and an Identity-Info header in the forwarded request. The Authentication Service is typically located at the outbound proxy and may authenticate the UAC using digest authentication and/or a TLS session.

• Identity is not based on challenge/response, requiring the UA to always send dialog requests protected. This is even more of an issue where authentication of non-REGISTERs (e.g., INVITEs) is desired.
• Unless the UA is directly connected to the Authentication Service, TLS is not available to the UA to perform mutual TLS to the Authentication Service.
• Identity requires the Authentication Service to be authoritative for a domain, and this is typically not supported on a UA as the UA would need to be its own domain.

RFC 3329 (Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. Haukka, “Security Mechanism Agreement for the Session Initiation Protocol (SIP),” January 2003.) [RFC3329] Security Mechanism Agreement for the Session Initiation Protocol (SIP) describes a mechanism for a user agent and its next-hop SIP entity to negotiate security mechanisms. RFC 3329 (Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. Haukka, “Security Mechanism Agreement for the Session Initiation Protocol (SIP),” January 2003.) [RFC3329] may be used to enable confidentiality of messaging for the solution between a client and its next-hop SIP server, but it is not a solution in itself.

3.  Requirements and Recommendations

The following are the general requirements and recommendations for the support of certificate based authentication in SIP networks. A proposed solution MUST meet all the requirements stated in this section.

1. The solution MUST utilize SIP messaging and be compliant to RFC 3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261].
2. Depending on the solution, it MAY need to follow a challenge/response paradigm, to allow the network to decide the policy for authentication (i.e., keep the client from always computing and sending authentication data).
3. The solution MUST provide end-to-end authentication. One example is the authentication between UAs and Registrars during a registration that includes intermediate proxies. In this case, the registrar must receive enough information to ensure the authenticity of the client and the authorization of the client to receive service.
4. A device certificate MUST represent an end entity that will be authenticated. The certificate MUST contain enough information that allows the end entity to be identified. RFC 2818 (Rescorla, E., “HTTP Over TLS,” May 2000.) [RFC2818] contains some rules on end entity authentication that may be utilized in the solution.
5. Relying parties MUST check the validity of certificates as defined in RFC 3280 (Housley, R., Polk, W., Ford, W., and D. Solo, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” April 2002.) [RFC3280].Relying parties MAY use the additional rules of RFC 2818 (Rescorla, E., “HTTP Over TLS,” May 2000.) [RFC2818] to validate end entity certificates.
6. The solution MUST support client-only authentication and mutual authentication modes. Client-only authentication modes could be employed when mutual authentication is achieved by other means (e.g., TLS).

The following are the recommendations that should be considered when developing a solution that complies with this document.

1. This document RECOMMENDS that solutions consider a way for the entities to agree on the authentication to be used. This would allow for the coexistence and the use of multiple authentication mechanisms. Exceptions include solutions that do not allow for the use of multiple credentials.
2. The methodology SHOULD consider message size impacts and SHOULD attempt to limit them. Bandwidth constrained environments may be impacted.
3. The solution SHOULD re-use existing standards and solutions where applicable.

4.  IANA Considerations

None.

5.  Security Considerations

This document defines the requirements for certificate-based authentication within SIP. As such, it does not define a specific solution or set of technologies. However, the eventual technical architecture meeting these requirements must consider the security of the solution.

Depending on the solution, confidentiality and integrity of messages may be necessary. Replay protection must be provided.

6. Normative References

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2007).

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.

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, THE IETF TRUST 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.

Intellectual Property

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.