Internet DRAFT - draft-chen-p2psip-psc
draft-chen-p2psip-psc
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]
