One document matched: draft-zhou-dhc-ibc-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-zhou-dhc-ibc-01" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="draft-zhou-dhc-ibc-00">Securing DHCPv6 By Identity Based
Cryptography</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Sujing Zhou" initials="S.Z." role="editor"
surname="Zhou">
<organization>ZTE Corporation</organization>
<address>
<postal>
<street>No.68 Zijinghua Rd. Yuhuatai District</street>
<!-- Reorder these if your country does things differently -->
<city>Nanjing</city>
<region>Jiang Su</region>
<code>210012</code>
<country>R.R.China</country>
</postal>
<email>zhou.sujing@zte.com.cn</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Zhou Xu" surname="Xu">
<organization>Institute of Acoustics, Chinese Academy of
Sciences</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<date day="5" month="November" year="2012"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Internet</area>
<workgroup>DHC</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<section title="DHCP">
<t>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 <xref target="RFC3315"/></t>
<t>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<xref
target="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.</t>
<t>To obtain other configuration parameters except IPv6 addresses, the
client and server are involved in an exchange of two messages<xref
target="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.</t>
<t>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.</t>
</section>
<section title="Security Threats and Defense Methods">
<t>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<xref target="RFC3315"/>.</t>
<t>To defend against the above attacks, DHCPv6, like DHCPv4, defined
Authentication Option<xref target="RFC3118"/><xref target="RFC3315"/>
which include fields of authentication protocol types, algorithm
types, and authentication information, to provide authentication for
DHCP messages.</t>
<t>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<xref target="RFC3315"/>. However the distribution of shared
secret key is unspecified. Some work proposed to distribute shared
secret key by AAA server <xref
target="I-D.tschofenig-pana-bootstrap-rfc3118"/><xref
target="I-D.yegin-eap-boot-rfc3118"/> .</t>
<t>Recently, new authentication protocols based on public key
cryptographic techniques, specifically digital signatures, were
proposed <xref target="I-D.ietf-dhc-secure-dhcpv6"/><xref
target="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.</t>
<t>In this document, we propose to adopt identity based cryptography
(IBC)<xref target="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., <xref target="Hess02"/><xref
target="CC03"/>, and a new method of distributing shared secret key
between client and server, by adopting identikit based
encryption(IBE),e.g., <xref target="RFC5091"/><xref target="RFC6508"/>
and IBS.</t>
</section>
</section>
<!-- -->
<section title="Terminology ">
<t>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 <xref
target="RFC2119"/>.</t>
</section>
<section title="Options">
<section anchor="IBC_PARAMETER" title="IBC_PARAMETER Option">
<t><figure>
<artwork><![CDATA[ 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) ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
</figure></t>
<t><list hangIndent="20" style="hanging">
<t hangText="option-code">OPTION_IBC_PARAMETER (TBA)</t>
<t hangText="option-len">1 + length of IBC public parameters or
URL where IBC public parameters is located</t>
<t hangText="flag">Indicate which is included in the following
field</t>
<t hangText="IBC public parameters">Values of IBC public
parameters</t>
<t hangText="URL">URL where IBC public parameters are located</t>
</list></t>
</section>
<section anchor="IBC_ID" title="IBC_ID Option">
<t><figure>
<artwork><![CDATA[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) ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure><list hangIndent="20" style="hanging">
<t hangText="option-code">OPTION_IBC_ID (TBA)</t>
<t hangText="option-len">length of IBC_ID</t>
</list></t>
</section>
<section anchor="IBC_ENCRYPTED_KEY" title="IBC_ENCRYPTED_KEY Option ">
<t><figure>
<artwork><![CDATA[ 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) ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t><list hangIndent="20" style="hanging">
<t hangText="option-code">OPTION_IBC_ENCRYPTED_KEY (TBA)</t>
<t hangText="option-len">8 + length of encrypted key and signature
fields</t>
<t hangText="IBE id">The identity based encryption algorithm used
in calculating encrypted key</t>
<t hangText="IBS id">The identity based signature algorithm used
in calculating signature</t>
<t hangText="ID type">The identity type used in identity based
encryption and signature algorithms</t>
<t hangText="enckey-len ">The length of IBE encrypted key</t>
<t hangText="IBE encrypted key">The ciphertext output of the
identity based encryption algorithm identified by enc id with a
128 bits key as plaintext input</t>
<t hangText="IBS signature">The signature of the encrypted key,
output of the identity based signature algorithm identified by sig
id</t>
</list></t>
</section>
</section>
<section anchor="authen_ibs"
title="Authentication Through Identity Based Signatures">
<t><figure>
<artwork><![CDATA[ 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) ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t><list hangIndent="20" style="hanging">
<t hangText="option-code">OPTION_AUTH (11)</t>
<t hangText="option-len">11 + length of authentication information
field</t>
<t hangText="IBS">The newly defined authentication protocol used in
this authentication option</t>
<t hangText="algorithm">The identity based algorithm used in IBS
authentication protocol</t>
<t hangText="RDM">The replay detection method used in this
authentication option</t>
<t hangText="Replay detection ">The replay detection information for
the RDM</t>
<t hangText="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.</t>
<t hangText="IBS Signature ">The signature of the information to be
authenticated, output of the identity based signature algorithm
identified by algorithm.</t>
</list></t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Distribution of Shared Secret Key">
<t>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.</t>
<t>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 <xref target="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.</t>
<t>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).</t>
<t>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.</t>
<t>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 <xref target="RFC3315"/>.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document defines three new options which must be assigned Option
Type values within the option numbering space for DHCPv6 messages by
IANA :</t>
<t>Name: IBC_PARAMETER Option;</t>
<t>Value: TBA.</t>
<t>Description: see Section <xref target="IBC_PARAMETER"/>.</t>
<t/>
<t>Name: IBC_ID Option;</t>
<t>Value: TBA.</t>
<t>Description: see Section <xref target="IBC_ID"/>.</t>
<t/>
<t>Name: IBC_ENCRYPTED_KEY_Option;</t>
<t>Value: TBA.</t>
<t>Description: see Section <xref target="IBC_ENCRYPTED_KEY"/>.</t>
<t>This document also defines a new Authentication protocol that must be
assigned protocol number by IANA:</t>
<t/>
<t>Name: IBS_Auth;</t>
<t>Value: TBA.</t>
<t>Description: see Section <xref target="authen_ibs"/>.</t>
<t>The values of IBE id and IBS id defined in IBC_ENCRYPTED_KEY_Option
are also required to be assigned by IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t/>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<?rfc include='reference.RFC.2119.xml'?>
<?rfc include='reference.RFC.3315.xml'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.3118.xml'?>
<?rfc include='reference.I-D.tschofenig-pana-bootstrap-rfc3118.xml'?>
<?rfc include='reference.I-D.yegin-eap-boot-rfc3118.xml'?>
<?rfc include='reference.I-D.ietf-dhc-secure-dhcpv6'
?>
<?rfc include='reference.I-D.xu-dhc-cadhcp'?>
<?rfc include='reference.RFC.5091.xml'?>
<?rfc include='reference.RFC.6508.xml'?>
<reference anchor="CC03">
<front>
<title>An Identity-Based Sig-nature from Diffie-Hellman
Groups</title>
<author initials="J." surname="Cha">
<organization/>
</author>
<author initials="J." surname="Cheon">
<organization/>
</author>
<date year="2003"/>
</front>
<seriesInfo name="LNCS" value=" 2567"/>
</reference>
<reference anchor="Hess02">
<front>
<title>Efficient Identity Based Signature Schemes Based on
Pairings</title>
<author initials="F." surname="Hess">
<organization/>
</author>
<date year="2002"/>
</front>
<seriesInfo name="LNCS" value="2595"/>
</reference>
<reference anchor="sh84">
<front>
<title>Identity-Based Cryptosystems and Signature Schemes</title>
<author initials="A." surname="Shamir">
<organization/>
</author>
<date year="1984"/>
</front>
<seriesInfo name="LNCS" value="7"/>
</reference>
</references>
<!-- -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:09:20 |