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

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 09, 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 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

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.

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)               ~
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      

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)                        ~
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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
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 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;

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

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

[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[I-D.tschofenig-pana-bootstrap-rfc3118] Tschofenig, H, "Bootstrapping RFC3118 Delayed authentication using PANA", Internet-Draft draft-tschofenig-pana-bootstrap-rfc3118-01, October 2003.
[I-D.yegin-eap-boot-rfc3118] Tschofenig, H, Yegin, A and D Forsberg, "Bootstrapping RFC3118 Delayed DHCP Authentication Using EAP-based Network Access Authentication", Internet-Draft draft-yegin-eap-boot-rfc3118-03, July 2008.
[I-D.ietf-dhc-secure-dhcpv6] Jiang, S and S Shen, "Secure DHCPv6 Using CGAs", Internet-Draft draft-ietf-dhc-secure-dhcpv6-03, June 2011.
[I-D.xu-dhc-cadhcp] Xu, Y, Manning, S and M Wong, "A authentication method based on certificate for DHCP", Internet-Draft draft-xu-dhc-cadhcp-00, June 2011.
[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)", RFC 6508, February 2012.
[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.
[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