One document matched: draft-mayrhofer-enum-domainkeys-00.txt
ENUM -- Telephone Number Mapping A. Mayrhofer
Working Group enum.at
Internet-Draft February 22, 2006
Expires: August 26, 2006
Telephone Number Mapping and Domain Keys as a Distributed Identity
Infrastructure
draft-mayrhofer-enum-domainkeys-00
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 26, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document creates a decentralized indentity infrastructure by
combining technology from E.164 Number Mapping (ENUM) and DomainKeys
Identified Mail (DKIM). This infrastructure uses E.164 numbers as
identities, ENUM DNS for key distribution, and leverages the trust
relations from ENUM validation to actual messages signed by the
number holder.
Mayrhofer Expires August 26, 2006 [Page 1]
Internet-Draft ENUM and Domain Keys February 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Infrastructure Components . . . . . . . . . . . . . . . . . . 3
2.1. The Identifier . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Identifier Domain Mapping . . . . . . . . . . . . . . . . 4
2.3. Key Management and Storage . . . . . . . . . . . . . . . . 4
2.4. Signing Actions . . . . . . . . . . . . . . . . . . . . . 5
2.5. Verification Actions . . . . . . . . . . . . . . . . . . . 5
3. Application scenarios . . . . . . . . . . . . . . . . . . . . 5
3.1. Peer to Peer Communications . . . . . . . . . . . . . . . 6
3.2. Trusted Caller ID . . . . . . . . . . . . . . . . . . . . 6
3.3. Spam over Internet Telephony (SPIT) Prevention . . . . . . 7
3.4. Secure Real Time Transport Protocol (SRTP) key exchange . 7
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Mayrhofer Expires August 26, 2006 [Page 2]
Internet-Draft ENUM and Domain Keys February 2006
1. Introduction
E.164 numbers [2] serve as well known addressing elements for
communication on various networks (voice calls, instant text
messages, video calls). Besides their primary addressing role, those
numbers also serve as identities for the owner, and are sometimes
even part of an authentication process.
E.164 Number Mapping (ENUM) [1] associates each E.164 number with a
DNS domain. Since ENUM validation [3] ensures that only the holder
of a certain E.164 number can aquire and control the respective ENUM
domain, the contents of such a domain is under the descretion of the
number holder.
DomainKeys Identified Mail (DKIM) FIXME-ref describes a mechanism
where owners of a domain publish the public part of a cryptographic
key in the DNS and sign messages with the private part. Entities
receiving suche messages verify the signature by discovering and
fetching the public key directly from the DNS without prior contact
with the sender.
By combining selected parts of ENUM and DKIM technology, any owner of
a phone number can potentially convey the identity his number
reflects to any other entity on the Internet in a decentralized way.
For the purpose of the following sections, the proposed
infrastructure is abbreviated as "ENDI" (ENUM Distributed Identity).
Please note that this document is currently just aimed at conveying
the idea - most parts of the proposed infrastructure need to be
described in more detail in upcoming versions of this draft.
2. Infrastructure Components
The proposed identity infrastructure "ENDI" uses only certain parts
of the ENUM and DKIM specifications. Most of the definitions in DKIM
focus on email, and do not apply to the infrastructure described.
ENUM, on the other hand, has a lot of features which are not
neccessary for the service described, but would make implementations
fully incompatible with existing DKIM tools. The following section
describes the components used in this approach.
2.1. The Identifier
The identifier used to convey an identity MUST be a fully qualified
E.164 number, including the leading "plus" sign. Numbers which are
not valid E.164 numbers MUST NOT be used as an identifier, as well as
numbers which are local to a certain network, and may therefore
Mayrhofer Expires August 26, 2006 [Page 3]
Internet-Draft ENUM and Domain Keys February 2006
introduce collisions in the identity space (they wouldn't work
anyways). ENDI applications SHOULD NOT attempt to convert such local
numbers into E.164 space, since guessing identities is always bad.
Clients MAY, however, apply "dial plan" style normalizations as well
as whitespace stripping, removal of non-numeric characters to the
input string. Applications SHOULD give feedback to the user about
normalizations applied.
Example of an identifier string (office identity of the author):
+431505641634
2.2. Identifier Domain Mapping
The mapping from an identifier to a domain name is to be performed as
described in RFC3761, section 2.1 ("Application Unique String"), and
section 2.4 ("Valid databases"). However, processing should be
stopped at list item 4. of RFC3761, section 2.4 since ENDI is not a
full Dynamic Delegation Discovery System (DDDS) application. The
final output of this step is a full qualified domain name, as
outlined there.
Example of the domain mapping (for the identifier listed above):
4.3.6.1.4.6.5.0.5.1.3.4.e164.arpa
A client application SHOULD NOT confuse the user by displaying the
domain - it SHOULD always display/request the identifier instead.
2.3. Key Management and Storage
Key management is to be done according to section 3.6 of
draft-ietf-dkim-base-00. The identifier domain mapping described
above is to be used as "domain".
In contrary to to a full DDDS application, a "TXT" type resource
record is proposed, which makes the propsed infrastructure compatible
with existing Domainkeys toolkits. The "selector" mechanism as
described in draft-ietf-dkim-base-00, section 3.1 may be used for the
reasons outlined in said document, especially if different
applications sharing a single E.164 number each require a seperate
key.
Example of public key (stored for the identifier above):
@ORIGIN _domainkey.4.3.6.1.4.6.5.0.5.1.3.4.e164.arpa.
@ IN TXT "p=MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAM2r/
A7PvMlW7p6imaNlwjwTRp/
Mayrhofer Expires August 26, 2006 [Page 4]
Internet-Draft ENUM and Domain Keys February 2006
xvIsbbSpLF7fyBMv2PWdy0dCwrkEpfLQGfKS6P+cLPSw6OTjlgt3IK7Jr5KcCAwEAAQ"
Note: line breaks introduced due to format limits
2.4. Signing Actions
Generally, signing follows the principles outlined in
draft-ietf-dkim-base-00. However, there are a few differences to due
to the facts that only a subset of DKIM is used, and this subset is
potentially applied to protocols different from email:
o Relation between Users and Keys: Most DKIM domains will be shared
by many users of the same domain, which means that the private key
part will be shared by many users as well. Contrary to that, it
is envisaged that the domain mapped identifier proposed in this
document is not shared (unless the underlying E.164 number is
shared as well), and therefore one ENDI key pair per user is set
up.
o Signing and key availability: In DKIM, signing is expected to
occur on the outbound SMTP server rather than in the user's
application itself, which makes the entity operating the server
the Signer. In ENDI signing is expected to take place in the
application itself, which makes the Signer identical to the User,
and in turn qualifies the protocol for end user authentication.
o Since the Signer needs access to the private key DKIM requires the
key to be present on the outbound SMTP server. Since ENDI
applications sign messages by themselves the private key needs to
reside in the application.
2.5. Verification Actions
Again, verification principles follow the principles of DKIM.
However, the actual implementation of the verification steps is
specific to the application, as is the interpretation of the
verification result. Section 3 lists a few examples.
Verification steps:
1. Extracting the signature
2. Extracting the identity
3. Fetching the public key
4. Verifying the signature
5. Interpreting the results
3. Application scenarios
The following section tries to outline a few potential applications
of ENDI. Obviously, the examples should be treated as rough
conceptual sketches rather than finished protocols.
Mayrhofer Expires August 26, 2006 [Page 5]
Internet-Draft ENUM and Domain Keys February 2006
3.1. Peer to Peer Communications
Many communication services are set up in the way of distributed peer
to peer networking - most often with the drawback that for addressing
and authentication a centralized server is still necessary in most
cases. Even if no authentication is required, the mechanism for
assigning unique identifiers to each user still mandates a central
component.
Some P2P applications leverage existing addressing schemes as like as
email addresses, and attach new credentials to those addresses.
However, a centralized component caching/managing those credentials
is still required.
By using the proposed architecture, P2P networks could replace those
central functions in the following way:
o Identity allocation: The user uses his existing E.164 number as
his identifier. This solves the problem of unique identifiers,
since E.164 numbers can only be assigned once, and the allocation
mechanism is already in place. In addition, phone numbers are
well established addressing elements - using them to be reachable
on just another network requires no new address book entry.
o Authentication: Without any prior knowledge, any node in the P2P
network is able to verify an authentication request signed by the
owner of the E.164 number. Credential verification by a central
component is replaced by an ad hoc verification of signed
messages.
o Usability: Re-using a well known identifier (the E.164 number) for
just another service without risking of giving any more
information is good. Other users will easily accomodate to this
identifier, since they are already using it on other networks to
contact the user (eg. on the Public Switched Telephony Network).
3.2. Trusted Caller ID
Voice over IP (VoIP) gateways need to signal a calling party number
for calls which traverse from the Internet to the PSTN. Even if the
call itself would be free (as free Beer), authentication is required
to ensure that the caller ID presented resembles the number allocated
to the user. A gateway which does not have access to respective data
sources would be unable to provide a trusted caller ID to the PSTN.
If, however, the gateway receives (and sucessfully verifies) a call
request signed by ENDI technology, it can safely assume that the
E.164 number presented is under control of the calling party (because
the public key used for verification is under the control of the
E.164 number holder). Subsequently, it can safely signal the E.164
number presented as calling party ID to the PSTN.
Mayrhofer Expires August 26, 2006 [Page 6]
Internet-Draft ENUM and Domain Keys February 2006
3.3. Spam over Internet Telephony (SPIT) Prevention
It is safe to assume that once open VoIP endpoint deployment take up,
spammers will closely follow. One concept of fighting SPIT is
whitelisting, however, for SIP this approach has the same drawbacks
as email whitelisting - spammers regularly use addresses which are
likely to be already whitelisted.
By using an E.164 number as identifier for the whitelist (probably
auto-generated from the user's address book) together with a
mechanism to verify the E.164 number of a caller, SPIT potential
could be greatly reduced. ENDI would provide a mechanism to securely
convey the E.164 identity of a caller.
3.4. Secure Real Time Transport Protocol (SRTP) key exchange
SRTP provides encryption of the media stream to VoIP applications.
Before encrypted communication takes places, keys have to be
exchanged. If the call parties know the E.164 numbers of the other
party from signaling, they could use the ENDI public keys for media
encryption instead
4. IANA considerations
There are no considerations for IANA (yet)
5. Security Considerations
Obviously, a protocol dealing with cryptographic keys,
authentication/authorization has to be analyzed in depth for security
concerns. Most of the security concerns from DKIM apply to this
protocol as well, and with no doubt more issues will come up due to
the combination with another technology.
[ analysis required here ]
6. Acknowledgements
This specification contains information that was derived from the
original DKIM and ENUM documents.
The Author wishes to thank Klaus Darilion for his ideas.
7. References
Mayrhofer Expires August 26, 2006 [Page 7]
Internet-Draft ENUM and Domain Keys February 2006
7.1. Normative References
[1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
[2] ITU-T, "The international public telecommunication numbe ring
plan", Recommendation E.164, May 1997.
7.2. Informative References
[3] Mayrhofer, A. and B. Hoeneisen, "ENUM Validation Architecture",
draft-ietf-enum-validation-arch-01 (work in progress),
February 2006.
Mayrhofer Expires August 26, 2006 [Page 8]
Internet-Draft ENUM and Domain Keys February 2006
Author's Address
Alexander Mayrhofer
enum.at GmbH
Karlsplatz 1/9
Wien A-1010
Austria
Phone: +43 1 5056416 34
Email: alexander.mayrhofer@enum.at
URI: http://www.enum.at/
Mayrhofer Expires August 26, 2006 [Page 9]
Internet-Draft ENUM and Domain Keys 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.
Mayrhofer Expires August 26, 2006 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 12:06:41 |