SIP K. Darilion
Internet-Draft enum.at
Intended status: Standards Track H. Tschofenig
Expires: August 21, 2008 Nokia Siemens Networks
February 18, 2008
E.164 Ownership using Public Keys stored in ENUM
draft-darilion-sip-e164-enum-00.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 21, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
To determine which domain is allowed to claim ownership of a certain
telephone number is difficult. This may cause problems when to
authenticate endpoints that use telephone number URIs and domain
names in their From address. This document investigates a proposal
that stores a public key below the corresponding ENUM tree in the
DNS. The verifier can determine ownership by performing an ENUM
lookup to retrieve the public key from the DNS and to use it for
Darilion & Tschofenig Expires August 21, 2008 [Page 1]
Internet-Draft E.164 Ownership using ENUM February 2008
verifying the signature created as part of the SIP Identity
mechanism.
This document is a contribution to the ongoing discussion on RFC 4474
when used in combination with E.164 numbers.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. ENUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. User ENUM . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Infrastructure ENUM . . . . . . . . . . . . . . . . . . . 5
3.3. Private ENUM trees . . . . . . . . . . . . . . . . . . . . 5
4. Authentication Service Behavior . . . . . . . . . . . . . . . 6
5. Verifier Behavior . . . . . . . . . . . . . . . . . . . . . . 6
6. Considerations for User Agent . . . . . . . . . . . . . . . . 8
7. Considerations for Proxy Servers . . . . . . . . . . . . . . . 8
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Caching and Scalability . . . . . . . . . . . . . . . . . . . 9
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 10
11. Security Considerations . . . . . . . . . . . . . . . . . . . 10
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
12.1. TBD 'Unable to retrieve Public Key from DNS' Response
Code . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 11
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
14.1. Normative References . . . . . . . . . . . . . . . . . . . 12
14.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Darilion & Tschofenig Expires August 21, 2008 [Page 2]
Internet-Draft E.164 Ownership using ENUM February 2008
1. Introduction
RFC 4474 [3] defines a mechanism whereby an authentication service
authenticates a SIP UAC (possibly by sending a Digest authentication
challenge) and verifies whether he or she is authorized to use the
identity that is populated in the From header field. The
authentication service then computes a hash over some particular
headers, including the From header field and the bodies in the
message. This hash is signed with the certificate for the domain and
inserted in the 'Identity' header field in the SIP message.
The proxy, as the holder of the private key of its domain, is
asserting that the originator of this request has been authenticated
and that a specific user is authorized to claim the identity (the SIP
address-of-record) that appears in the From header field. The proxy
also inserts a companion header field, Identity-Info, that tells the
verifying party how to acquire its certificate, in case it is not yet
known already.
When the verifier receives the SIP message, it verifies the signature
provided in the Identity header, and thus can determine whether the
domain indicated by the host portion of the AoR in the From header
field authenticated the user, and permitted the user to assert that
From header field value.
The use of phone numbers with SIP was introduced with the TEL URL
scheme [5] whereby domain names were not used with the phone numbers.
SIP URIs always have domain names. In SIP [2], a translation between
SIP URIs and TEL URLs is described: when translating from a SIP URI
to a TEL URL, the domain name from the SIP URI is simply dropped.
When translating in the other direction (or simply generating a SIP
URI from an E.164 number) it is not clear how to populate the domain
name.
When SIP Identity [3] is applied to E.164 numbers [8] then there is
the question what the identity assertion actually means.
Additionally, the usage of the domain for an E.164 number is not
useful as described in [7]. This document does not make use of a
domain field attached to an E.164 number.
******************************************************************
The authors of this document do not claim that the question of
what ownership of E.164 numbers means is sufficiently well
understood at this point to be fully confident that any solution
actually helps to improve the current state-of-the-art. In fact,
the entire end-to-end security story when a call originates in the
PSTN and terminates somewhere on the Internet may weaken the
security of the call to such an extend that additional security
Darilion & Tschofenig Expires August 21, 2008 [Page 3]
Internet-Draft E.164 Ownership using ENUM February 2008
mechanisms applied to the communication on the Internet leg of the
call may not improve the overall security based on "security is as
good as the weakest link". However, strawman proposals (like this
one) might help to better understand the different forms of E.164
address ownership. The authors have received a large number of
intesting comments after distributing an initial proposal.
******************************************************************
This document investigates the ability to store a public key in the
ENUM database. The private key corresponding to that public key is
then used by the authentication service to compute the digital
signature for the 'Identity' header. Additionally, an indication is
provided for the verifier inside the Identity-Info header so that it
is apparent that the public key is not available at a given URI but
rather in the DNS used by ENUM. When the verifier receives a SIP
message that contains the 'Identity' header instead of obtaining the
certificate it performs a DNS lookup to determine the public key used
for the specific E.164 number. Possessing the public key stored with
the E.164 number allows verification of the digital signature.
From a design point of view we would like to make the following note:
This document does not define new SIP headers. Instead, it re-
uses existing headers from the SIP Identity specification. The
'Identity-Info' header is reused to convey a so-called selector
and the ENUM root. Both are required for the verification
procedure. The selector allows the authentication service to
support multiple concurrent public keys per signing domain and the
ENUM root allows to use different ENUM trees. This document
suggests to store the selector and the ENUM root as a URI in the
'Identity-Info' even though a new and more flexible header is
already required by the SIP SAML specification.
To summarize the proposed changes; this document suggests an
alternative method for storing public keys, namely one based on the
DNS in relationship to the ENUM database. This method is
conceptually similar to the approach used by DKIM [4]. As a
consequence, the mechanism to look-up the public key by the verifier
is different to the one proposed in [3]. The suggested modifications
are intentially kept at a minimum and only applicable when an E.164
number is signed by an authentication service.
2. Terminology
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
Darilion & Tschofenig Expires August 21, 2008 [Page 4]
Internet-Draft E.164 Ownership using ENUM February 2008
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [1].
3. ENUM
ENUM comes in different deployment variations. The incentives for
storing public keys in ENUM with these deployments are different.
Mostly, they can be distinguished by the root domain and whether
access is restricted or unrestricted.
3.1. User ENUM
User ENUM is defined in [6]. It uses the root domain e164.arpa and
access is not restricted. The right to provison DNS records is given
to the user of the corresponding E.164 number.
Use cases for putting the public key into user ENUM are the
following. A user who has registered its E.164 number into ENUM and
has its own SIP infrastructure (like companies have) or users
utilizing their own open SIP infrastructure (similar to users running
an SMTP server).
3.2. Infrastructure ENUM
There is no exact definition for Infrastructure ENUM (also called
Carrier ENUM). Infrastrucure ENUM is often understood as a public
accessible ENUM tree (for example ie164.arpa) where the "carrier-of-
record" (the carrier which provide telephony service to the end-user)
is allowed to provision the DNS records. It can also be seen as
federations of private ENUM.
The use case for infrastructure ENUM is similar to user ENUM except
that now carriers are able to relate the "carrier of record" to the
E.164 number. For example, if a call is routed from carrier A to
carrier B via transit carrier T, T will trust A and B will trust T.
There is no way for B to verify that the caller is really allowed to
use the indicated caller id.
3.3. Private ENUM trees
Private ENUM trees choose just any available domain as root domain
(e.g., e164.example.com) and provide ENUM services below this root
domain. Whether access is restricited or not, and the policy for
provisioning of DNS records, is defined by the holder of that domain.
An example of a private ENUM tree with restricted access is the 3GPP
ENUM tree (e164enum.net).
Darilion & Tschofenig Expires August 21, 2008 [Page 5]
Internet-Draft E.164 Ownership using ENUM February 2008
Use cases are similar to before, except that the owner of the root
domain can decide who is allowed to use the ENUM tree. Furthermore,
private ENUM trees can be used if user ENUM is not available in the
respective country (for example by using nrenum.net).
The main drawback of this proposal is the fact that public ENUM does
not enjoy a lot of deployment (see http://enumdata.org/). This
document is, however, particularly useful for environments that make
use of public ENUM. Private and infrastructure ENUM only need SIP
Identity alike mechanisms when interacting with the "external" world
since they follow a sort of wallet garden model with a chain-of-
trust. There is non-neglectable deployment incentive challenge. As
such, this proposal will live or die with the ability to come up with
a lucrative deployment story.
4. Authentication Service Behavior
The authentication service behavior proposed in this document is
almost identical to the authentication service described in [3].
Thus, the authentication service behavior is identical to the
description in Section 5 of [3] when TEL URIs are used with the
following addition for step 4:
When a TEL URI scheme is used in context of SIP Identity then the
'Identity-Info' header field does not contain a URI pointing to a
certificate but rather contains the DomainKeys selector and the
ENOM root domain since the procedure described in Section 5 allows
the verifier to determine the location of the public key
associated with a particular TEL URI.
The mechanism for storing a public key in the DNS is re-used from
DKIM [4].
5. Verifier Behavior
When a verifier receives a SIP message containing an Identity-Info
header, it may inspect the signature to verify the identity of the
sender of the message. Typically, the results of a verification are
provided as input to an authorization process which is outside the
scope of this document. If an Identity-Info header is not present in
a request, and one is required by either local policy (for example,
based on a per-sending-domain policy, or a per-sending-user policy)
or remote policy, then 'Use Identity Header' response code MUST be
sent.
Darilion & Tschofenig Expires August 21, 2008 [Page 6]
Internet-Draft E.164 Ownership using ENUM February 2008
The steps executed by the verifier are outlined in Section 6 of [3]
with the exception that step 1 is different primarily because SIP
Identity relies on certificates whereas this document stores public
keys in the DNS. The following paragraph replaces the text the text
in Section 6/step 1 of [3]. This document does not make use of the
'Unsupported Certificate' and the 'Bad Identity-Info' response code.
Step 1:
The verifier MUST obtain the ENUM root domain from the Identity-
Info header and apply local policies to find out if the specified
ENUM root domain points to a trusted ENUM tree. If the specified
ENUM tree is not trusted, the verifier has to cancel the signature
verification and the message MUST be treated like an unsigned
message.
Step 2:
The verifier MUST acquire the public key for the signing domain.
This document suggests to store the public key in the DNS.
This document is only applicable for the usage of tel URIs in the
From: header. When the tel URI contains a 'global-number', i.e.,
a phone number in E.164 format starting with the '+' sign, the
domain for retrieving the public key will be constructed according
to the following algorithm:
1. remove the 'visual-separators' and all parameters from the tel
URI
2. remove the leading "+" sign
3. put dots (".") between each digit
4. reverse the order of the digits
5. append the ENUM root domain (for example ".e164.arpa") to the
end
6. prepend the string "._domainkey."
7. prepend the selector
For example, given the tel URI
"tel:+43-1-5056416-36;mobile=false", the selector "2008-02" and
the root domain ".e164.arpa", the domain under which the public
key is stored is:
2008-02._domainkey.6.3.6.1.4.6.5.0.5.1.3.4.e164.arpa
Non global-numbers cannot be stored in ENUM and thus they cannot
be used in the From: header when signing the request by the
authentication service.
Darilion & Tschofenig Expires August 21, 2008 [Page 7]
Internet-Draft E.164 Ownership using ENUM February 2008
The 'Unable to retrieve Public Key from DNS' response code is used
when an error in fetching the public key from the DNS occurs.
6. Considerations for User Agent
There are no additional considerations beyond those described in
Section 8 of [3].
7. Considerations for Proxy Servers
There are no additional considerations beyond those described in
Section 8 of [3].
8. Examples
The following message exchange highlights the interaction.
Darilion & Tschofenig Expires August 21, 2008 [Page 8]
Internet-Draft E.164 Ownership using ENUM February 2008
Calling Auth. Called
UA Service proxies Verifier UA
------- ------- -------- -------- ------ --------
| | | | | ^
| INVITE | | | | |
|--------->| | | | |
| | | | | |
| (signs request) | | | |
| | | | | | Steps
|100 | INVITE | | | | largely
|<---------|--------->| | | | based
| | | | | | on normal
| |100 | INVITE | | | RFC4474
| |<---------|--------->| | | processing
| | | | | |
| | |100 | | |
| | |<---------| | V
| | | | | ----------
| | | | | ^
| | | (retrieve | |
| | | public key | This
| | | from DNS) | document
| | | | | |
| | | | | v
| | | | | --------
| | | (validates | ^
| | | signature) | | steps
| | | | | | which are
| | | | | | part of
| | | | | | normal
| | | | INVITE | | RFC4474
| | | |--------->| V
| | | | | ----------
| | | | |
| | | | |display
| | | | |E.164 number
Figure 1: Example Exchange
9. Caching and Scalability
When the verifier needs to determine the public key of a specific
E.164 number then it needs to perform a DNS lookup. This lookup
might be cached in the DNS but the lookup is specific for a certain
E.164 number and not for a domain. The verifier may cache the public
key corresponding to a particular E.164 number but there is no
Darilion & Tschofenig Expires August 21, 2008 [Page 9]
Internet-Draft E.164 Ownership using ENUM February 2008
guarantee that the same key will be used by any other E.164 number.
Furthermore, a specific E.164 number may have multiple public keys
associated with it based on the selector concept that is useful when
revocating keys or when delegating the signing process.
10. Privacy Considerations
The mechanism presented in this draft is compatible with the standard
SIP practices for privacy, described in RFC 3323 [9] and also with
the privacy considerations of RFC 4474 [3].
11. Security Considerations
The mechanism described in this document has different authorization
properties than RFC 4474 [3]. A SIP message (including the
'Identity' and the 'Identity-Info' header) with an E.164 number in
the From: header field has the following property (if successfully
processed by the verifier):
The entity that uses the private key for creating the SIP Identity
header is authorized to attach the corresponding public key to the
ENUM database of the respective E.164 number used during the
lookup.
When using PKI infrastructure, the signature verifier trusts the
certificate authority, which attest the identity of the certificate
holder. Using ENUM, the signature verifier has to trust the ENUM
registry and the registrars. The ENUM registrar typically has to
validate that the user who tries to register an ENUM domain is the
number right holder. The validation methods usually will be
different between user ENUM (the validation methods can be approved
by official buddies) and private ENUM trees.
It is important to note that with this proposal public keys are
essentially for individual users rather than for the entire domain.
As such, the authentication service needs to have access to the
private keys corresponding to the respective public key. Note,
however, that there is nothing special about these key pairs as such
and there is no relationship to other (long-term) asymmetric
credentials potentially possessed by the user. They are rather used
only as a technical vehicle to accomplished the ownership requirement
described in this document.
This proposal also does not address the case where a call originates
in the PSTN and enters the Internet via provider that does not
possess the private key corresponding to the public key stored with
Darilion & Tschofenig Expires August 21, 2008 [Page 10]
Internet-Draft E.164 Ownership using ENUM February 2008
the E.164 number in the ENUM tree. This is, in some sense, desired
since Caller-ID spoofing is very easy in the PSTN and is difficult to
differentiate from a call that enters the Internet through a provider
that has no relationship with the calling party. This asymmetric
routing scenario is, however, quite common today.
Additional security considerations can be found in [10].
12. IANA Considerations
This document requests IANA to register a new response code.
12.1. TBD 'Unable to retrieve Public Key from DNS' Response Code
This document registers a new SIP response code, which is described
in Section 5. It is used when a verifier tries to retrieve the
public key from the DNS and does not succeed and the DNS lookup
fails. This response code is defined by the following information,
which has been added to the method and response-code sub-registry
under http://www.iana.org/assignments/sip-parameters.
Response Code Number: TBD
Default Reason Phrase: Unable to retrieve Public Key from DNS
12.2. URI Scheme Registration
[Editor's Note: A future version of this document may register a URI
scheme that allows the SIP 'Identity-Info' header to be reused in
order to convey parameters from the authentication service to the
verifier.]
13. Acknowledgments
We would like to thank Dan Wing for raising the problems associated
with E.164 number-usage in SIP Identity and the discussion during
writing of this draft. Further we would like to thank Alexander
Mayrhofer for his ideas in [draft-mayrhofer-enum-domainkeys-00].
We would also like to thank Kai Fischer, John Elwell, Hadriel Kaplan,
David Schwartz, and Jon Peterson for their off-list comments.
14. References
Darilion & Tschofenig Expires August 21, 2008 [Page 11]
Internet-Draft E.164 Ownership using ENUM February 2008
14.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] 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.
[3] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[4] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and
M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures",
RFC 4871, May 2007.
[5] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
[6] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
14.2. Informative References
[7] Elwell, J., "SIP E.164 Problem Statement",
draft-elwell-sip-e164-problem-statement-00 (work in progress),
February 2008.
[8] ITU-T, "The international public telecommunication numbering
plan", Recommendation E.164, May 1997.
[9] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[10] Schwartz, D., "E.164 Ownership Problem Statement",
Std draft-schwartz-sip-e164-ownership-00.txt, Feb 2008.
Darilion & Tschofenig Expires August 21, 2008 [Page 12]
Internet-Draft E.164 Ownership using ENUM February 2008
Authors' Addresses
Klaus Darilion
enum.at GmbH
Karlsplatz 1/9
Wien A-1010
Austria
Phone: +43 1 5056416 36
Email: klaus.darilion@enum.at
URI: http://www.enum.at/
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.com
Darilion & Tschofenig Expires August 21, 2008 [Page 13]
Internet-Draft E.164 Ownership using ENUM February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Darilion & Tschofenig Expires August 21, 2008 [Page 14]