One document matched: draft-wu-hokey-ldn-discovery-01.xml

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3118 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3118.xml">
<!ENTITY rfc3315 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY rfc3748 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml">
<!ENTITY rfc5296 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5296.xml">
<!ENTITY rfc5295 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5295.xml">
]>
<?rfc strict="yes"?>
<?rfc comments="no"?>
<?rfc inline="yes"?>
<?rfc editing="no"?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc rfcprocack="no"?>
<?rfc tocindent="yes"?>
<rfc category="std" docName="draft-wu-hokey-ldn-discovery-01"
     ipr="noDerivativesTrust200902">
  <front>
    <title>The Local Domain Name DHCP Option</title>

    <author fullname="Glen Zorn" initials="G." surname="Zorn">
      <organization>Network Zen</organization>

      <address>
        <postal>
          <street>1463 East Republican Street</street>

          <city>Seattle</city>

          <region>Washington</region>

          <code>98112</code>

          <country>USA</country>
        </postal>

        <phone>+1 206 931 0768</phone>

        <email>gwz@net-zen.net</email>
      </address>
    </author>

    <author fullname="Qin Wu" initials="Q." surname="Wu">
      <organization abbrev="Huawei">Huawei Technologies Co.,
      Ltd.</organization>

      <address>
        <postal>
          <street>Site B, Floor 12, Huihong Mansion, No.91 Baixia Rd.</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>21001</code>

          <country>China</country>
        </postal>

        <phone>+86-25-84565892</phone>

        <email>sunseawq@huawei.com</email>
      </address>
    </author>

    <author fullname="Yungui Wang" initials="Y." surname="Wang">
      <organization abbrev="Huawei">Huawei Technologies Co.,
      Ltd.</organization>

      <address>
        <postal>
          <street>Site B, Floor 10, HuiHong Mansion, No.91 BaiXia Rd.</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210001</code>

          <country>P.R. China</country>
        </postal>

        <phone>+86 25 84565893</phone>

        <email>w52006@huawei.com</email>
      </address>
    </author>

    <date year="2010" />

    <abstract>
      <t>In order to derive a Domain-Specific Root Key (DSRK) from the
      Extended Master Session Key (EMSK) generated as a side-effect of an
      Extensible Authentication Protocol (EAP) method, the EAP peer must
      discover the name of the domain to which it is attached. <vspace
      blankLines="1" /> This document specifies a Dynamic Host Configuration
      Protocol (DHCP) option designed to allow a DHCP server to inform clients
      of the name of the local domain..</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The EAP Re-authentication Protocol (ERP) <xref
      target="RFC5296"></xref> is designed to allow faster re-authentication
      of a mobile device which was previously authenticated by means of the
      Extensible Authentication Protocol (EAP, <xref target="RFC3748"></xref>.
      Considering that the local root key (e.g., DSRK <xref
      target="RFC5295"></xref>) is generated using the local domain name
      (LDN), LDN discovery is an important part of re-authentication. As
      described in RFC 5296 <xref target="RFC5296"></xref>, the local domain
      name can be learned by the mobile device through the ERP exchange or via
      a lower-layer mechanism. However, no lower-layer mechanisms for LDN
      discovery have yet been defined. <vspace blankLines="1" /> This document
      specifies an extension to DHCP for local domain name discovery.</t>
    </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 <xref
      target="RFC2119"></xref>.</t>
    </section>

    <section title="Option Format">
      <t>In DHCPv6-based local domain name discovery, the LDN option is used
      by the DHCPv6 client (MD) to obtain the local domain name from the DHCP
      Server after full EAP authentication has taken place.</t>

      <section title="DHCPv6 Local Domain Name Option">
        <t>The format of this option is: <figure anchor="LDN-OPT">
            <artwork>
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_LOCAL_DOMAIN_NAME      |         option-length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             local-domain-name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
          </figure> <list style="hanging">
            <t hangText="option code">OPTION_LOCAL_DOMAIN_NAME (TBD)</t>

            <t hangText="option-length">Length of the ‘local domain name’
            field in octets</t>

            <t hangText="local-domain-name">This field contains the name of
            the local domain and MUST be encoded as specified in Section "8 of
            <xref target="RFC3315">RFC 3315</xref></t>
          </list></t>
      </section>
    </section>

    <section title="Appearance of the Option">
      <t>The LDN option MUST NOT appear in DHCPv6 messages other than the
      types Solicit, Advertise, Request, Information-Request and Reply. The
      option-code of the LDN option MAY be included in the Option Request
      Option in the DHCPv6 message types Solicit, Request and
      Information-Request.</t>
    </section>

    <section title="Client Behavior">
      <t>If a DHCPv6 client (MD) doesn't know the local domain name and
      requires the DHCP Server to provide the DHCPv6 LDN option, it MUST
      include an Option Request option requesting the DHCPv6 LDN option, as
      described in Section 22.7 of RFC 3315 <xref
      target="RFC3315"></xref>.</t>

      <t>When the DHCPv6 client recieves a LDN option with the local domain name
      present in it, it MUST verify that the option length is no more than 256
      octets (the maximum length of a single FQDN allowed by DNS), and that
      the local domain name is a properly encoded single FQDN, as specified in
      Section 8 "Representation and Use of Domain Names" of the RFC3315 <xref
      target="RFC3315"></xref>.</t>
    </section>

    <section title="Relay Agent Behavior">
      <t>If a DHCPv6 relay agent has pre-existing knowledge of the local
      domain name (for example, from a previous AAA exchange), it SHOULD
      include it in the DHCPv6 LDN option and forward to the DHPv6 server.</t>
    </section>

    <section title="Server Behavior">
      <t>If the option code for the LDN option is included in an Option
      Request option, the server SHOULD return the DHCPv6 LDN option to the
      client. If a DHCPv6 LDN option is received from a relay agent with a
      non-empty local-domain-name field, the server SHOULD extract this option
      and include it in the reply message.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The communication between the DHCP client and the DHCP server for the
      exchange of local domain name information is security sensitive and
      requires authentication, integrity and replay protection. Either
      lower-layer security (such as link layer security established as part of
      the network access authentication protocol run) or DHCP security <xref
      target="RFC3118"></xref> can be used.</t>
    </section>

    <section title="IANA considerations">
      <t>IANA is requested to allocate one DHCPv6 Option code, referencing
      this document.</t>
    </section>
	</middle>
  <back>
    <references title="Normative References">
      &rfc2119;

      &rfc5296;

      &rfc5295;

      &rfc3315;
    </references>

    <references title="Informative References">
      &rfc3118;

      &rfc3748;
    </references>
  </back>
</rfc>