GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5409

Network Working Group L. Martin Request for Comments: 5409 Voltage Security Category: Informational M. Schertler

                                                                 Axway
                                                          January 2009
Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption
      Algorithms with the Cryptographic Message Syntax (CMS)

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (c) 2009 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.

Abstract

 This document describes the conventions for using the Boneh-Franklin
 (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in
 the Cryptographic Message Syntax (CMS) to encrypt content-encryption
 keys.  Object identifiers and the convention for encoding a
 recipient's identity are also defined.

Martin & Schertler Informational [Page 1] RFC 5409 Using IBE with CMS January 2009

Table of Contents

 1. Introduction ....................................................2
    1.1. Terminology ................................................3
    1.2. IBE Overview ...............................................3
 2. Using Identity-Based Encryption .................................3
 3. Key Encryption Algorithm Identifiers ............................6
 4. Processing by the Sender ........................................7
 5. Processing by the Receiver ......................................7
 6. ASN.1 Module ....................................................8
 7. Security Considerations .........................................9
    7.1. Attacks outside the Scope of This Document .................9
    7.2. Attacks within the Scope of This Document .................10
    7.3. Attacks to Which the Protocols Defined in This Document
         Are Susceptible............................................11
 8. References .....................................................12
    8.1. Normative References ......................................12
    8.2. Informative References ....................................12

1. Introduction

 This document defines the way to use the Boneh-Franklin [IBCS] and
 Boneh-Boyen [IBCS] identity-based encryption (IBE) public-key
 algorithms in the Cryptographic Message Syntax (CMS) [CMS].  IBE is a
 public-key technology for encrypting content-encryption keys (CEKs)
 that can be implemented within the framework of the CMS: the
 recipient's identity is incorporated into the EnvelopedData CMS
 content type using the OtherRecipientInfo CHOICE in the RecipientInfo
 field as defined in Section 6.2.5 of [CMS].  This document does not
 describe the implementation of the BF and BB1 algorithms, which are
 described in detail in [IBCS].
 IBE algorithms are a type of public-key cryptographic algorithm in
 which the public key is calculated directly from a user's identity
 instead of being generated randomly.  This requires a different set
 of steps for encryption and decryption than would be used with other
 public-key algorithms, and these steps are defined in Sections 4 and
 5 of this document, respectively.
 This document also defines the object identifiers and syntax of the
 object that is used to define the identity of a message recipient.
 CMS values and identity objects are defined using ASN.1 [ASN1].

Martin & Schertler Informational [Page 2] RFC 5409 Using IBE with CMS January 2009

1.1. Terminology

 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 RFC 2119 [KEYWORDS].

1.2. IBE Overview

 In addition to the client components that are described in this
 document, the following additional components are required for a
 complete IBE messaging system.
    o  A Private-Key Generator (PKG).  The PKG contains the
       cryptographic material, known as a master secret, for
       generating an individual's IBE private key.  A PKG accepts an
       IBE user's private key request and, after successfully
       authenticating them in some way, returns their IBE private key.
    o  A Public Parameter Server (PPS).  IBE system parameters include
       publicly sharable cryptographic material, known as IBE public
       parameters, and policy information for the PKG.  A PPS provides
       a well-known location for distribution of IBE public parameters
       and policy information for the IBE PKG.
 The interactions of senders and receivers of IBE-encrypted messages
 are described in [IBE].  All communications between users of an IBE
 system and the PPS or PKG MUST be protected using TLS [TLS] as
 described in [IBE].  This provides confidentiality and integrity of
 all information that is delivered to users as well as authentication
 of the PPS and PKG.

2. Using Identity-Based Encryption

 To use IBE, the ori field in RecipientInfo MUST be used.  The fields
 are set as follows: oriType is set to ibeORIType; oriValue is set to
 ibeORIValue.
 These fields have the following meanings:
 ibeORIType defines the object identifier (OID) that indicates that
 the subsequent ibeORIValue is the information necessary to decrypt
 the message using IBE.  This field MUST be set to the following:
 ibeORIType OBJECT IDENTIFIER ::= {
   joint-iso-itu(2) country(16) us(840)
   organization(1) identicrypt(114334)
   ibcs(1) cms(4) ori-oid(1) version(1)
 }

Martin & Schertler Informational [Page 3] RFC 5409 Using IBE with CMS January 2009

 ibeORIValue defines the identity that was used in the IBE algorithm
 to encrypt the CEK.  This is an IBERecipientInfo type, which is
 defined as follows:
 IBERecipientInfo ::= SEQUENCE {
   cmsVersion         INTEGER { v3(3) },
   keyFetchMethod     OBJECT IDENTIFIER,
   recipientIdentity  IBEIdentityInfo,
   serverInfo         SEQUENCE SIZE (1..MAX) OF
     OIDValuePairs OPTIONAL,
   encryptedKey       EncryptedKey
 }
 The fields of IBERecipientInfo MUST be set as follows.
 The cmsVersion MUST be set to 3.
 The keyFetchMethod is the OID that defines the method of retrieving
 the private key that the recipient MUST use.  This SHOULD be set to
 uriPPSOID [IBE], which is defined to be the following:
 uriPPSOID OBJECT IDENTIFIER ::= {
   joint-iso-itu-t(2) country(16) us(840)
   organization(1) identicrypt(114334)
   pps-schemas(3) ic-schemas(1) pps-uri(1) version(1)
 }
 The recipientIdentity is the data that the sender used to calculate
 the IBE public key that the sender used to encrypt the content-
 encryption key.  This recipientIdentity is used to calculate IBE
 public and private keys as described in [IBCS].  This MUST be a DER-
 encoded [DER] IBEIdentityInfo type [IBE], which is defined as
 follows:
 IBEIdentityInfo ::= SEQUENCE {
   district        IA5String,
   serial          INTEGER,
   identityType    OBJECT IDENTIFIER,
   identityData    OCTET STRING
 }
 The identityType defines the format that is used to encode the
 information that defines the identity of the recipient.  This MUST be
 set to cmsIdentityOID to indicate that identityData contains an
 EmailIdentityData type.  The value of cmsIdentityOID is the
 following:

Martin & Schertler Informational [Page 4] RFC 5409 Using IBE with CMS January 2009

 cmsIdentityOID OBJECT IDENTIFIER ::= {
   joint-iso-itu-t(2) country(16) us(840)
   organization(1) identicrypt(114334)
   keyschemas(2) icschemas(1) email(1) version(1)
 }
 The identityData MUST be an EmailIdentityData type, which is defined
 as follows:
 EmailIdentityData ::= SEQUENCE {
   rfc822Name   IA5String,
   time         GeneralizedTime
 }
 The rfc822Name field is the email address of the recipient in the
 format defined in Section 4.2.1.6 of [PKIX] for the rfc822Name
 subjectAltName variant.  Rules for encoding Internet mail addresses
 that include internationalized domain names are specified in Section
 7.5 of [PKIX].
 The value of the time field is the UTC time after which the sender
 wants to let the recipient decrypt the message, so it may be called
 the "not-before" time.  This is usually set to the time when the
 message is encrypted, but MAY be set to a future time.  The value of
 "time" MUST be expressed in Greenwich Mean Time (Zulu), MUST include
 seconds (i.e., times are always YYYYMMDDHHMMSSZ), even where the
 number of seconds is equal to zero, and MUST be expressed to the
 nearest second.
 The sender of an IBE-encrypted message may want to express this time
 rounded to a time interval to create a key lifetime.  A key lifetime
 reduces the number of IBE private keys that a recipient needs to
 retrieve, but still forces the IBE user to periodically re-
 authenticate.  Based on the time interval chosen a recipient would
 only have to retrieve a new IBE key once during the interval.  To do
 this, follow the steps below.  Let "time-interval" be the number of
 seconds in this larger time interval.
    1. Find the GeneralizedTime for the not-before value.
    2. Convert this GeneralizedTime into the number of seconds since
       January 1, 1970.  Call this "total-time".
    3. Calculate reduced-time =
       (floor (total-time / time-interval)) * time-interval.
    4. Convert reduced-time to a GeneralizedTime to get the not-before
       "time" value.
 An example of this algorithm for computing a one-week time interval
 is as follows.

Martin & Schertler Informational [Page 5] RFC 5409 Using IBE with CMS January 2009

    1. Suppose that the GeneralizedTime is 20020401000000Z.
    2. Then the total-time is 1017612000.
    3. A time-interval of 1 week is 604800 seconds.
       So the reduced-time = (floor (1017612000 / 604800)) * 604800 =
       1017273600.
    4. This gives the GeneralizedTime form of the reduced-time of
       20020328000000Z.
 When issuing IBE private keys, a PKG SHOULD NOT issue them too far
 into the future.  This restriction is to prevent an adversary who
 obtains an IBE user's authentication credentials from requesting
 private keys far into the future and therefore negating the periodic
 IBE user re-authentication that key lifetime provides.  For example,
 if a one-week period is chosen for the key lifetime, then IBE private
 keys should not be issued more than one week in advance.  Otherwise,
 once an adversary gains access to the PKG via the stolen IBE user
 credentials, they can request all future keys and negate the IBE user
 authentication restraints in place.
 The serverInfo is an optional sequence of OID-value pairs that are
 defined to be the following:
 OIDValuePairs ::= SEQUENCE {
   fieldID     OBJECT IDENTIFIER,
   fieldData   OCTET STRING
 }
 These can be used to convey any other information that might be used
 by a PKG.  Examples of such information could include the user
 interface that the recipient will experience.  Differences in the
 user interface could include localization information or commercial
 branding information.  A client MUST ignore any part of serverInfo
 that it is unable to process.
 The encryptedKey is the result of encrypting the CEK with an IBE
 algorithm using recipientIdentity as the IBE public key.

3. Key Encryption Algorithm Identifiers

 The BF and BB1 algorithms as defined in [IBCS] have the following
 object identifiers.  These object identifiers are also defined in the
 ASN.1 module in [IBCS].
 bf OBJECT IDENTIFIER ::= {
   joint-iso-itu-t(2) country(16) us(840)
   organization(1) identicrypt(114334)
   ibcs(1) ibcs1(1) ibe-algorithms(2) bf(1)
 }

Martin & Schertler Informational [Page 6] RFC 5409 Using IBE with CMS January 2009

 This is the object identifier that MUST be inserted in the
 keyEncryptionAlgorithm field in the CMS when the BF algorithm is used
 to encrypt the CEK.
 bb1 OBJECT IDENTIFIER ::= {
   joint-iso-itu-t(2) country(16) us(840)
   organization(1) identicrypt(114334)
   ibcs(1) ibcs1(1) ibe-algorithms(2) bb1(2)
 }
 This is the object identifier that MUST be inserted in the
 keyEncryptionAlgorithm field in the CMS when the BB1
 algorithm is used to encrypt the CEK.

4. Processing by the Sender

 The sender of a message that uses IBE to encrypt content-
 encryption keys performs the following steps:
    1. Selects a set of IBE public parameters to use in the
       subsequent steps in accordance with his local security
       policy.  He then determines the URI where the public
       parameters can be obtained using the process described in
       [IBE].  This information MUST be encoded in the
       IBEIdentityInfo as described in Section 2.
    2. Sets the fields of an OtherRecipientInfo object to
       their appropriate values as described in Section 2.
    3. Calculates an IBE public key as defined in [IBCS]
       using this IBEIdentityInfo as the identity information.
    4. This IBE public key is then used to encrypt the
       content-encryption key (CEK), using the algorithms that are
       defined in [IBCS].
    5. Sets encryptedKey to the IBE-encrypted CEK.
    6. Within the CMS, keyEncryptionAlgorithm MUST then be
       set to the appropriate OID for the IBE algorithm that was
       used (see Section 3).

5. Processing by the Receiver

 Upon receiving a message that has a CEK encrypted with IBE,
 the recipient performs the following steps to decrypt the
 CEK:

Martin & Schertler Informational [Page 7] RFC 5409 Using IBE with CMS January 2009

    1. Determines that the CEK is IBE-encrypted by noting that
       the oriType of the OtherRecipientInfo type is set to
       ibeORIType.
    2. Determines that the recipientIdentity was used as the
       identity in IBE encryption of the CEK.
    3. Determines the location of the IBE public parameters
       and the IBE Private Key Generator as described in
       [IBE].
    4. Obtains the IBE public parameters from the location
       determined in Step 3 using the process defined in
       [IBE].
    5. Obtains the IBE private key needed to decrypt the
       encrypted CEK using the process defined in [IBE].
    6. Decrypts the CEK using the IBE private key obtained in
       Step 4 using the algorithms described in [IBCS].

6. ASN.1 Module

 The following ASN.1 module summarizes the ASN.1 definitions
 defined by this document.
 IBECMS-module {
   joint-iso-itu-t(2) country(16) us(840)
   organization(1) identicrypt(114334)
   ibcs(1) cms(4) module(5) version(1)
 }
 DEFINITIONS IMPLICIT TAGS ::= BEGIN
 IMPORTS IBEIdentityInfo, uriPPSOID FROM
    IBEARCH-module { joint-iso-itu-t(2) country(16)
      us(840) organization(1) identicrypt(114334) ibcs(1)
      ibearch(5) module(5) version(1)
    };
 IBEOtherRecipientInfo ::= SEQUENCE {
   oriType   OBJECT IDENTIFIER,
   oriValue  IBERecipientInfo
 }

Martin & Schertler Informational [Page 8] RFC 5409 Using IBE with CMS January 2009

 ibeORIType OBJECT IDENTIFIER ::= {
   joint-iso-itu-t(2) country(16) us(840)
   organization(1) identicrypt(114334)
   ibcs(1) cms(4) ori-oid(1) version(1)
 }
 IBERecipientInfo ::= SEQUENCE {
   cmsVersion         INTEGER { v3(3) },
   keyFetchMethod     OBJECT IDENTIFIER,
   recipientIdentity  IBEIdentityInfo,
   serverInfo         SEQUENCE SIZE (1..MAX) OF
     OIDValuePairs OPTIONAL,
   encryptedKey       EncryptedKey
 }
 OIDValuePairs ::= SEQUENCE {
   fieldID     OBJECT IDENTIFIER,
   fieldData   OCTET STRING
 }
 EncryptedKey ::= OCTET STRING
 EmailIdentityData ::= SEQUENCE {
   rfc822Name   IA5String,
   time         GeneralizedTime
 }
 cmsIdentityOID OBJECT IDENTIFIER ::= {
   joint-iso-itu-t(2) country(16) us(840)
   organization(1) identicrypt(114334)
   keyschemas(2) icschemas(1) email(1) version(1)
 }
 END

7. Security Considerations

 This document is based on [CMS], [IBCS], and [IBE], and the relevant
 security considerations of those documents apply.

7.1. Attacks outside the Scope of This Document

 Attacks on the cryptographic algorithms that are used to implement
 IBE are outside the scope of this document.  Such attacks are
 detailed in [IBCS], which defines parameters that give 80-bit,

Martin & Schertler Informational [Page 9] RFC 5409 Using IBE with CMS January 2009

 112-bit, 128-bit, and 256-bit encryption strength.  We assume that
 capable administrators of an IBE system will select parameters that
 provide a sufficient resistance to cryptanalytic attacks by
 adversaries.
 Attacks that give an adversary the ability to access or change the
 information on a PPS or PKG, especially the cryptographic material
 (referred to in this document as the master secret), will defeat the
 security of an IBE system.  In particular, if the cryptographic
 material is compromised, the adversary will have the ability to
 recreate any user's private key and therefore decrypt all messages
 protected with the corresponding public key.  To address this
 concern, it is highly RECOMMENDED that best practices for physical
 and operational security for PPS and PKG servers be followed and that
 these servers be configured (sometimes known as hardened) in
 accordance with best current practices [NIST].  An IBE system SHOULD
 be operated in an environment where illicit access to the PKG or the
 ability to modify the information distributed by the PPS is
 infeasible for attackers to obtain.
 Attacks that require administrative access or IBE-user-equivalent
 access to machines used by either the client or the server components
 defined in this document are also outside the scope of this document.
 We also assume that all administrators of a system implementing the
 protocols that are defined in this document are trustworthy and will
 not abuse their authority to bypass the security provided by an IBE
 system.  This is of particular importance with an IBE system, for an
 administrator of a PKG could potentially abuse his authority and
 configure the PKG to grant him any IBE private key that the PKG is
 capable of calculating.  To minimize the possibility of
 administrators doing this, a system implementing IBE SHOULD implement
 n-out-of-m control for critical administrative functions and SHOULD
 maintain auditable logs of all security-critical events that occur in
 an operating IBE system.
 Similarly, we assume that users of an IBE system will behave
 responsibly, not sharing their authentication credentials with
 others.  Thus, attacks that require such assumptions are outside the
 scope of this document.

7.2. Attacks within the Scope of This Document

 Attacks within the scope of this document are those that allow an
 adversary to:
    o  passively monitor information transmitted between users of an
       IBE system and the PPS and PKG

Martin & Schertler Informational [Page 10] RFC 5409 Using IBE with CMS January 2009

    o  masquerade as a PPS or PKG
    o  perform a denial-of-service (DoS) attack on a PPS or PKG
    o  easily guess an IBE user's authentication credential

7.3. Attacks to Which the Protocols Defined in This Document

    Are Susceptible
 All communications between users of an IBE system and the PPS or PKG
 are protected using TLS [TLS].  The IBE system defined in this
 document provides no additional security for the communications
 between IBE users and the PPS or PKG.  Therefore, the described IBE
 system is completely dependent on the TLS security mechanisms for
 authentication of the PKG or PPS server and for confidentiality and
 integrity of the communications.  Should there be a compromise of the
 TLS security mechanisms, the integrity of all communications between
 an IBE user and the PPS or PKG will be suspect.
 The protocols defined in this document do not explicitly defend
 against an attacker masquerading as a legitimate IBE PPS or PKG.  The
 protocols rely on the server authentication mechanism of TLS [TLS].
 In addition to the TLS server authentication mechanism, IBE client
 software can provide protection against this possibility by providing
 user interface capabilities that allows users to visually determine
 that a connection to PPS and PKG servers is legitimate.  This
 additional capability can help ensure that users cannot easily be
 tricked into providing valid authorization credentials to an
 attacker.
 The protocols defined in this document are also vulnerable to attacks
 against an IBE PPS or PKG.  Denial-of-service attacks against either
 component can result in users unable to encrypt or decrypt using IBE,
 and users of an IBE system SHOULD take the appropriate
 countermeasures [DOS, BGPDOS] that their use of IBE requires.
 The IBE user authentication method used by an IBE PKG SHOULD be of
 sufficient strength to prevent attackers from easily guessing the IBE
 user's authentication credentials through trial and error.

Martin & Schertler Informational [Page 11] RFC 5409 Using IBE with CMS January 2009

8. References

8.1. Normative References

 [ASN1]     ITU-T Recommendation X.680: Information Technology -
            "Abstract Syntax Notation One (ASN.1): Specification of
            Basic Notation", July 2002.
 [CMS]      Housley, R., "Cryptographic Message Syntax (CMS)", RFC
            3852, July 2004.
 [DER]      ITU-T Recommendation X.690: OSI Networking and System
            Aspects: Abstract Syntax Notation One (ASN.1), July 2002.
 [DOS]      Ferguson, P. and D. Senie, "Network Ingress Filtering:
            Defeating Denial of Service Attacks which employ IP Source
            Address Spoofing", BCP 38, RFC 2827, May 2000.
 [IBCS]     Boyen, X. and L. Martin, "Identity-Based Cryptography
            Standard (IBCS) #1: Supersingular Curve Implementations of
            the BF and BB1 Cryptosystems", RFC 5091, December 2007.
 [IBE]      Appenzeller, G., Martin, L., and M. Schertler, "Identity-
            Based Encryption Architecture and Supporting Data
            Structures", RFC 5408, January 2009.
 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [PKIX]     Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
            Housley, R., and W. Polk, "Internet X.509 Public Key
            Infrastructure Certificate and Certificate Revocation List
            (CRL) Profile", RFC 5280, May 2008.
 [TLS]      Dierks, T. and E. Rescorla, "The Transport Layer Security
            (TLS) Protocol Version 1.2", RFC 5246, August 2008.

8.2. Informative References

 [BGPDOS]   Turk, D., "Configuring BGP to Block Denial-of-Service
            Attacks", RFC 3882, September 2004.
 [NIST]     M. Souppaya, J. Wack and K. Kent, "Security Configuration
            Checklist Program for IT Products - Guidance for Checklist
            Users and Developers", NIST Special Publication SP 800-70,
            May 2005.

Martin & Schertler Informational [Page 12] RFC 5409 Using IBE with CMS January 2009

Authors' Addresses

 Luther Martin
 Voltage Security
 1070 Arastradero Rd, Suite 100
 Palo Alto, CA 94304
 USA
 Phone: +1 650 543 1280
 EMail: martin@voltage.com
 Mark Schertler
 Axway
 1600 Seaport Blvd, Suite 400
 Redwood City, CA 94063
 USA
 Phone: +1 650 216 2039
 EMail: mschertler@us.axway.com

Martin & Schertler Informational [Page 13]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5409.txt · Last modified: 2009/01/23 17:30 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki