draft-ietf-smime-ibearch-01.txt   draft-ietf-smime-ibearch-02.txt 
G. Appenzeller G. Appenzeller
L. Martin L. Martin
S/MIME Working Group M. Schertler S/MIME Working Group M. Schertler
Internet Draft Voltage Security Internet Draft Voltage Security
Expires: April 2007 October 2006 Expires: June 2007 December 2006
Identity-based Encryption Architecture Identity-based Encryption Architecture
<draft-ietf-smime-ibearch-01.txt> <draft-ietf-smime-ibearch-02.txt>
Status of this Document Status of this Document
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at and may be updated, replaced, or made obsolete by other documents at
any time. It is inappropriate to use Internet-Drafts as reference any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Abstract Abstract
skipping to change at page 2, line 38 skipping to change at page 2, line 38
4.7. Responses Containing a Redirect..........................14 4.7. Responses Containing a Redirect..........................14
4.8. Responses Indicating an Error............................15 4.8. Responses Indicating an Error............................15
5. ASN.1 Module..................................................16 5. ASN.1 Module..................................................16
6. Security Considerations.......................................18 6. Security Considerations.......................................18
6.1. Attacks that are outside the scope of this document......18 6.1. Attacks that are outside the scope of this document......18
6.2. Attacks that are within the scope of this document.......19 6.2. Attacks that are within the scope of this document.......19
6.3. Attacks that the protocols defined in this document are 6.3. Attacks that the protocols defined in this document are
susceptible to................................................19 susceptible to................................................19
6.4. Attacks that the protocols defined in this document protect 6.4. Attacks that the protocols defined in this document protect
against.......................................................19 against.......................................................19
7. IANA Considerations...........................................20 7. IANA Considerations...........................................19
8. References....................................................20 8. References....................................................21
8.1. Normative References.....................................20 8.1. Normative References.....................................21
Authors` Addresses...............................................22 Authors` Addresses...............................................23
Intellectual Property Statement..................................22 Intellectual Property Statement..................................23
Disclaimer of Validity...........................................23 Disclaimer of Validity...........................................24
Copyright Statement..............................................23 Copyright Statement..............................................24
Acknowledgment...................................................23 Acknowledgment...................................................24
1. Introduction 1. Introduction
This document describes the security architecture required to This document describes the security architecture required to
implement identity-based encryption, a public-key encryption implement identity-based encryption, a public-key encryption
technology that uses a user`s identity as a public key. technology that uses a user's identity as a public key.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEY]. document are to be interpreted as described in [KEY].
2. Identity-based Encryption 2. Identity-based Encryption
2.1. Overview 2.1. Overview
skipping to change at page 5, line 8 skipping to change at page 5, line 8
-----------------------------> ----------------------------->
Sender Public Parameter Server Sender Public Parameter Server
<----------------------------- <-----------------------------
IBE Public Parameters IBE Public Parameters
Figure 1 Requesting IBE Public Parameters Figure 1 Requesting IBE Public Parameters
2.2.2. Sender IBE-encrypts Message 2.2.2. Sender IBE-encrypts Message
To IBE-encrypt a message, the sender chooses a content encryption key To IBE-encrypt a message, the sender chooses a content encryption key
(CEK) and uses it to encrypt his message and then encrypts the CEK (CEK) and uses it to encrypt his message and then encrypts the CEK
with the recipient`s IBE public key as described in [CMS]. This with the recipient's IBE public key as described in [CMS]. This
operation is shown below in Figure 2. [IBCS] describes the algorithms operation is shown below in Figure 2. [IBCS] describes the algorithms
needed to implement two forms of IBE and [IBECMS] describes how to needed to implement two forms of IBE and [IBECMS] describes how to
use the Cryptographic Message Syntax (CMS) to encapsulate the use the Cryptographic Message Syntax (CMS) to encapsulate the
encrypted message along with the IBE information that the recipient encrypted message along with the IBE information that the recipient
needs to decrypt the message. needs to decrypt the message.
CEK ----> Sender ----> IBE-encrypted CEK CEK ----> Sender ----> IBE-encrypted CEK
^ ^
| |
| |
Recipient`s Identity Recipient's Identity
and IBE Public Parameters and IBE Public Parameters
Figure 2 Using an IBE Public-key Algorithm to Encrypt Figure 2 Using an IBE Public-key Algorithm to Encrypt
2.3. Receiving and Viewing an IBE-encrypted Message 2.3. Receiving and Viewing an IBE-encrypted Message
The recipient of an IBE-encrypted message parses the message as The recipient of an IBE-encrypted message parses the message as
described in [IBECMS]. This gives him the URI where he can obtain the described in [IBECMS]. This gives him the URI where he can obtain the
IBE public parameters required to perform IBE calculations as well as IBE public parameters required to perform IBE calculations as well as
the identity that was used to encrypt the message. The PPS also gives the identity that was used to encrypt the message. The PPS also gives
skipping to change at page 12, line 5 skipping to change at page 12, line 5
certificate [RFC2818], and MUST abort the key request if the server certificate [RFC2818], and MUST abort the key request if the server
certificate verification of the TLS or SSL connection fails. Doing so certificate verification of the TLS or SSL connection fails. Doing so
is critical to protect the authentication credentials and the private is critical to protect the authentication credentials and the private
key against man-in-the-middle attacks when it is transmitted from the key against man-in-the-middle attacks when it is transmitted from the
key server to the client. key server to the client.
4.3. Request Structure 4.3. Request Structure
The POST method contains in its body the following XML structure: The POST method contains in its body the following XML structure:
<ibe:request xmlns:ibe=\"http://www.ietf.org/tbd/ibepkg\"> <ibe:request xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:header> <ibe:header>
<ibe:client version="clientID"/> <ibe:client version="clientID"/>
</ibe:header> </ibe:header>
<ibe:body> <ibe:body>
<ibe:keyRequest> <ibe:keyRequest>
<ibe:algorithm> <ibe:algorithm>
<oid> algorithmOID </oid> <oid> algorithmOID </oid>
</ibe:algorithm> </ibe:algorithm>
<ibe:id> <ibe:id>
ibeIdentityInfo ibeIdentityInfo
skipping to change at page 13, line 20 skipping to change at page 13, line 20
4.5. Server Response Format 4.5. Server Response Format
The key server replies to the HTTP request with an HTTP response. If The key server replies to the HTTP request with an HTTP response. If
the response contains a client error or server error status code, the the response contains a client error or server error status code, the
client MUST abort the key request and fail. client MUST abort the key request and fail.
If the PKG replies with a HTTP response that has a status code If the PKG replies with a HTTP response that has a status code
indicating success, the body of the reply MUST contain the following indicating success, the body of the reply MUST contain the following
XML structure: XML structure:
<ibe:response xmlns:ic="http://www.ietf.org/tbd/icsip"> <ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:responseType value="responseCode"/> <ibe:responseType value="responseCode"/>
<ibe:body> <ibe:body>
bodyTags bodyTags
</ibe:body> </ibe:body>
</ibe:response> </ibe:response>
The responseCode describes the type of response from the key server. The responseCode describes the type of response from the key server.
The list of currently defined response codes is: The list of currently defined response codes is:
100 KEY_FOLLOWS 100 KEY_FOLLOWS
skipping to change at page 14, line 5 skipping to change at page 14, line 5
301 INVALID_REQUEST 301 INVALID_REQUEST
303 CLIENT_OBSOLETE 303 CLIENT_OBSOLETE
304 AUTHORIZATION DENIED 304 AUTHORIZATION DENIED
4.6. Response Containing a Private Key 4.6. Response Containing a Private Key
If the key request was successful, the key server responds with KEY If the key request was successful, the key server responds with KEY
FOLLOWS, and the <ibe:body> must contain a <ibe:privateKey> tag with FOLLOWS, and the <ibe:body> must contain a <ibe:privateKey> tag with
a valid private key. An example of this is shown below. a valid private key. An example of this is shown below.
<ibe:response xmlns:ic=" http://www.ietf.org/tbd/icsip"> <ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:responseType value="100"/> <ibe:responseType value="100"/>
<ibe:body> <ibe:body>
<ibe:privateKey> <ibe:privateKey>
privateKey privateKey
</ibe:privateKey> </ibe:privateKey>
</ibe:body> </ibe:body>
</ibe:response> </ibe:response>
The privateKey is the Base64 [B64] encoding of the DER encoding of The privateKey is the Base64 [B64] encoding of the DER encoding of
the following ASN.1 structure: the following ASN.1 structure:
skipping to change at page 15, line 5 skipping to change at page 15, line 5
the ASN.1 module below. the ASN.1 module below.
4.7. Responses Containing a Redirect 4.7. Responses Containing a Redirect
A Key Server MAY support authenticating user to external A Key Server MAY support authenticating user to external
authentication mechanism. If this is the case, the server replies to authentication mechanism. If this is the case, the server replies to
the client with response code 201 and the body MUST contain a the client with response code 201 and the body MUST contain a
<ibe:location> element that specifies the URI of the authentication <ibe:location> element that specifies the URI of the authentication
mechanism. An example is shown below. mechanism. An example is shown below.
<ibe:response xmlns:ic=" http://www.ietf.org/tbd/icsip"> <ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:responseType value="201"/> <ibe:responseType value="201"/>
<ibe:body> <ibe:body>
<ibe:location URI="http://www.example.com/enroll.asp"/> <ibe:location URI="http://www.example.com/enroll.asp"/>
</ibe:body> </ibe:body>
</ibe:response> </ibe:response>
The client can now contact the authentication mechanism to obtain The client can now contact the authentication mechanism to obtain
authentication credentials. Once the client has obtained the authentication credentials. Once the client has obtained the
credential, it sends a new key request to the PKG with the correct credential, it sends a new key request to the PKG with the correct
authentication credentials contained in the request. authentication credentials contained in the request.
skipping to change at page 20, line 8 skipping to change at page 19, line 51
are encrypted using TLS 1.1 [TLS] or SSL 3.0 [SSL], which should are encrypted using TLS 1.1 [TLS] or SSL 3.0 [SSL], which should
provide an adequate level of protection for such communications. provide an adequate level of protection for such communications.
The authentication method used by an IBE PKG should also be The authentication method used by an IBE PKG should also be
sufficiently strong to prevent attackers from easily guessing them sufficiently strong to prevent attackers from easily guessing them
through trial and error. through trial and error.
7. IANA Considerations 7. IANA Considerations
The XML defined in this document will be registered with the IANA per The XML defined in this document will be registered with the IANA per
the instructions in RFC 3688, The IETF XML Registry, once the format the instructions in RFC 3688, The IETF XML Registry.
has been agreed upon.
URI:
urn:ietf:params:xml:ns:ibe
Registrant Contact:
Mark Schertler
Voltage Security
1070 Arastradero Rd Suite 100
Palo Alto CA 94304
Phone: +1 650 543 1280
Email: mark@voltage.com
XML:
BEGIN
<ibe:request xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:header>
<ibe:client version="clientID"/>
</ibe:header>
<ibe:body>
<ibe:keyRequest>
<ibe:algorithm>
<oid> algorithmOID </oid>
</ibe:algorithm>
<ibe:id>
ibeIdentityInfo
</ibe:id>
</ibe:keyRequest>
</ibe:body>
</ibe:request>
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:responseType value="responseCode"/>
<ibe:body>
bodyTags
</ibe:body>
</ibe:response>
END
8. References 8. References
8.1. Normative References 8.1. Normative References
[AUTH] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [AUTH] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., Sink, E. and L. Stewart, "HTTP Leach, P., Luotonen, A., Sink, E. and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", RFC Authentication: Basic and Digest Access Authentication", RFC
2617, June 1999. 2617, June 1999.
skipping to change at page 22, line 5 skipping to change at page 23, line 5
[SSL3] A. Frier, P. Karlton, P. Kocher, "The SSL 3.0 Protocol," [SSL3] A. Frier, P. Karlton, P. Kocher, "The SSL 3.0 Protocol,"
Netscape Communications Corp., Nov 18, 1996. Netscape Communications Corp., Nov 18, 1996.
[TLS] T. Dierks, E. Rescorla, "The Transport Layer Security (TLS) [TLS] T. Dierks, E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1," RFC 4346, April 2006. Protocol Version 1.1," RFC 4346, April 2006.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998. 1998.
Authors` Addresses Authors' Addresses
Guido Appenzeller Guido Appenzeller
Voltage Security Voltage Security
1070 Arastradero Rd Suite 100 1070 Arastradero Rd Suite 100
Palo Alto CA 94304 Palo Alto CA 94304
Phone: +1 650 543 1280 Phone: +1 650 543 1280
Email: guido@voltage.com Email: guido@voltage.com
Luther Martin Luther Martin
 End of changes. 13 change blocks. 
21 lines changed or deleted 61 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/