Network Working Group Shuyi Chen Internet-Draft Feng Gao Intended status: Informational ZTE Corporation Expires: April 17, 2011 Chongwei Sun Xiaofeng Qiu Chunhong Zhang MINE lab,Beijing University of Posts and Telecommunication October 14, 2010 Public Security Channel(PSC): An Alternative Key Management Mode in RELOAD draft-chen-p2psip-psc-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 17, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Chen, et al. Expires April 17, 2011 [Page 1] Internet-Draft Public Security Channel(PSC) October 2010 Abstract REsource LOcation And Discovery (RELOAD) is a peer-to-peer (P2P) signaling protocol for use on the Internet. This document proposes a security extension for RELOAD. A new data transmission security model was introduced in this draft. This model was based on a central Key Management Server (KMS). Security communications among multi peers can be achieved with PSC(Public Security Channel). PSC can also get performance improvement compared with TLS/DTLS method in RELAOD draft. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . .. . . . 3 3. Design Considerations . . . . . . . . . . . . . . . . . . . . . 3 3.1 security issues in RELOADN . . . . . . . . . . . . . . . . 4 3.2 design motivation . . . . . . . . . . . . . . . . . . . . . 4 4. A New Mode: PSC . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1 overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2 set up a PSC. . . . . . . . . . . . . . . . . . . . . . . . 6 4.2.1 Bootstrap phase . . . . . . . . . . . . . . . . . . . 6 4.2.2 Running phase . . . . . . . . . . . . . . . . . . . . 7 4.3 join a PSC. . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3.1 Join a PSC actively . . . . . . . . . . . . . . . . . 8 4.3.2 Join a PSC passively . . . . . . . . . . . . . . . . 9 4.4 Refresh a PSC . . . . . . . . . . . . . . . . . . . . . . . 9 4.5 Destroy a PSC. . . . . . . . . . . . . . . . . . . . . . . 10 5. Key management. . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1 Key generation . . . . . . . . . . . . . . . . . . . . . . 11 5.2 Key distribution . . . . . . . . . . . . . . . . . . . . . 11 5.3 Key refreshment. . . . . . . . . . . . . . . . . . . . . . 11 6. Communication protocol of PSC . . . . . . . . . . . . . . . . . 11 6.1 KMS and certificate server . . . . . . . . . . . . . . . . 11 6.2 KMS and peer . . . . . . . . . . . . . . . . . . . . . . . 11 6.3 communication between KMSs . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1 Normative References . . . . . . . . . . . . . . . . . . 12 9.2 Informative References . . . . . . . . . . . . . . . . . 12 Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . 13 chen, et al. Expires April 17, 2011 [Page 2] Internet-Draft Public Security Channel(PSC) October 2010 1. Introduction This document defines PSC (Public Security Channel), a key management mode for RELOAD[I-D draft-ietf-p2psip-base-07]. PSC provides an alternative service for security P2P overlay communications. With this service, P2P network allows peers to organize large-scale group communications in virtual channels. Compared with TLS/DTLS mode mentioned in RELOAD draft, PSC mode achieves less expense and low latency. This method can also fulfill the manageability, controllability requirements in some networks. 2. Terminology PSC: Public Security Channel, used to secure data transmission in P2P network. KMS: Key Management Server, used to assign PSC ID and key for P2P node. P2P Node: node in P2P network. Node exchange information after encrypting them use PSC key. 3. Design Considerations As mentioned in [I-D draft-mattsson-mikey-ticket-02], key management systems are divided into three items: (1) negotiation and exchange directly (e.g. Diffie-Hellman based schemes) (2) pre-distribution of user credentials (e.g. shared secrets/certificates) (3) trusted Key Management Service Key management modes in RELOAD specification are all variants of the first two alternatives. Detailed description will be showed in 3.1. A key management service is often preferred in large-scale systems. Because with Key Management Service , there is no need for pre-distribution of credentials or secret materials. When a peer need to establish security communication with other peers, it send request message to KMS. KMS handle this request message. Handle process was consists of certificate verification and access control. KMS will send security channel related materials back to the peer if peer's request was accepted. Chen, et al. Expires April 17, 2011 [Page 3] Internet-Draft Public Security Channel(PSC) October 2010 3.1 security issues in RELOAD RELOAD's security model is based on each node having one or more public key certificates. These certificates can be signed by a central certificate server or node itself. Credentials in the certificates were used for security communications of RELOAD message. Communication security in RELOAD was at three levels: (1) Connection Level: Connections between peers are secured with TLS or DTLS. (2) Message Level: Each RELOAD message must be signed. (3) Object Level: Stored objects must be signed by the storing peer. 3.2 design motivation As mentioned in 3.1, message communication security in RELOAD was resolved in two levels: connection level and message level. TLS and DTLS were used on connection level between nodes. Nodes in P2P network can exchange messages on TLS or DTLS channel directly. This method was flexible and effective in small-scale network. But there are some imperfections to use TLS/DTLS in RELOAD. (1) TLS/DTLS was designed for Client/Server mode. So it is not convenient to use TLS/DTLS in P2P overlay network. for example, the position of nodes is equal reciprocally in RELOAD, so mutual certification will be needed frequently. But mutual certification in TLS/DTLS is complex and expensive. (2) TLS/DTLS is not suitable for different situations. Variant security strategies were needed in large scale networks. TLS/DTLS can not sustain many security strategies. Only encryption level and cipher spec can be changed in TLS/DTLS. Complicated security strategy, such as key refreshment according to network situation, can not be deployed on TLS/DTLS. (3) In order to set up TLS/DTLS, PKI infrastructure should be deployed in the network. This is unrealistic in some environments. (4) The security of nodes in RELOAD was guaranteed to a certain extent. Especially when strict access control was implemented. So there is no need to verify each other before security link was established sometimes. But verification between nodes was mandatory in TLS/DTLS. It is unreasonable. In a word, it is necessary to introduce a new key management mechanism into RELOAD. A key management server will be specially designed in this mechanism. Key management server is responsible for key generation, distribution and refreshment. This server should also cooperate with other existing facilities in RELOAD. Chen, et al. Expires April 17, 2011 [Page 4] Internet-Draft Public Security Channel(PSC) October 2010 4. A New Mode: PSC 4.1 overview Public Security Channel(PSC) was introduced to resolve message security problems. PSC is an essential complement of TLS/DTLS solution. In PSC, P2P nodes exchange messages after encrypting them using PSC key. The PSC method include KMS and P2P node. The function of KMS and P2P node was interpreted in Terminology section. The position of PSC in RELOAD architecture is as follows. PSC link Message Transport Component and Forwarding & Link Management Component. In original RELOAD structure, message can be only supported by overlay link layer. After adding PSC in, P2P overlay network can accomplish security channel establishment without overlay link layer. +-------------+ +-------------+ |SIP Usage | | XMPP Usage | +-------------+ +-------------+ -------------------------------------------------------------message -------------------------------------------------------------API +----------------+ +---------+ | Message | | Storage | +------+ Transport |...........| | | |-------------+ +---------+ | PSC | . . . | | . . . | | . . . | | . +---------------------+ | | . | Topology Plugin | | | . +---------------------+ | | . . | | . . | | . . | +---------------------------+ | | Forwarding&Link | +----| Management | +---------------------------+ -------------------------------------------------------------overlay -------------------------------------------------------------link API +---------+ +--------+ |TLS | |DTLS | +---------+ +--------+ ... interoperation between modules Figure 1 Network Architecture Chen, et al. Expires April 17, 2011 [Page 5] Internet-Draft Public Security Channel(PSC) October 2010 4.2 set up a PSC There are two ways to set up a PSC. A node can accomplish the setting up process either in the bootstrap phase or in the normal running phase. 4.2.1 Bootstrap phase In the bootstrap phase, the peer acquires an configuration file either by downloading online or other offline methods. Several KMSs server address will be included in the configuration file. The peer sends InitializeRequest message to one of the KMSs. Message contents are: peer certificate, peer ID, encryption algorithms peer support, whether to join a established PSC, whether to establish a new PSC. (1) peer certificate: help KMS to verify the peer. (2) peer ID: identify peer in PSC. (3) encryption algorithm peer support: used for PSC key generation. (4) whether to join a established PSC: notify KMS whether to join a established PSC. (5) PSC ID(optional): used with "whether to join a established PSC", confirm the PSC ID which peer want to join in. (6) whether to establish a new PSC: notify KMS whether to establish a PSC for peer. KMS receive the InitializeRequest message and resolve it. KMS check up the user certificate, in this progress, KMS may need communicate with certificate server. KMS decide whether user can establish a PSC and whether can join a established PSC. Then KMS send a InitializeResponse message back to user. Message contents are: PSC related materials(PSC ID and PSC key materials). Peer A KMS | | | | | InitializeRequest | |------------------------>| | | | InitializeResponse | |<------------------------| | | | | Figure 2 PSC initialization progress Chen, et al. Expires April 17, 2011 [Page 6] Internet-Draft Public Security Channel(PSC) October 2010 4.2.2 Running phase We need to establish a PSC after joining P2P overlay in some conditions. There may be some peers want to communication in a group or some secret messages transported between P2P nodes. These requirements are temporary during running phase of P2P network. One peer should be chosen out to be PSC constructor. This peer collect essential information for PSC constructing and send PscEstablishRequest message to KMS. This message includes: peer ID, PSC access control information. peer ID: identify peer on KMS, help KMS to get peer's certificate for further manipulation. PSC access control information: help KMS to accomplish access control function. KMS receives PscEstablishRequest message and resolve it. First, KMS verify peer's certificate to examine whether this user can construct a PSC. Certificate was stored on KMS during bootstrap phase. If verification was went through, KMS accomplish several actions which include choosing encryption algorithm, generating keys, adding PSC member ID into PSC data structure, etc. KMS send PscEstablishResponse message back to construct peer and notify other PSC members through PscRefresh message. Construct user and other PSC members receive these messages and communicate in PSC. PSC constructor Other PSC member KMS | | | | PscEstablishRequest | | |-----------------------|-------------------------->| | | | | | PscEstablishRequest | |<----------------------|---------------------------| | | | | | PscRefresh | | |<--------------------------| | | | | | | Figure 3 PSC establish progress Chen, et al. Expires April 17, 2011 [Page 7] Internet-Draft Public Security Channel(PSC) October 2010 4.3 join a PSC There are two ways to join a PSC: active and passive. Nodes can join a PSC by sending a joining request to KMS actively or invited by a PSC constructor. 4.3.1 Join a PSC actively When node A want to communicate with node B in a PSC. Node A should get PSC ID of node B. Then node A send a PscJoinRequest message to KMS. PSC ID was included in this request message. KMS receive this message and query security information of node B's PSC. If node A was authorized to access to node B's PSC. KMS return correct response message to node A. Encryption related materials will also be sent to node A through PscRefresh message. If node A's request can not be accepted, PscJoinRequest message will be sent to node A for rejection. If there are not clear information for A's access to B's PSC. KMS should send a query message to B for affirmance. B receive this query message and demand whether A was allowed to this PSC. Node A KMS Node B | | | | | | | PscJoinRequest | | |---------------------->| | | | | | | Query | | |..........................>| | | | | | Response | | |<..........................| | | | | PscJoinResponse | | |<----------------------| | | | | | PscRefresh | | |<......................| | | | | | | | Figure 4 join a PSC actively Chen, et al. Expires April 17, 2011 [Page 8] Internet-Draft Public Security Channel(PSC) October 2010 4.3.2 Join a PSC passively When node A has set up a PSC and asked node B to join this PSC. Node A sends a PscInviteIntializeRequest message to KMS. KMS check the validity of this message and demand whether Node B can be invited to node A's PSC. If invite request was accepted, KMS send PscInviteRequest message to Node B. Node B decide whether to join this PSC and send PscInviteResponse message to KMS. KMS send PscInviteIntializeResponse back to Node A. PscInviteIntializeResponse message was used for notifying node A the invite result. At the same time, KMS modify the security information of PSC and send PscRefresh message to group members of PSC. Node A KMS Node B | | | | PscInviteInitializeRequest | | |----------------------------->| | | | | | | PscInviteRequest | | |-------------------------->| | | | | | PscInviteRequest | | |<--------------------------| | | | | PscInviteInitializeResponse | | |<-----------------------------| | | | | | | | Figure 5 join a PSC passively 4.4 Refresh a PSC PSC should be refreshed in some situations. These situations include: (1) Timer expired. PSC should be refreshed periodically for security consideration. (2) some PSC member leave a PSC. Peer which leave P2P network normally should notify KMS its left. Peer can also detect other peer's abnormal left and inform KMS. KMS receive this information and confirm its facticity. (3) some nodes join into a PSC. Peers join a PSC must communicate with KMS first, so KMS can apperceive peer's join easily. When above situations happen, KMS send PscRefresh message to PSC members. PSC ID and PSC key materials were included in this message. Chen, et al. Expires April 17, 2011 [Page 9] Internet-Draft Public Security Channel(PSC) October 2010 KMS Peer A Peer B Peer N | | | | | PscRefresh | | | |--------------->| | | | | | | | PscRefresh | | | |----------------|---------------->| | | | | | | | | | | PscRefresh | | | |----------------|-----------------|-------------------->| | | | | | | | | Figure 6 refresh a PSC 4.5 Destroy a PSC When security communication finished, PSC construct peer send a PscDestroyRequest to KMS. PSC ID was included in this message. KMS resolve this message as follows: check this peer's certificate to decide whether this peer has the right to destroy a PSC. If peer passed-through authentication, KMS send PscRefresh message to PSC members. PscRefresh was used for notifying them the destruction of PSC. Then KMS delete the information of PSC. PSC members stop communicating through PSC after receiving PscRefresh message. KMS send PscDestroyResponse message back to PSC construct peer at last. Peer A KMS Peer B Peer C | | | | | PscDestoryRequest | | | |-------------------->| | | | | | | | | PscRefresh | | | |---------------->| | | | | | | | PscRefresh | | | |-----------------|----------------->| | | | | | PscDestoryResponse | | | |<--------------------| | | | | | | Figure 7 destroy a PSC Chen, et al. Expires April 17, 2011 [Page 10] Internet-Draft Public Security Channel(PSC) October 2010 5. Key management Key management is the core function in PSC. Key management function can be divided into three scenarios: key generation, key distribution and key refreshment. 5.1 Key generation When a peer send a initialize message(set up a PSC in bootstrap phase)or PscEstablishRequest message(set up a PSC in running phase) for PSC construction, KMS should generate PSC key. Just as TLS, PSC constructor send supporting encryption scheme to KMS. KMS decide which encryption scheme was used. Key generation should also be run when PSC refresh event happen. 5.2 Key distribution PSC key should be encapsulated into a PscRefresh message which was used for key distribution. This message was encrypted by a master key. Master key can be get from PSC constructor's public certificate. 5.3 Key refreshment PSC'S key should be refreshed according some situations. These situations has been showed in Section 4.4. 6. Communication protocol of PSC 6.1 KMS and certificate server When KMS receive initialize message or construct message from peer, KMS should communicate to certificate server for certificate verification. Certificate server can help KMS to validate the certificate of peer. Peer's public key was included in its certificate, KMS get peer's public key after certificate verification. 6.2 KMS and peer Peer send PSC related messages to KMS for PSC establishment, refreshment and destruction. KMS accomplish corresponding work after receiving these messages. Chen, et al. Expires April 17, 2011 [Page 11] Internet-Draft Public Security Channel(PSC) October 2010 6.3 communication between KMSs In order to defend DoS attack to KMS and achieve high availability, multi KMSs should be deployed. KMS exchange PSC related information (PSC ID, PSC member list, PSC key) between each other. 7. Security Considerations See details in section 3. 8. IANA Considerations This document proposes a new Key Management Mode, which may need IANA considerations to define PSC(Public Security Channel) in RELOAD protocol. Todo: Need complete this section further. 9. References 9.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2 Informative References [I-D draft-ietf-p2psip-base-07] C. Jennings, "Resource Location And Discovery(RELOAD) Base Protocol", Internet-Draft, February 17, 2010. [I-D draft-mattsson-mikey-ticket-02] J. Mattsson, "MIKEY-TICKET: An Additional Mode of Key Distribution in Multimedia Internet KEYing(MIKEY)" Internet-Draft, March 8, 2010. Chen, et al. Expires April 17, 2011 [Page 12] Internet-Draft Public Security Channel(PSC) October 2010 Authors' Addresses Shuyi Chen ZTE Corpoporation 17/F, ZTE Plaza, No.19, East HuaYuan Road Haidian District, Beijing P.R.China, 100191 Tel:+86-10-82963667 Fax:+86-10-59932043 Email:chen.shuyi@zte.com.cn Feng Gao ZTE Corpoporation 17/F, ZTE Plaza, No.19, East HuaYuan Road Haidian District, Beijing P.R.China, 100191 Email:gao.feng1@zte.com.cn Chongwei Sun Mobile lIfe and New mEdia Lab, BUPT. P.O. Box 92, No.10, Xitucheng Road BeiJing, Haidian District 100876 P.R.China Email: sunchw@gmail.com Xiaofeng Qiu Mobile lIfe and New mEdia Lab, BUPT. P.O. Box 92, No.10, Xitucheng Road BeiJing, Haidian District 100876 P.R.China Email: qiuxiaofeng@gmail.com Chunhong Zhang Mobile lIfe and New mEdia Lab, BUPT. P.O. Box 92, No.10, Xitucheng Road BeiJing, Haidian District 100876 P.R.China Email: zhangch.bupt.001@gmail.com Chen, et al. Expires April 17, 2011 [Page 13]