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]