Internet DRAFT - draft-yan-sip-cave-requirements
draft-yan-sip-cave-requirements
SIP Working Group B. Yan
Internet-Draft Z. Zhang
Expires: April 19, 2006 F. Zhang
China Unicom
Q. Li
Beihang University
H. Deng
Hitachi (China)
October 16, 2005
MMD CAVE Support Requirements
draft-yan-sip-cave-requirements-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 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes why there is a need to support CAVE
authentication in Multi-Media Domain, and outlines the requirements
of the potential solution to this problem.
Yan, et al. Expires April 19, 2006 [Page 1]
Internet-Draft CAVE Requirements October 2005
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Yan, et al. Expires April 19, 2006 [Page 2]
Internet-Draft CAVE Requirements October 2005
1. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, [RFC2119].
CDMA
Code Division Multiple Access
CAVE
Cellular Authentication and Voice Encryption. Cellular Message
Encryption Algorithm used in the cdma system
R-UIM
Removable User Identify Module. The UIM is an application
traditionally resident on smart cards distributed by cdma
operators. R-UIM indicates that UIM itself could be removed from
the cdma device.
UE
User Equipment. Equivalent to Mobile Station
MMD
Multi-media Domain defined in 3GPP2 which is almost equivalent to
IMS in 3GPP
2. Introduction
3GPP2 MMD provides an IP-based session control capability based on
the SIP [RFC3261] protocol. MMD can be used to enable services such
as push to talk, instant messaging, presence and conferencing.
However at present time, it is not possible for devices equipped with
legacy cards to access 3GPP2 MMD-based services under current
standards and technology. Specially, there will be a need to deploy
some MMD-based services which can be accessed reusing the current
CDMA 1X R-UIM devices.
This document outlines some of the reasons why such a problem is
essential to ensure the applicability and for wider deployment, and
also describes the requirements of the solution to this problem.
Yan, et al. Expires April 19, 2006 [Page 3]
Internet-Draft CAVE Requirements October 2005
3. Background
As the second-largest CDMA operator, China Unicom held about 30
millions subscribers equipped with CDMA 1X R-UIM at the end of last
year. If reusing the legacy R-UIM devices, MMD services will not
support more than the 30 millions subccribers.
Recently operators would like to provide MMD-basde services to its
subscribers. Except that existing R-UIM cards only support CAVE
authentication method, which means it is not possible to process AKA
authentication vectors in current devices because of the lack of 3G
secret key K. Since mobile equipment must be firstly authenticated to
the network before accessing the services provided by the MMD, that
means current subscribers with existing R-UIM cards will not be able
to use these services based on SIP protocol.
However, replacing with new R-UIM cards for large subscribers to
support AKA will be difficult and expensive since more than 30
millions subscribers have to change their R-UIM card if they want to
subscribe IMS service. Such kind of additional time and expense
needed work should be avoided by operators. Also that reusing
current R-UIM card would be more convenient and preferable to
operators.
Therefore, an alternative authentication scheme which supports CAVE
would be useful for legacy CDMA 1X R-UIM devices. Such athentication
scheme should provide adequate level of security, as well as to
minimize the possible impacts on existing entities, as described in
following section.
4. Requirements
There is a need to provide an alternative authentication scheme to
legacy CDMA 1X R-UIM devices which supports CAVE algorithm in
addition to [RFC3329]. Therefore with the support of such
authentication scheme, legacy devices with CAVE capability can be
authenticated by SIP server (S-CSCF) in the MMD. The following are
the requirements to such authentication scheme in general:
o Such authentication mechanism should not bring massive impact to
existing entities.
o Any MMD security mechanisms should be such that impacts on
existing entities.
o The mechanism should be quick to implement so that the window of
opportunity for the MMD security solution is not missed.
Yan, et al. Expires April 19, 2006 [Page 4]
Internet-Draft CAVE Requirements October 2005
5. Security Considerations
The security requirements for the new authentication scheme is to
ensure adequate level of security. It should provide an adequate
level of security to protect against the most significant security
threats that will exist in MMD implementations. As a guide, the
strength of subscriber authentication should be comparable to the
level of authentication provided for existing chargeable services in
mobile networks.
6. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] 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.
[RFC3329] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T.
Haukka, "Security Mechanism Agreement for the Session
Initiation Protocol (SIP)", RFC 3329, January 2003.
Yan, et al. Expires April 19, 2006 [Page 5]
Internet-Draft CAVE Requirements October 2005
Authors' Addresses
Bifeng Yan
China Unicom
No. 133A Xidan North Street
Xicheng District
Beijing 100032
China
Email: yanbf@chinaunicom.com.cn
Zhijiang Zhang
China Unicom
No. 133A Xidan North Street
Xicheng District
Beijing 100032
China
Email: zhangzhj@chinaunicom.com.cn
Fan Zhang
China Unicom
No. 133A Xidan North Street
Xicheng District
Beijing 100032
China
Email: zhangf@chinaunicom.com.cn
Qin Li
Beihang University
No. 35 Xueyuan Road
Haidian District
Beijing 100083
China
Phone: +86 10 8231 6342
Email: liqin@cse.buaa.edu.cn
Yan, et al. Expires April 19, 2006 [Page 6]
Internet-Draft CAVE Requirements October 2005
Hui Deng
Hitachi (China)
Beijing Fortune Bldg. 1701
5 Dong San Huan Bei-Lu
Chao Yang District
Beijing 100004
China
Email: hdeng@hitachi.cn
Yan, et al. Expires April 19, 2006 [Page 7]
Internet-Draft CAVE Requirements October 2005
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 (2005). 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.
Yan, et al. Expires April 19, 2006 [Page 8]
