[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

                                                                 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]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/