| DHC | S.Z. Zhou, Ed. |
| Internet-Draft | ZTE Corporation |
| Intended status: Standards Track | Xu |
| Expires: May 09, 2013 | Institute of Acoustics, Chinese Academy of Sciences |
| November 05, 2012 |
Securing DHCPv6 By Identity Based Cryptography
draft-zhou-dhc-ibc-01
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.
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 09, 2013.
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 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.
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.
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.
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.
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].
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) ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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 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].
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;
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.
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.
| [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. |