Internet DRAFT - draft-abiri-cpfp
draft-abiri-cpfp
A. Biri
Internet-Draft Magnet Consortium
Intended status: Informational
Expires: January 1, 2009 June 30, 2008
Certified Pan Formation Protocol
draft-abiri-cpfp-00
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 January 1, 2009.
Biri Expires January 1, 2009 [Page 1]
Internet-Draft Certified Pan Formation Protocol June 2008
Abstract
This draft introduces the Certified PN Formation Protocol (CPFP)
based on the personal public key infrastructure (personal PKI)
concept. CPFP employs Elliptic Curve Cryptography (ECC) techniques
by using ECDH, ECDSA and STS protocols and provides feasible
solutions for key revocation and transitive imprinting.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. CPFP-stage 1: Initialization and imprinting with PNCA and getting
certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. CPFP-Stage 2: Using STS to derive shared keys. . . . . . . . . .7
5. PNCA resilience . . . . . . . . . . . . . . . . . . . . . . . .9
6 Key revocation mechanism . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .11
8. Security Considerations . . . . . . . . . . . . . . . . . . . .12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . .13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .14
Intellectual Property and Copyright Statements . . . . . . . . . .15
Biri Expires January 1, 2009 [Page 2]
Internet-Draft Certified Pan Formation Protocol June 2008
1. Introduction
Security and privacy is one of the major concerns in the development
and acceptance of personal networks (PN) technologies. The PN
consists of a dynamic collection of personal nodes and devices around
a user (Private Personal Area Network or P-PAN), and remote personal
nodes and devices in different clusters (home cluster, office
cluster, car cluster) that are connected to each other through the
infrastructure or ad hoc networks. In the PN networks, classical
network security mechanisms based on the conventional public key
infrastructure (PKI) and certificate authorities (CA), cannot be
directly applied PN networks because lack of permanent access to a
common trusted third party. Our protocol named as Certified PN
Formation Protocol (CPFP), is based on the personal public key
infrastructure (Personal PKI) in which instead of global certificates
issued by a trusted third party, the local certificates issued by PN
certificate authority (PNCA) will be applied. In CPFP, all the PN
communication units share the PNCA s signature public key as the PN
root key and use the certificate issued by it to authenticate each
others and establish the pairwise keys. To provide the light-weight
security solutions, we decided to adopt Elliptic Curve Cryptography
(ECC) as our main public key technology. ECC allows us to obtain the
same level of security with smaller key sizes which are operable for
all PN resource scarce components.
Biri Expires January 1, 2009 [Page 3]
Internet-Draft Certified Pan Formation Protocol June 2008
2. Conventions
The key words "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, RFC 2119
[1].
Biri Expires January 1, 2009 [Page 4]
Internet-Draft Certified Pan Formation Protocol June 2008
3. CPFP-stage 1: Initialization and imprinting with PNCA and getting
certificate
The PN security architecture is based on bilateral trust
relationships between personal devices established during the
certified PN formation protocol (CPFP). The first stage of CPFP is
initializing and imprinting with PN certificate authority (PNCA) and
getting certificate, therefore the PN security depends, from a
fundamental point of view, on the security of the imprinting
procedure, which is subject to following assumptions:
1. The user is in full control of the imprinting procedure, i.e. the
user determines when and how a new device will be imprinted with
PNCA and taken as a member of the PN
2. The personal devices share two different communication interfaces
with PNCA:
A. Proximity Authenticated Channel (PAC); and
B. Usual wireless communication channel over which the actual
data between the devices and PNCA is transferred
A proximity authenticated channel is a communication interface
between two devices, which is authenticated by physical means by the
user, who is in close proximity of the device and can identify a
device. We distinguish between two types of PAC channels, private
and public PAC channels, with respect to the level of security the
PAC channel can provide. A private PAC channel provides
authenticity, integrity and confidentiality, while a public PAC
channels provide authenticity and integrity only. User starts CPFP
by choosing one device, with keypad and display, as the PN
certificate authority (PNCA) and imprints (pairs) all the PN
components with it. PNCA initializes itself with generating the
public and private ECDSA signature key and other PN components
initialize themselves with generating their long term ECDH public and
private keys. Generating the keys either signature ECDSA or long
term ECDH, is based on a fixed elliptic curve with standardized
coefficients. PNCA and PN components exchange their public keys
(signature and long term) over the insecure wireless channel and user
authenticates it by using the complementary channel (private or
public PAC). With getting an authenticated copy of the PNCA
signature public key and PN components long term public key, PNCA is
able to securely issue certificate for components and components are
able to correctly verify the issued certificates. Based on the used
PAC (private or public) there are two different procedures for this
stage of protocol:
Biri Expires January 1, 2009 [Page 5]
Internet-Draft Certified Pan Formation Protocol June 2008
1. In this version of protocol after exchanging the signature and
long term public keys over insecure wireless channel, PNCA
generates a key K, suitable for use in a shared MAC function with
PN components, and computes a MAC function of exchanged public
keys using the key K.
2. In this version of protocol, after exchanging signature and long
term public keys over insecure wireless channel, PNCA generates a
hash of the exchanged public keys and sends it to pairing device
over public PAC. Pairing device calculates the hash of the
exchanged public keys, compares the result with the received date
over the public PAC and shows accepted or rejected signal to user
who updates the PNCA.
3. Using digital certificates is an established method to generate
trusted identities in network communications. A certificate
provides a binding between identity information and a public key;
a key pair can subsequently be used for key exchange to set up
secured communications and for digital signatures, to validate
transactions. In CPFP certificates are used to bind the
identities of PN components to their long term ECDH public key.
This ensures that once the certificates are issued by PNCA and
while they are not revoked or expired, the identities and their
long term ECDH public keys are trustable by all PN components.
Biri Expires January 1, 2009 [Page 6]
Internet-Draft Certified Pan Formation Protocol June 2008
4. CPFP-Stage 2 : Using STS to derive shared keys
In the last stage of CPFP, we are using the STS key agreement
protocol to establish a shared secret key between the PN components
which already have certificates on their long term public keys from
the PNCA. PNCA itself participates in this stage to establish shared
pair wise keys with other PN components by generating its long term
ECDH pair keys and issuing self signed certificate on its long term
ECDH public key. The Station-to-Station (STS) protocol is a
cryptographic protocol which ensures the key agreement procedure. It
is based on Diffie-Hellman that provides mutual key and entity
authentication. Not only it protects the established key from an
attacker, but also this protocol uses no timestamps and provides
perfect forward secrecy. It also entails two-way explicit key
confirmation, making it an authenticated key agreement with key
confirmation (AKC) protocol.In the following, D = (q,FR, S,a,b,
P,n,h) are elliptic curve domain parameters, KDF is a key derivation
function, MAC is a message authentication code algorithm such as
HMAC, and SIGN is the signature generation algorithm for a signature
scheme. We suggest that user choose a user friendly name (UFN)
including PN name and/or owner name for each component during the
imprinting with PNCA and use these UFNs as their identities. We are
using the (STS) protocol with the following protocol messages:
AB: RA , Cert_A
A selects kA belongs to [1, n-1], computes a public key RA = kAP, its
private key rA and then sends its UFN, RA and Cert_A to B.
B-->A: Cert_B, RB, SB = SIGNB(RB, RA, UFNA), tB = MACk1 (RB, RA,
UFNA)
o B performs an embedded public key validation of RA
o B selects kB belongs to [1,n-1] and computes its public key RB and
private key rB
o Compute Z = hkBRA and verify that Z is different from the infinity
o KDF(xZ)-->(k1,k2) where xZ is the x-coordinate of Z.
o Computes SB = SIGNB(RB, RA, UFNA) and tB =MACk1 (RB, RA, UFNA).
o Send Cert_B, RB, sB, tB to A.
A --> B: SA = SIGNA(RA, RB, UFNB), tA =MACk (RA, RB, UFNB)
Biri Expires January 1, 2009 [Page 7]
Internet-Draft Certified Pan Formation Protocol June 2008
o A performs an embedded public key validation of RB
o It computes Z = hkARB and verify that Z is different from the
infinity.
o KDF(xZ)-->(k1,k2),where xZ is the x-coordinate of Z.
o It verifies that SB is B s signature on the message (RB, RA,
UFNA).
o It computes t =MACk1 (RB , RA, UFNA) and verify that t = tB.
o Compute Sa = SIGNA(RA, RB, UFNB) and tA =MACk1 (RA, RB, UFNB).
o It sends sA, tA to B.
B does the following: Verify that SA is A s signature on the message
(RA, RB, UFNB). Compute t =MACk1 (RA, RB, UFNB) and verify that t =
tA. The session key is k2.
The shared secret is Z = hkAkBP, which is derived from the ephemeral
(one-time) public keys RA and RB. Multiplication by h and the check
that Z is different from the infinity has order n and therefore is
in. Successful verification of the signatures SA = SIGNA(RA, RB,
UFNB) and Sb = SIGNB(RB , RA, UFNB) convinces each entity of the
identity of the other entity (since the signing entity can be
identified by its public signing key), that the communications have
not been tampered with (assuming that the signature scheme is
secure), and that the other entity knows the identity of the entity
with which it is communicating (since this identity is included in
the signed message). Successful verification of the authentication
tags tA and tB convinces each entity that he other entity has indeed
computed the shared secret Z (since computing the tags requires
knowledge of k1 and therefore also of Z).
Biri Expires January 1, 2009 [Page 8]
Internet-Draft Certified Pan Formation Protocol June 2008
5. PNCA resilience
The fact that the PNCA plays a central role in the PN s key
management brings the problem of resilience. If the PNCA is broken
or out of reach, basic operations as inviting new devices, revoking
keys, etc. are no longer possible. Thus, practical requirements ask
for fallback solutions. In the currently discussed approach, we use
the fact that in principle the difference between the PNCA and an
ordinary node is that the PNCA knows the secret key SKPNCA what is
mandatory for the operations mentioned above. This means in
particular that if other devices share this knowledge, they can take
over the part of the PNCA if necessary. To solve these seemingly
concurring demands of storing the key SKPNCA on different devices
without increasing the risk, the idea is to store only the encryption
of SKPNCA, such that only the user is able to decrypt it.
Biri Expires January 1, 2009 [Page 9]
Internet-Draft Certified Pan Formation Protocol June 2008
6. Key revocation mechanism
Like in a normal PKI, the PNCA is not only in charge of inviting
nodes into the PN but also to revoke them in the case of need. Since
the user is the centre of the PN architecture, only the user herself
should be able to decide if a node has to be revoked or not. In
particular, there should be no automatic revocation without user
interaction.
Biri Expires January 1, 2009 [Page 10]
Internet-Draft Certified Pan Formation Protocol June 2008
7. Acknowledgements
We would like to acknowledge all the partners of Magnet consortium
espacially A. Ahmad, H. Afifi, S.Mirzadehdehkordi and F.Armknecht.
Biri Expires January 1, 2009 [Page 11]
Internet-Draft Certified Pan Formation Protocol June 2008
8. Security Considerations
All drafts are required to have a security considerations section.
See RFC 3552 [RFC3552] for a guide.
Biri Expires January 1, 2009 [Page 12]
Internet-Draft Certified Pan Formation Protocol June 2008
9. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
Biri Expires January 1, 2009 [Page 13]
Internet-Draft Certified Pan Formation Protocol June 2008
Author's Address
Aroua Biri
Magnet Consortium, Telecom SudParis
9, rue Charles Fourier
Evry 91001
FR
Email: aroua.biri@int-edu.eu
Biri Expires January 1, 2009 [Page 14]
Internet-Draft Certified Pan Formation Protocol June 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
Biri Expires January 1, 2009 [Page 15]
