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]