ENUM Working Group Hui. Chen
Internet-Draft Feng. Wang
Intended status: Informational Xiaodong. Lee
Expires: April 11, 2007 Liang. Chen
CNNIC,China
October 8, 2006
Authentication Scheme for Public ENUM Applications
draft-chenh-enum-app-auth-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 April 11, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Chen, et al. Expires April 11, 2007 [Page 1]
Internet-Draft auth for ENUM app October 2006
Abstract
ENUM possesses the feature of E.164 number authenticity, therefore by
being carried with initiation signal of application services, ENUM
number can be used to identify originer.
The service initiation signal includes sender's (originer's) un-
encrypted ENUM number and encrypted ENUM number, or some other
information needed by specific applications, then receiver decrypts
encrypted ENUM number and compares decrypted result with the un-
encrypted ENUM number to authenticate the originer's identity.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. ENUM Implementation Framework . . . . . . . . . . . . . . . . 4
2.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Application . . . . . . . . . . . . . . . . . . . . . . . 5
3. Authentication Scheme for ENUM Application . . . . . . . . . . 6
3.1. Function modules . . . . . . . . . . . . . . . . . . . . . 6
3.2. Key Creation . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Key Management . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Encryption and Decryption . . . . . . . . . . . . . . . . 7
3.5. Process of Authentication Scheme . . . . . . . . . . . . . 7
3.6. ENUM Authentication Requirements . . . . . . . . . . . . . 8
4. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 9
5. Additional Consideration . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Chen, et al. Expires April 11, 2007 [Page 2]
Internet-Draft auth for ENUM app October 2006
1. Introduction
ENUM [1] defines a mechanism to set up the relationship between E.164
number [2] and Internet URIs. Thus, ENUM can be considered as a
bridge to associate virtual Internet with users' real communication
services.
So far, validation of ENUM registration has been focused on, but
authentication of ENUM applications has seldom been discussed. Most
of ENUM applications are based on Internet, but the non-central, out-
of-control and short-of-administration features of Internet make the
authentication for ENUM applications difficult.
Although the security and privacy of user terminals can be got by
agreement or contract for private ENUM or carrier ENUM, but it is
rather difficult to get identity authentication for public users.
This document just provides a kind of authentication scheme combined
with ENUM number for public ENUM applications.
Chen, et al. Expires April 11, 2007 [Page 3]
Internet-Draft auth for ENUM app October 2006
2. ENUM Implementation Framework
There are four main function modules in ENUM implementation:
registration, resolution, authentication and application. The
interactions among these modules are shown in Figure 1.
+----------+
|Resolution|
+----------+
(2)/ ^
/ \(1)
v \
+-----------+ +------------+
|Application| |Registration|
+-----------+ +------------+
^ /
\(4) /(3)
\ v
+--------------+
|Authentication|
+--------------+
Figure 1
Interaction 1 is between registration and resolution, registration
transports the registration information to resolution, which is used
to create zone file. Interaction 2 is between resolution and
application, application gets ENUM NAPTR records from resolution
server by ENUM DNS queries.
Interaction 3 and interaction 4 are the key points of this document.
Interaction 3 is the path for authentication system to get
authentication information such as the required certificates or
secret keys from registration process. Interaction 4 provides
authentication for application, authentication center stores
authentication information and responds the authentication queries.
2.1. Registration
The description of concrete entities of registration is not included
in this document. It can be referred to another draft, such as "ENUM
Validation Architecture" [3].
Registration has two aspects, one is to record real information of
registrants, the other is to record the ENUM services corresponding
to ENUM number/domain name. A registrant should register to be an
ENUM user first, then he has the further right to register ENUM
number/domain name and the mapped ENUM services.
Chen, et al. Expires April 11, 2007 [Page 4]
Internet-Draft auth for ENUM app October 2006
The process of ENUM number/domain name registration needs to interact
with authentication center. The important event is to produce and
assign the certificates and secret keys. When a registrant registers
an ENUM number/domain through a registrar, the registrant gets or
submits a unique pair of secret key corresponding with the ENUM
number (described in Section 3.2). The private key is given to the
registrant, and the public key is stored at authentication center.
2.2. Authentication
Authentication in the implementation includes equipment
authentication and user authentication. Equipment authentication is
discussed in SPEERMINT working group.
User authentication can be divided into user access authentication
and user service authentication. User access authentication can be
solved by application server in the private realm. If the service is
intra-realm, user service authentication is out of this document.
And this solution is for inter-realm user service.
Authentication center is to insure the user's possessing right of the
ENUM number, authorize the user's using right of some services, and
provide response for ENUM number authentication query.
The actual authentication method is possible to be different
according to special entity, provided data sources, options of
subscribe and local policy. Authentication center needs to store
information, including ENUM account, user information, ENUM number,
corresponding public key, and etc.
2.3. Application
ENUM application system often consists of ENUM enabled equipments,
main function of which is to provide different ENUM services, such as
IP telephone, e-Fax, Email, presence service, web service, SMS, EMS,
MMS.
In order to improve the security and privacy of ENUM service,
authentication function can be introduced into ENUM applications.
When the originer initiates a service, the initiation message carries
both originer's un-encrypted ENUM number and encrypted ENUM number
field with sender's public key. The receiver acquires originer's
public key from the authentication center according to the originer's
un-encrypted ENUM number, decrypts the encrypted ENUM number field
and judges the originer's identity, then decides whether to accept
this request.
Chen, et al. Expires April 11, 2007 [Page 5]
Internet-Draft auth for ENUM app October 2006
3. Authentication Scheme for ENUM Application
In order to let the receiver validate originer's identity, user
terminals of ENUM application should insert the originer's ENUM
number into service initiation signals. But if only un-encrypted
ENUM number is carried, it will be easy to be tampered and the hacker
can fabricate someone to initiate ENUM application. So this paper
gives out an authentication scheme to hold both the un-encrypted ENUM
number for querying public key and encrypted ENUM number to ensure
the identity of originer.
During the process, ENUM number is the association of ENUM
application and ENUM user's real information.
3.1. Function modules
+--------------------------------------+
| +--------------+ +--------------+ |
+----------+ | | Key Creation | |Key Management| | +----------+
|Encryption| | +--------------+ +--------------+ | |Decryption|
+----------+ | +--------------+ | +----------+
| |Authentication| |
| +--------------+ |
+--------------------------------------+
Figure 2
3.2. Key Creation
Key pair is used to ensure the security and integrity of ENUM number.
Arithmetic of key creation is out of this document.
Key creation generally happens during ENUM registration. Here
provides two kinds of key creation for ENUM application:
1) ENUM user can create a pair of key by himself, then he keeps the
private key and at the same time submits the public key to key
management module.
2) Registrar creates a pair of key for a ENUM number, and gives the
private key to user for preservation, also submits the public key to
key management module.
3.3. Key Management
Key management includes examination of key validity, key store, and
etc. Private key store method can be chosen by user itself. This
Chen, et al. Expires April 11, 2007 [Page 6]
Internet-Draft auth for ENUM app October 2006
section mainly focuses on key validity and public key store method.
Any key pair has a period of validity. If beyond validity period,
the key pair needs to be recreated. When the new key pair is
created, there is default validity period for it. Furthermore, ENUM
user can set its preferred validity period in order to guarantee the
security of the key pair.
Public keys of key pairs are kept in authentication server.
Authentication server should be run by a third neutral organization.
Generally, radius server can act as authentication server, or ENUM
resolution server can serve too [4].
3.4. Encryption and Decryption
The data fields which the originer sends out for authentication is as
following:
Field 1/send Field 2/send Field 1/rec Field 2/rec
+--------------+-------------+ +--------------+-------------+
| un-encrypted | encrypted | ---> | un-encrypted | decrypted |
| ENUM number | ENUM number | ---> | ENUM number | ENUM number |
+--------------+-------------+ +--------------+-------------+
Figure 3
The originer terminal can provide the user entrance of its ENUM
number. The terminal software encrypts ENUM number with originer's
private key and gets "Field 2/send", forms data "Field 1/send" and
"Field 2/send", then the data fields will be inserted into initiation
signal.
The receiver terminal draws out the un-encrypted ENUM number, and
acquires public key of this ENUM number from authentication server.
The terminal software decrypted "Field 2/send" with the public key
and gets "Field 2/rec", then compares the "Field 1/rec" and "Field
2/rec". If "Field 1/rec" is the same with "Field 2/rec",then the
originer's ENUM number can be considered real and the corresponding
ENUM user's information is trustable.
3.5. Process of Authentication Scheme
Use the solution to protect authentication, privacy and security of
application. The whole process is as following:
1) During the registration, registrar sends ENUM number,
corresponding public key and optional ENUM user's information to the
Chen, et al. Expires April 11, 2007 [Page 7]
Internet-Draft auth for ENUM app October 2006
third authentication center for store.
2) Before initiating service, the originer requires that only
authorized receiver who gets the sender's public key can examine the
ENUM information in the message.
3) When initiating service, the originer writes its own un-encrypted
ENUM number and encrypted ENUM number with private key into extended
field of communication protocol message.
4) While the receiver incepts service, it fetchs originer's public
key from the third authentication center, and decrypts the encrypted
field.
5) The receiver compares the un-encrypted ENUM number field and
decrypted ENUM number field. If consensus, the originer validity can
be confirmed. Moreover, the receiver can queries for originer's more
information according to the ENUM number.
3.6. ENUM Authentication Requirements
There are some requirements for ENUM application authentication as
following:
1) ENUM registrant is coincident with ENUM number possesser
2) ENUM number/domain name is associated with the concrete
application
3) Users have the requirements of privacy, security and integrity
4) Service protocol has extension feature, and ENUM authentication
information can be added into the protocol data package
5) The application terminals should interact with the third
authentication center
6) The addition of ENUM new services will not affect the existing
architecture
Chen, et al. Expires April 11, 2007 [Page 8]
Internet-Draft auth for ENUM app October 2006
4. Example Scenarios
Here gives an example of extended SIP/VoIP communication. Figure 4
is a simple framework of SIP/VoIP system.
+--------+ +--------+
|Server A|----------->|Server B|
+--------+ +--------+
^ \
/ +--------------+ \
/ ___|Authentication|___ V
+--------+ / | Server | \ +--------+
| User | / +--------------+ \ | User |
| Agent A|/ \| Agent B|
+--------+ +--------+
Figure 4
The extended field of SIP protocol is used. Supposed that there is
an identity field for ENUM authentication, which carries originer's
both un-encrypted ENUM number and encrypted ENUM number. Figure 5
shows the working flow of authentication solution for SIP/VoIP
application.
Chen, et al. Expires April 11, 2007 [Page 9]
Internet-Draft auth for ENUM app October 2006
Working Flow
UA A(sender) Server A Authentication Server B UA B(receiver)
Center
| | | | |
encrypts ENUM msg | | | |
with pricate key | | | |
| | | | |
|SIP INVITE msg| | | |
|------------->| SIP INVITE msg | |
| |--------------------------->| SIP INVITE msg |
| | | |--------------->|
| | | | |
| | | ask for pubilc key of UA A |
| | |<-----------------------------|
| | | return public key of UA A |
| | |----------------------------->|
| | | | |
| | | |decrypts SIP msg with
| | | | UA A's public key
| | | | |
| | | (optionally) |
| | | ask for information of UA A |
| | |<-----------------------------|
| | | return the detail of UA A |
| | |----------------------------->|
| | dual-peer communication | |
|<==========================================================>|
| | | | |
Figure 5
Chen, et al. Expires April 11, 2007 [Page 10]
Internet-Draft auth for ENUM app October 2006
5. Additional Consideration
Besides the above SIP/VoIP application, this authentication scheme
can also be applied in other applications. It is only needed to use
certain free field or extended field for carring the authentication
ENUM number information.
Chen, et al. Expires April 11, 2007 [Page 11]
Internet-Draft auth for ENUM app October 2006
6. Security Considerations
The security based on encryption of authentication is required in
this ENUM authentication scheme, so the user terminal or application
server needs to support encrypting message, but the specification
doesn't limit which encryption protocol is used.
In order to maintain a consistent approach, unique and specialized
security requirements common for the majority of peering
relationships, should be standardized within the IETF.
Chen, et al. Expires April 11, 2007 [Page 12]
Internet-Draft auth for ENUM app October 2006
7. References
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] "The international public telecommunication numbering plan",
Recommendation E.164, May 1997.
7.2. Informative References
[3] Mayrhofer, A. and B. Hoeneisen, "ENUM Validation Architecture",
draft-ietf-enum-validation-arch-03 (work in progress), Jun 20,
2006.
[4] Mayrhofer, A., "Telephone Number Mapping and Domain Keys as a
Distributed Identity Infrastructure",
draft-mayrhofer-enum-domainkeys-00 (work in progress), February
2006.
Chen, et al. Expires April 11, 2007 [Page 13]
Internet-Draft auth for ENUM app October 2006
Authors' Addresses
Hui,Chen
CNNIC,China
4 South 4th Street,Zhongguancun,Haidian District
Beijing 100080
China
Email: chenhui@cnnic.cn
Feng,Wang
CNNIC,China
4 South 4th Street,Zhongguancun,Haidian District
Beijing 100080
China
Email: fengw@cnnic.cn
Xiaodong,Lee
CNNIC,China
4 South 4th Street,Zhongguancun,Haidian District
Beijing 100080
China
Email: lee@cnnic.cn
Chen,Liang
CNNIC,China
4 South 4th Street,Zhongguancun,Haidian District
Beijing 100080
China
Email: chenliang@cnnic.cn
Chen, et al. Expires April 11, 2007 [Page 14]
Internet-Draft auth for ENUM app October 2006
Full 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.
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.
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).
Chen, et al. Expires April 11, 2007 [Page 15]