Internet DRAFT - draft-zhou-dhc-ibc
draft-zhou-dhc-ibc
DHC S. Zhou, Ed.
Internet-Draft ZTE Corporation
Intended status: Standards Track Xu
Expires: May 9, 2013 Institute of Acoustics, Chinese
Academy of Sciences
November 5, 2012
Securing DHCPv6 By Identity Based Cryptography
draft-zhou-dhc-ibc-01
Abstract
This document provides security methods based on identity based
cryptography to protect DHCP messages. Identity based cryptography
is a special kind of public key cryptography. Specifically, an
authetication protocol based on IBS (identity based signature)
algorithms is proposed. A key distribution method adopting IBE (
identity based encryption) algorithms is also proposed, where key is
used as a shared secret in calculating authentication information
according to authentication protocol specified in RFC 3315.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on May 9, 2013.
Copyright Notice
Copyright (c) 2012 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
Zhou & Xu Expires May 9, 2013 [Page 1]
Internet-Draft draft-zhou-dhc-ibc-00 November 2012
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Security Threats and Defense Methods . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. IBC_PARAMETER Option . . . . . . . . . . . . . . . . . . . 4
3.2. IBC_ID Option . . . . . . . . . . . . . . . . . . . . . . 5
3.3. IBC_ENCRYPTED_KEY Option . . . . . . . . . . . . . . . . . 5
4. Authentication Through Identity Based Signatures . . . . . . . 6
5. Distribution of Shared Secret Key . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Zhou & Xu Expires May 9, 2013 [Page 2]
Internet-Draft draft-zhou-dhc-ibc-00 November 2012
1. Introduction
1.1. DHCP
The Dynamic Host Configuration Protocol for IPv6 (DHCP) is a client/
server protocol that enables DHCP servers to pass configuration
parameters such as IPv6 network addresses to IPv6 nodes, namely DHCP
clients [RFC3315]
To obtain an IPv6 network address among other configuration
parameters, the client and server are normally involved in an
exchange of four messages unless Rapid Commit option is
used[RFC3315]. The client firstly sends a Solicit message to
All_DHCP_Relay_Agents_and_Servers, a reserved link-scoped multicast
address, to find available DHCP servers. Any server that can meet
the client's requirements responds with an Advertise message. The
client then chooses one of the servers and sends a Request message to
the server asking for confirmed assignment of addresses and other
configuration information. The server responds with a Reply message
that contains the confirmed addresses and configuration.
To obtain other configuration parameters except IPv6 addresses, the
client and server are involved in an exchange of two
messages[RFC3315]. The client firstly sends an Information-Request
message to the All_DHCP_Relay_Agents_and_Servers multicast address.
The qualified servers respond with a Reply message containing the
configuration information for the client.
There are some other situations in which exchanges of two messages
are invoked, e.g., Confirm/Reply, Renew/Reply, Rebind/Reply, Release/
Reply, Decline/Reply.
1.2. Security Threats and Defense Methods
Among the security threats to DHCP are attacks involving with
identity masquerading and message tampering. Attacker may establish
a malicious server with the intent of providing incorrect
configuration information to the client ,the malicious server may
also mount a denial of service attack through misconfiguration of the
client that causes all network communication from the client to fail.
Attacker may be an invalid client masquerading as a valid client
aiming for theft of service, or to circumvent auditing for any number
of nefarious purposes[RFC3315].
To defend against the above attacks, DHCPv6, like DHCPv4, defined
Authentication Option[RFC3118][RFC3315] which include fields of
authentication protocol types, algorithm types, and authentication
information, to provide authentication for DHCP messages.
Zhou & Xu Expires May 9, 2013 [Page 3]
Internet-Draft draft-zhou-dhc-ibc-00 November 2012
In DHCPv6, two authentication protocols are specified: "delayed
authentication" and "reconfigure key authentication". They both
require a shared secret key between client and server and use HMAC-
MD5 algorithm to generate a message authentication code of the whole
DHCP message[RFC3315]. However the distribution of shared secret key
is unspecified. Some work proposed to distribute shared secret key
by AAA server
[I-D.tschofenig-pana-bootstrap-rfc3118][I-D.yegin-eap-boot-rfc3118] .
Recently, new authentication protocols based on public key
cryptographic techniques, specifically digital signatures, were
proposed [I-D.ietf-dhc-secure-dhcpv6][I-D.xu-dhc-cadhcp]. The
advantage of these protocols is not having to distribute shared
secret keys, but additional long options carrying CGA parameters or
public keys are required to send.
In this document, we propose to adopt identity based cryptography
(IBC)[sh84] to authenticate DHCP messages. Identity based
cryptography is a special public key cryptographic technique in which
user identities are used as the public keys, thus users are not
needed to send certificate or public key. Specifically, we propose a
new authentication protocol to authenticate DHCP messages by identity
based signatures(IBS), e.g., [Hess02][CC03], and a new method of
distributing shared secret key between client and server, by adopting
identikit based encryption(IBE),e.g., [RFC5091][RFC6508] and IBS.
2. 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 [RFC2119].
3. Options
3.1. IBC_PARAMETER Option
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IBC_PARAMETER | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flag | |
+-+-+-+-+-+-+-+-+ ~
~ IBC public parameters / URL(variable length) ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Zhou & Xu Expires May 9, 2013 [Page 4]
Internet-Draft draft-zhou-dhc-ibc-00 November 2012
option-code OPTION_IBC_PARAMETER (TBA)
option-len 1 + length of IBC public parameters or URL where
IBC public parameters is located
flag Indicate which is included in the following field
IBC public parameters Values of IBC public parameters
URL URL where IBC public parameters are located
3.2. IBC_ID Option
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IBC_ID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IBC_ID(variable length) ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_IBC_ID (TBA)
option-len length of IBC_ID
3.3. IBC_ENCRYPTED_KEY Option
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IBC_ENCRYPTED_KEY | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IBE id | IBS id| ID type | enckey-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IBE encrypted key(variable length) ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
~ IBS signature (variable length) ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Zhou & Xu Expires May 9, 2013 [Page 5]
Internet-Draft draft-zhou-dhc-ibc-00 November 2012
option-code OPTION_IBC_ENCRYPTED_KEY (TBA)
option-len 8 + length of encrypted key and signature fields
IBE id The identity based encryption algorithm used in
calculating encrypted key
IBS id The identity based signature algorithm used in
calculating signature
ID type The identity type used in identity based
encryption and signature algorithms
enckey-len The length of IBE encrypted key
IBE encrypted key The ciphertext output of the identity based
encryption algorithm identified by enc id with a
128 bits key as plaintext input
IBS signature The signature of the encrypted key, output of the
identity based signature algorithm identified by
sig id
4. Authentication Through Identity Based Signatures
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_AUTH | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IBS_Auth | algorithm | RDM | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| replay detection (64 bits) +-+-+-+-+-+-+-+-+
| | ID type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
~ IBS Signature(variable length) ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_AUTH (11)
option-len 11 + length of authentication information field
Zhou & Xu Expires May 9, 2013 [Page 6]
Internet-Draft draft-zhou-dhc-ibc-00 November 2012
IBS The newly defined authentication protocol used in
this authentication option
algorithm The identity based algorithm used in IBS
authentication protocol
RDM The replay detection method used in this
authentication option
Replay detection The replay detection information for the RDM
ID type The identity type used in calculation of IBS
signature. ID type=0 indicates using DUID value.
ID type=1 indicates using ID in IBC_ID Option.
IBS Signature The signature of the information to be
authenticated, output of the identity based
signature algorithm identified by algorithm.
DHCP Client or Server sends every message along with a IBS signature.
The identity of signer comes either from the accompanying DUID if the
ID type is zero, or from the accompanying IBC_ID option otherwise.
The public parameters or the URL where the public parameters can be
found in IBC_PARAMETER option.
IBC_ID option and IBC_PARAMETER option MAY only be sent once with the
first DHCP message to inform the peer of the identity and public
parameter. Once client and server have knowledge of the information,
the two options are not required to send again. When DHCP client or
server receives a DHCP message with IBS signature, it firstly checks
whether the public parameters or the URL storing the public
parameters are trusted. The reciever discards the message if the
public parameters are found untrusted, otherwise it continues to
verify the IBS signature. If the IBS signature is not valid, it
discards the message, otherwise it accepts the message.
5. Distribution of Shared Secret Key
What is proposed here is not a new authentication protocol, but a
method of distributing shared secret key between client and server,
specifically from server to client.
DHCP Client sends a DHCP message including an
IBC_ENCRYPTED_KEY_Option with enckey-len zero and the following two
fields (encrypted key field and signature field) null, to inform the
server that it requests to send a key through the method defined
here. Authentication Option defined in [RFC3315] is also included to
Zhou & Xu Expires May 9, 2013 [Page 7]
Internet-Draft draft-zhou-dhc-ibc-00 November 2012
inform server the preferred authentication protocol and algorithm.
The authentication protocols MUST be those based on shared secret,
e.g., delayed authentication.
DHCP Server replies with a DHCP message including an
IBC_ENCRYPTED_KEY_Option , optionally including IBC_ID and
IBC_PARAMETER options. If ID type in IBC_ENCRYPTED_KEY_ Option is
zero, DUID of server is also required to send. To generate an
IBC_ENCRYPTED_KEY_Option, server firstly generates a random key,
stores it along with client's DUID, then encrypts the key with
client's identity whose type has been indicated in the recieved
IBC_ENCRYPTED_KEY_Option from client, the encryption algorithm
following the enc id in the client's IBC_ENCRYPTED_KEY_Option (if it
is acceptable to server) ; then calculates an IBS signature on the
whole DHCP message excluding signature field and authentication
information, using the private key corresponding to server's
identity, the signature algorithm following the sig id in the
client's IBC_ENCRYPTED_KEY_Option (if it is acceptable to server).
After DHCP client receives the reply including an
IBC_ENCRYPTED_KEY_Option from server, it firstly checks if IBC public
parameters or URL storing the public parameter is trusted, if not,
discards the message, otherwise verifies the IBS signature against
server's identity and IBCpublic parameters. If the IBS signature is
not valid, discards the message, otherwise decrypts the IBE encrypted
key to obtain the shared secret key.
After DHCP client has obtained the shared secret key, it generates
authentication information from the shared secret key according to
the protocol and algorithm indicated in Authentication Option. DHCP
server verifies DHCP client's message and generates its message as
exactly specified in [RFC3315].
6. IANA Considerations
This document defines three new options which must be assigned Option
Type values within the option numbering space for DHCPv6 messages by
IANA :
Name: IBC_PARAMETER Option;
Value: TBA.
Description: see Section Section 3.1.
Name: IBC_ID Option;
Zhou & Xu Expires May 9, 2013 [Page 8]
Internet-Draft draft-zhou-dhc-ibc-00 November 2012
Value: TBA.
Description: see Section Section 3.2.
Name: IBC_ENCRYPTED_KEY_Option;
Value: TBA.
Description: see Section Section 3.3.
This document also defines a new Authentication protocol that must be
assigned protocol number by IANA:
Name: IBS_Auth;
Value: TBA.
Description: see Section Section 4.
The values of IBE id and IBS id defined in IBC_ENCRYPTED_KEY_Option
are also required to be assigned by IANA.
7. Security Considerations
This document considers the security of DHCP messages, specifically
message authentication between DHCP client and server directly or
through DHCP relay . The security of DHCP message flows between DHCP
relay and DHCP server is not considered here.
The authentication protocol provided in this document adopts identity
based signature without certificate, so it is crucial to keep the
private key corresponding to the identity secret, and the trust
anchor is in the IBC public parameters or the URL storing the IBC
public parameters.
The distribution of shared secret key method provided in this
document adopts both identity based signature and identity based
encryption, the shared secret key is encrypted by an IBE algorithm,
then the whole message including the encryption is authenticated by
an IBS algorithm. The security also relies on the secrecy of the
private keys corresponding to the identities and the trust in the IBC
public parameters and URL where IBV public parameters are published.
8. References
Zhou & Xu Expires May 9, 2013 [Page 9]
Internet-Draft draft-zhou-dhc-ibc-00 November 2012
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
8.2. Informative References
[CC03] Cha, J. and J. Cheon, "An Identity-Based Sig-nature from
Diffie-Hellman Groups", LNCS 2567, 2003.
[Hess02] Hess, F., "Efficient Identity Based Signature Schemes
Based on Pairings", LNCS 2595, 2002.
[I-D.ietf-dhc-secure-dhcpv6]
Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs",
draft-ietf-dhc-secure-dhcpv6-07 (work in progress),
September 2012.
[I-D.tschofenig-pana-bootstrap-rfc3118]
Tschofenig, H., "Bootstrapping RFC3118 Delayed
authentication using PANA",
draft-tschofenig-pana-bootstrap-rfc3118-01 (work in
progress), October 2003.
[I-D.xu-dhc-cadhcp]
Wong, M., Manning, S., and Y. Xu, "An Authentication
Method based on Certificate for DHCP",
draft-xu-dhc-cadhcp-01 (work in progress), September 2011.
[I-D.yegin-eap-boot-rfc3118]
Tschofenig, H., Yegin, A., and D. Forsberg, "Bootstrapping
RFC3118 Delayed DHCP Authentication Using EAP-based
Network Access Authentication",
draft-yegin-eap-boot-rfc3118-03 (work in progress),
July 2008.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC5091] Boyen, X. and L. Martin, "Identity-Based Cryptography
Standard (IBCS) #1: Supersingular Curve Implementations of
the BF and BB1 Cryptosystems", RFC 5091, December 2007.
[RFC6508] Groves, M., "Sakai-Kasahara Key Encryption (SAKKE)",
Zhou & Xu Expires May 9, 2013 [Page 10]
Internet-Draft draft-zhou-dhc-ibc-00 November 2012
RFC 6508, February 2012.
[sh84] Shamir, A., "Identity-Based Cryptosystems and Signature
Schemes", LNCS 7, 1984.
Authors' Addresses
Sujing Zhou (editor)
ZTE Corporation
No.68 Zijinghua Rd. Yuhuatai District
Nanjing, Jiang Su 210012
R.R.China
Email: zhou.sujing@zte.com.cn
Zhou Xu
Institute of Acoustics, Chinese Academy of Sciences
Phone:
Fax:
Email:
URI:
Zhou & Xu Expires May 9, 2013 [Page 11]
