One document matched: draft-mccann-dmm-flatarch-00.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" [
]>
<?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="no"?>
<!-- use numeric references tags -->
<?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="info" docName="draft-mccann-dmm-flatarch-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
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="FlatArch">Authentication and Mobility Management in a Flat Architecture</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Peter J. McCann" initials="P.J." role="editor"
surname="McCann">
<organization>Huawei</organization>
<address>
<postal>
<street>400 Crossing Blvd, 2nd Floor</street>
<!-- Reorder these if your country does things differently -->
<city>Bridgewater</city>
<region>NJ</region>
<code>08807</code>
<country>USA</country>
</postal>
<phone>+1 908 541 3563</phone>
<email>peter.mccann@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date 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>Internet Engineering Task Force</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>dmm</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>Today's mobility management schemes make use of a hierarchy of tunnels
from a relatively fixed anchor point, through one or more intermediate
nodes, to reach the MN's current point of attachment. These schemes
suffer from poor performance, scalability, and failure modes due to the
centralization and statefulness of the anchor point(s). The dmm (Distributed
Mobility Management) working group is currently chartered to investigate
alternative solutions that will provide greater performance, scalability,
and robustness through the distribution of mobility anchors. This document
is an input to the dmm discussion. It outlines a problem statement for the
existing mobility management techniques and goes on to propose (high-level)
solutions to two of the most vexing problems: MN authentication and mobility
management in a fully distributed, flat (non-hierarchical) access network.
These two aspects are often treated separately in a layered architecture,
but we argue there are important advantages to considering how these two
functions can work in tandem to provide a simple and robust framework for
the design of a wireless Internet Service Provider network.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t><xref target="fig_hierarchy"/> depicts the hierarchical mobility management
architecture that is being deployed by 3GPP LTE networks.
</t>
<figure align="center" anchor="fig_hierarchy" title="A typical hierarchical mobility management architecture.">
<artwork align="center"><![CDATA[
------
| P-GW | <--------- Fixed centralized
------ anchor point
// \\
// \\ <--------- Tunnels
// \\
------ ------ -----
| S-GW | | S-GW | | MME | <---- Responsible for
------ ------ ----- Authentication
// \\ \\ /
// \\ \\ /
// \\ \\ /
----- ----- -----
| eNB | | eNB | | eNB |
----- ----- -----
]]></artwork>
</figure>
<t>This architecture is an evolution of the General Packet Radio
System (GPRS) that was originally adopted for GSM systems. It is
motivated in large part by two fundamental requirements:
<list style="symbols">
<t>Keep the IP address (and therefore the anchor point) of the packet
data session fixed for the life of the session; and,</t>
<t>Re-use the existing legacy AKA authentication algorithm that was
used for circuit voice.</t>
</list>
These requirements were demanded by operators due to their desire to
maintain control over services in the home network and to maintain
their existing system of distributing user credentials in secure
Subscriber Identity Modules (SIMs).
</t>
<t>While these two requirements made sense for the operators that controlled
standards decisions at the time, meeting them comes at somewhat of a cost.
The use of a fixed P-GW without route optimization means that all packets
have to traverse the chain of tunnels from anchor to MN, which could be
very suboptimal if the MN is far away from the P-GW. The centralization
of state in the P-GW (and to a lesser extent in the S-GWs) means that these
nodes are scalability bottlenecks and that if one of them fails, all packet
data sessions going through that node also fail. The re-use of a legacy
symmetric secret key authentication protocol means that there must be a
round-trip to the home network to retrieve keying material upon initial
attachment and every time the MN encounters a new MME. In addition to the
performance impact, transport of secret keying material across inter-provider
interfaces always carries some risk that the material will be compromised
somewhere along the way. Note that keying material also needs to be
transported from the MME to each eNB that the MN encounters.
</t>
<t>This document examines the architectural implications of relaxing the
above two requirements. In particular, we note that many MNs will not
require a fixed IP address for the entire duration of their packet data
session, as they will most likely be acting as clients and initiating
short-lived connections to servers. It may be more important that such
communication take the shortest path possible to reduce latency and load
on the network. By making use of a routing protocol instead of a tunnel
setup protocol for most mobility events, we can maximize the fault tolerance
and compute the most optimal route for any packet from any vantage point
in the network.
</t>
<t>
Second, we note that the hardware limitations that mandated
the use of symmetric key algorithms for authentication are fading away.
On a modern CPU, an elliptic curve public key cryptographic operation can
be completed in well under 1 millisecond <xref target="BernsteinSpeed"/>.
With the addition of low-cost
cryptographic acceleration hardware <xref target="Gaubatz05"/>,
the battery impact of such an operation can
be reduced even further. As CPU power is only increasing, we argue that it
will be more important to reduce the number of messages and round-trips to
the home network than to absolutely minimize the CPU consumption in the MN.
Only a public key cryptosystem offers the ability to do this. With the
creation of a new breed of authentication algorithms that can operate in
one round-trip over the air, we can afford to perform a full re-authentication
of the MN upon encountering each Access Router (AR), completely eliminating the need to
transport secret keying material between infrastructure nodes.
</t>
<t>The remainder of this document is structured as follows: <xref target="sec_mobman"/>
discusses the possibility of using a routing protocol for localized, network-based
mobility management in a wireless access network. <xref target="sec_auth"/>
introduces a possible public-key based authentication scheme that could be used
for access authentication at each AR. <xref target="sec_synergy"/> explores the
synergy between authentication and mobility management, and explains how the new
authentication algorithm could be embedded into Mobile IP for macro-mobility across
domains. <xref target="sec_workplan"/> is a list of work items for the IETF
that will make this vision a reality. Finally, <xref target="sec_IANA"/> and
<xref target="sec_sec"/> give IANA and Security Considerations, respectively.
</t>
<section title="Requirements Language">
<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">RFC 2119</xref>.</t>
</section>
</section>
<section anchor="sec_mobman" title="Mobility Management">
<t><xref target="fig_flat"/> gives a picture of a flat wireless Internet service
provider network. Although ISP networks are usually structured in a hierarchy
of layers such as Core, Aggregation, and Access routers, the connectivity
between the routers is more mesh-like in nature and less rigidly hierarchical
than the tunneling boxes shown in <xref target="fig_hierarchy"/>.
</t>
<figure align="center" anchor="fig_flat" title="A flat wireless Internet service provider architecture.">
<artwork align="center"><![CDATA[
__O-----------O__
( )
( Internet )
(_ _)
/O-------------O
/ \
/ \
----- -----
( rtr )-------------__( rtr ) <--- Core Layer
----- _/ ----- Routers
/ \ ______/ / \
/ \ / / \
----- ----- ----- -----
( rtr ) ( rtr ) ( rtr ) ( rtr ) <--- Aggregation
----- ----- ----- ----- Layer Routers
/ \ / \ / \ /
---- ---- ---- ----
| AR | | AR | | AR | | AR | <--- Access Layer
---- ---- ---- ---- Routers
]]></artwork>
</figure>
<t>The Access Routers (ARs) would be integrated with the radio link
layer at the base stations. The ARs act as the first-hop routers
for the MNs, and tunnels do not appear in the architecture until
they are needed.
Note also that each router can be connected to more than one router
in the layer above, and can even be connected directly to some of
its peer routers in the same layer. Except for the access layer,
all of the routers in the network are standard off-the-shelf wireline
routers running IBGP.
</t>
<t>We assume that each AR has its own pool of
addresses from which it can assign to mobile nodes and that
these addresses are advertised using IBGP to the upstream
routers in the aggregation layer. We assume that all mobile
nodes are authenticated upon attachment or re-attachment to a
base station, and that the outcome of authentication is an
exchange of hostnames (the base station learns the mobile node's
hostname and vice-versa) bound to a master session key (MSK)
shared between the mobile node and base station. Upon initial
arrival in a given autonomous system, the mobile node is
allocated an address (or a prefix) from the base station to
which it is attached using ordinary mechanisms, e.g., DHCP.
Then the mobile node updates its home DNS server to point from
its hostname to the new address. The base station updates the
reverse pointer in the in-addr.arpa or ip6.arpa space to point
to the hostname it obtained when it authenticated the mobile
node. Then, upon handoff, the target base station looks up the
hostname received during authentication to determine whether the
mobile node already has an address assigned from elsewhere in
the autonomous system. If so, and if the hostname looked up in
the reverse pointer is the same, it sends a BGP UPDATE message
to all of its BGP peers containing the address (or the prefix)
that was allocated to the mobile node. Packets are then routed
appropriately to the new point of attachment in an optimal way.
In the remainder of this section we describe the possible mechanisms
in more detail.
</t>
<section anchor="sec_addrplan" title="Addressing Plan">
<t>The operator must define an addressing plan for the whole
autonomous system. As a maximally-flat network, we assume that
each base station will have its own designated pool of addresses
from which it will assign to mobile nodes. To save space in the
routing tables throughout the autonomous system, each pool
should be a contiguous chunk of address space with a common
prefix. Each base station acts as a BGP <xref
target="RFC4271"/> router, originating UPDATE messages for the
prefix(es) that it owns. The routers in the aggregation layer
are configured as route reflectors <xref target="RFC2796"/> for
the base stations they subtend (the base stations are route
reflector clients). These routers are configured to aggregate
the assigned address prefixes advertised by the base stations
for the core routers above them, but will faithfully reflect all
sub-prefixes advertised by any route reflector client to all
other route reflector clients. Also, any sub-prefixes
advertised by a client that are outside that client's
pre-assigned range (known by configuration in the aggregation
router) will also be reflected to the other clients and,
if the prefix is outside the scope of the route reflector itself,
propagated upward toward the core routers.
<list hangIndent="6" style="empty">
<t>On one popular BGP router platform,
this would be accomplished with a combination of the
"aggregate-address" command (without the "summary-only" option) and
the "neighbor distribute-list out" command specifying that
more-specific prefixes of the known aggregate are to be
suppressed to the non-client routers.
</t>
</list>
</t>
</section>
<section anchor="sec_handoff" title="Handoff">
<t>Upon handoff within the same autonomous system, the mobile
node is authenticated by the new base station. Given the mobile
node's authenticated DNS name, the new base station takes
several actions. First, it looks up the set of IP addresses
associated with the hostname. It then makes a policy check on
each IP address to see whether it is within the range of
addresses managed by BGP in its local autonomous system. If so,
it does a reverse lookup in the in-addr.arpa or ip6.arpa space
(this space is controlled by the wireless ISP, unlike the
forward mapping which is controlled by the mobile node) for each
such IP address to ensure that some peer base station in its
network did actually assign the IP address to the given name.
If so, it originates a new BGP UPDATE message to its peers
containing NLRI of the specific prefix (perhaps just a single
address) that was assigned to the mobile node, with itself as
the NEXT_HOP. It sets the LOCAL_PREF attribute to a 32-bit
timestamp taken from its local clock (we assume that all base
stations in an autonomous system have clocks synchronized to
within 1 second). This will guarantee that the route is
preferred over the same route that may have been advertised by a
previously visited base station. The UPDATE will be sent to the
parent routers in the aggregation layer, and will be reflected
down to all other base stations in the same cluster. If the
prefix was originally assigned by a peer base station in the
same cluster, that is the extent of the update. Otherwise, the
aggregation router propagates the update to the core layer which
reflects it down to all other aggregation routers and from there
it goes into all the base stations in the access layer.
</t>
<t>
Thus, when the mobile node moves
within the same cluster, the messaging is confined to that
cluster; however, when the mobile node crosses a cluster
boundary, the update propagates through the larger cluster
bounded by the route reflector above. If this is the core layer,
then the update would be propagated throughout the autonomous system.
This is necessary to ensure that optimal routes are
created everywhere in the system. In general, there may be
additional peer-to-peer links in the autonomous system; for
example, directly between two neighboring base stations. Such a
link would appear in the Interior Gateway Protocol (IGP, such as
OSPF, EIGRP, or IS-IS) but would not be a BGP peering because
the route reflectors take care of propagating BGP prefixes. Our
scheme allows packets to make use of this route when
appropriate; for example, a packet originated on one base
station, destined for an IP address that is normally homed on
the same base station but is being temporarily borrowed by a
neighbor, would match the more-specific route to the neighbor
listed as the NEXT_HOP in BGP and the recursive routing would
forward the packet over the direct link.
</t>
</section>
<section anchor="sec_addrmgmt" title="Address Management">
<t>The mobile node can therefore keep its address throughout the
autonomous system if it wishes. When the address is nearing its
lease expiration, the mobile node would send a unicast
DHCPREQUEST to the DHCP server associated with the original base
station to renew the lease. All base stations in the network
must filter packets bound to IP addresses internal to the
autonomous system to prevent abuse. In the case of DHCPREQUEST
going to a remote base station, the current base station must
add the DHCP Relay Agent Information Option <xref target="RFC3046"/>
containing the
mobile node's DNS hostname in the Agent Remote ID sub-option.
</t>
<t>Keeping an address for a long period of mobility is
sub-optimal due to the large amount of routing state that would
be introduced. Our scheme is optimized for the case where the
mobile node can periodically change its IP address to one that
is more locally-appropriate. The BGP routing updates can
provide a micro-mobility solution that hides the mobile node's
movement from nodes outside the autonomous system and avoids
frequent updates of its home DNS server. However, mobile nodes
should keep track of which connections are using which
addresses, and should periodically get new IP addresses from
whatever base station to which they happen to be attached. Each
IP address currently assigned to the mobile node should be
registered to its home DNS server, with the most recently
allocated listed first. Clients will therefore prefer the most
recently allocated address for new connections.
</t>
<t>Publishing the IP address assigned to a mobile node has
security implications. Anyone who does a lookup can track the
mobile node to the base station to which it was attached when it
reserved the address. In general the use of an optimal route
seems to be at odds with location privacy; if the mobile node
needs location privacy, it should hide itself behind a proxy and
only publish the proxy's IP address to the public DNS. Our
scheme could function with pseudonyms assigned to mobile nodes
by the visited network operator, but constructing such
pseudonyms and allocating credentials to them is outside the
scope of this document.
</t>
<t>When a mobile node wants to release an address it should
remove it from its home DNS server and send a DHCPRELEASE to the
original assigning DHCP server. A DHCP server may have a policy
that limits the number of times an IP address assignment may be
renewed from a remote base station. This will force the mobile
node to eventually release the address and optimize the routing
tables.
</t>
<t>The prefixes that we inject into the IBGP would most likely
be full-length IPv4 addresses, although for IPv6 assignment of
true prefixes would be more appropriate. All base stations in an
autonomous system would need to agree on the prefix lengths they
are assigning, and these prefixes would need to be on byte
boundaries (for in-addr.arpa reverse lookups) or nybble
boundaries (for ip6.arpa reverse lookups). The target base
station would look up the mobile node's hostname and get back
single IP addresses that are drawn from the prefixes and then do
the reverse lookup on the containing prefix.
</t>
</section>
<section anchor="sec_homeagent" title="Macro-Mobility">
<t>The ability for any router in the access network to attract
the packets destined for the MN can be used advantageously for
macro-mobility as well as micro-mobility. Let's consider again
the diagram from <xref target="fig_flat"/>, redrawn in
<xref target="fig_ha"/>.
</t>
<figure align="center" anchor="fig_ha" title="Home Agent support in a wireless Internet service provider architecture.">
<artwork align="center"><![CDATA[
__O-----------O__
( )
( Internet )
(_ _)
/O-------------O
/ \
/ \
----- ----- ----
( rtr )-------------__( rtr )---( HA )
----- _/ ----- ----
/ \ ______/ / \
/ \ / / \
----- ----- ----- -----
( rtr ) ( rtr ) ( rtr ) ( rtr )
----- ----- ----- -----
/ \ / \ / \ /
---- ---- ---- ----
| AR | | AR | | AR | | AR |
---- ---- ---- ----
]]></artwork>
</figure>
<t>When the MN leaves the autonomous system completely, it may
desire to keep sessions that were ongoing before it left. The
Home Agent in the figure can be used for this purpose. Instead
of using Gratuitous ARP or ND to attract the MN's packets, the
HA can instead send a BGP UPDATE into the network to effect the
routing of packets towards itself. This is a more powerful
mechanism than ARP or ND because it can reach across multiple
IP routing hops to install forwarding state that will route the
packets in its direction.</t>
<t>The sending of a BGP UPDATE by the HA is triggered by an
authenticated Registrationn Request or Binding Update. In this
respect, the role of the HA can be compared to the role of any
of the ARs that also must authenticate the MN before sending
UPDATEs. We advocate a unification of the authentication
protocol used for access and mobility signaling. The same set
of credentials and secret keys can be used for both purposes,
simplifying the network architecture and the node provisioning
process. In the next section, we give a high level design for
an authentication scheme that can be used.
</t>
</section>
</section>
<section anchor="sec_auth" title="Authentication">
<t>Recall in <xref target="sec_mobman"/> we alluded to an authentication
protocol that must run every time the MN encounters a new base station.
To minimize the number of round-trips to the home network, we choose
to base the authentication step on public key cryptography, namely
an Elliptic Curve Diffie-Hellman exchange between the MN and the
base station.
</t>
<t>We note that the existing key exchange protocols such as
IKE <xref target="RFC5996"/> and TLS <xref target="RFC5246"/>
implement Perfect Forward Secrecy (PFS) by completing an ephemeral Diffie-Hellman
exchange during the first round of messages between the communicating
parties. Credentials are exchanged in a second round of messages.
These multiple round-trips would introduce unacceptable overhead and
latency in the mobile wireless environment. A key insight is that
we don't necessarily need PFS if we are merely doing key exchange
for purposes of authentication and integrity protection. A simpler
protocol with one round-trip static Diffie-Hellman will suffice.
</t>
<t>Perhaps the most difficult part of deploying a public key infrastructure
is providing assurance that the public key obtained for the other party
with which one wants to communicate does actually correspond to a private
key known only to that other party. Key assurance can be provided through
the use of certificates such as those defined by X.509 <xref target="RFC5280"/>.
Usually, such certificates are exchanged in-band during the second round of
a key exchange protocol. They must then be validated using e.g., the Online
Certificate Status Protocol (OCSP) <xref target="RFC2560"/> or sometimes
with an OCSP response attached ("stapled") to the same message that delivered
the certificate. The exchange of certificates and OCSP information introduces
additional overhead and possible round-trips to the authentication protocol.
</t>
<t>In contrast, a new method of obtaining key assurance is currently being worked
on in the DNS-based Assurance of Named Entities (DANE) working group
<xref target="I-D.ietf-dane-protocol"/>. While intended initially to support
TLS, the protocol could be used for other purposes as well
(e.g., S/MIME <xref target="I-D.hoffman-dane-smime"/>). Interestingly,
some have proposed putting raw, bare public keys into the DNS records
so that TLS can be run without the use of any certificates
whatsoever <xref target="I-D.wouters-tls-oob-pubkey"/>. It is this latter
method of key assurance that we build on here.
</t>
<t>Here we use the terminology of "peer" and "authenticator" as they are used
in the Extensible Authentication Protocol (EAP) <xref target="RFC3748"/>.
In our case the peer is the MN and the authenticator is the base station
or Home Agent. We assume that the peer and authenticator are both named
entities with DNS records containing the public portion of their keys.
All such DNS records are protected with DNSSEC.
</t>
<t>The peer and authenticator must discover each others' names and obtain
the public keys corresponding to those names. There are several methods
for how the peer might learn the authenticator's name and public key:
<list style="symbols">
<t>The authenticator broadcasts its name and public key in system overhead
messages.
</t>
<t>The authenticator unicasts its name and public key to the peer in an
LTE Non-Access Stratum (NAS) message.
</t>
<t>The authenticator inserts its name and public key in the readable string
portion of an EAP Identity Request and/or after the null terminating character.
</t>
<t>The peer somehow learns the DNS name of the authenticator and looks up
the authenticator's key in the DNS using DNSSEC over an existing connection
to the Internet prior to attaching to the authenticator.
</t>
</list>
In the first three methods, the peer may obtain assurance that the key belongs
to the given name by making a DNS query as its very first action upon obtaining
Internet access through the authenticator.
</t>
<t>
We assume that the authenticator has access to the Internet and can retrieve
the key of the peer when it is given only the peer's DNS name during the authentication
process. Distributing keys out-of-band helps to reduce the size of the
authentication messages.
</t>
<t>The actual authentication process consists of a single message sent from the
peer to the authenticator. The message could be embedded in a NAS message
or an EAP Identity Response message destined to the authenticator. Upon
receiving and validating this message, the authenticator is able to derive
a Master Session Key (MSK) which will be securely bound to the pair of DNS
names given by both sides. The message from peer to authenticator would be
protected with an HMAC using the MSK derived by the peer. Upon validating
the authentication message, and if requested by the peer, the authenticator
may immediately begin the mobility management process outlined in
<xref target="sec_mobman"/>.
The authenticator may in parallel send a NAS
message or an EAP Success message indicating successful authentication.
The NAS message may be a Security Mode Command message that initializes the
over-the-air integrity protection and encryption. The EAP Success message
could trigger a lower layer key handshake as specified by IEEE 802.11i
<xref target="802.11"/>.
</t>
<t>The derivation of the MSK is depicted below in <xref target="fig_keys" />.
</t>
<figure align="center" anchor="fig_keys" title="The key derivation hierarchy for authentication and key agreement in one round-trip.">
<artwork align="center"><![CDATA[
peer __ ___authenticator
private key \ / private key
\ /
authenticator \ / peer
public key--+ | | +---public key
v v v v
ECDH ECDH
\ /
\ /
V V
Long-Term Shared Secret
(LTSS)
peer DNS __ | __authenticator DNS
name & length \_ | _/ name & length
\_ | _/
peer session \_ | _/ authenticator
nonce \ \ | / / session nonce
\ vvv /
\------> KDF <-----/
|
|
v
MSK
]]></artwork>
</figure>
<t>In the figure, we depict the two sides independently performing
Elliptic Curve Cofactor Diffie-Hellman (as specified in Section 5.7.1.2
of NIST SP 800-56A <xref target="NISTSP800-56A"/>). Each uses its own
private key and the public key of the other entity. Both sides should
arrive at the same value which they use as a Long-Term Shared Secret (LTSS).
The LTSS may be cached so that the expensive ECDH operation does not have
to be repeated when the same peer accesses the same authenticator in the
future.
</t>
<t>Next, we derive the MSK using a Key Derivation Function (KDF), taking
as input the LTSS, the identities of the two parties (the DNS names and
their lengths) as well as a session nonce from each party. The KDF should
also include a counter value (set to 1) and a unique string indicating
which function is calling the KDF. This will make the key derivation
compliant to Section 5.8.1 of NIST SP 800-56A <xref target="NISTSP800-56A"/>.
</t>
<t>The authenticator
may send a session nonce along with its public key in any of the four
ways outlined earlier; note that in the case of publication in the DNS,
the authenticator's session nonce would actually be re-used by incoming
sessions for a period of time. Session MSKs would still be independent
due to the entropy added by the peer in its own session nonce and by the
different LTSSs derived for different peers.
<list hangIndent="6" style="empty">
<t>If it turns out that it is unacceptable to re-use the authenticator's
nonce for more than one session, we will need to put an authenticator session
nonce into the response to the peer's single authentication message. This
response would trigger both sides to recompute MSK and to use it going forward.
This response message should be authenticated with an HMAC using a key derived
from either the first or second MSK to avoid denial-of-service attacks.
</t>
<t>Actually, it might be good to have such a "re-MSK" message available
to either side during the life of the session to enable re-fresh of the
MSK.
</t>
</list>
</t>
<t>The derivation of the LTSS and the execution of the KDF to generate the
MSK should be carried out in a secure environment, and both private keys
and the LTSS should be
stored in the secure environment so that they cannot be accessed except
by the authentication method. The MSK may also be kept in the secure
environment and an interface provided to derive further keys from it;
alternatively, the MSK may be distributed to the outside environment for
subsequent use. Historically, the secure environment has been implemented
inside tamper-proof hardware that is resistant to duplication ("cloning");
such hardware usually runs at a much lower clock speed than the general
purpose CPU that is used for other computing tasks. Because the ECDH operation
will require the support of the main CPU, we envision that hardware virtualization
support on the main CPU can be used to create a secure environment for the
generation, storage, and use of private keys and the LTSS.</t>
</section>
<section anchor="sec_synergy" title="Mobility Management and Authentication Working Together">
<t>As described in <xref target="sec_mobman"/>, it is the completion of the
authentication step that indicates
to the AR that the MN is authentic and that its traffic should be
redirected to the new point of attachment. Upon initial attachment, the MN
doesn't have any assigned IP address and must obtain one using DHCP. At the
same time, the DHCP server should assign the name of a Home Agent that can be used
by the MN when it leaves the area inside which a BGP UPDATE accomplishes the traffic
re-routing for the given address. The HA can be strategically placed at the boundary
of this region, introducing the least amount of latency once the MN puts it on the
forwarding path. The MN can perform a DNS lookup on the HA name to
retrieve the HA's public key and perform the derivation of an LTSS long in advance
of needing the HA's services. Messages could be provided so that the MN and HA
can develop an MSK without the HA sending a BGP UPDATE; this would avoid the need
to derive an MSK later when the Registration Request / Binding Update is actually
sent.
</t>
<t>We need some way of indicating to the MN
whether or not its old address(es) have been successfully re-routed or whether it
needs to perform a Mobile IP Registration Request / Binding Update to receive its traffic.
One way is to wait for the AR to send a Router Advertisement (RA). The RA should
contain all of those prefixes that were successfully re-routed by the AR sending
a BGP UPDATE. If any prefix is missing from this list, the MN should initiate
the Mobile IP Registration/Binding Update for those that are missing. However,
this may be too much overhead so it may be desirable to build in some indication
at the link layer (e.g., NAS signaling) when some prefixes were not able to be
re-routed.
</t>
<t>Existing LTE networks enable the MNs to remain in the idle state for many
mobility events. This is accomplished through the use of Tracking Area Lists,
and the MN does not need to update its location as long as it is within a Tracking
Area that is on the list it was last sent. We can also support this concept;
however, packets destined to the mobile node would always be routed to the AR
on which it was last authenticated. That AR would need to page the MN throughout
the Tracking Area List that it previously sent to the MN, and the MN would need
to attach to the currently serving AR and carry out authentication to obtain
these packets. The BGP UPDATE would reach the old AR which would then forward
the packets as normal. The Tracking Area Lists should be chosen to make a proper
tradeoff between the frequency of re-authentication and the size of the paging
areas, keeping in mind that the MN will need to re-authenticate itself to receive
packets at the current location.
</t>
<t>Caching of the LTSSs will play an important role in improving the performance
of our scheme. Each MN could retain the LTSS for many if not all of the ARs
it has previously visited, and the ARs could retain the LTSS for many of the
recently seen MNs. This makes the derivation of the MSK a very simple matter
of exchanging nonces and running the KDF.
</t>
</section>
<section anchor="sec_workplan" title="Workplan for IETF">
<t>The IETF should undertake the following:
<list style="numbers">
<t>In the DANE working group, add authenticator nonces to the DNS record format for bare
public keys.</t>
<t>Define a way to run the authentication protocol in this document over EAP.</t>
<t>In the DMM working group, define a way to run the authentication protocol in this
document over Mobile IP. This may or may not involve running EAP over Mobile IP.</t>
<t>When defining the authentication protocol either over EAP or MIP, define a flag
that allows the MN to control whether mobility management is immediately invoked
or not (i.e., allow for derivation of the MSK by both sides without necessarily
invoking mobility management).</t>
<t>Define a new DHCP option that carries a Home Agent DNS name.</t>
<t>Write an applicability statement and implementation guide for the use of BGP
to create host routes for host mobility.</t>
</list>
</t>
</section>
<section anchor="sec_IANA" title="IANA Considerations">
<t>This memo includes no request to IANA as of yet.</t>
</section>
<section anchor="sec_sec" title="Security Considerations">
<t>TBD</t>
</section>
<section anchor="sec_acks" title="Acknowledgements">
</section>
<!-- Possibly a 'Contributors' 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="Informative References">
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<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.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17491' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<reference anchor="BernsteinSpeed">
<front>
<title>Speed reports for elliptic-curve cryptography</title>
<author initials="D.J." surname="Bernstein" fullname="Daniel J. Bernstein">
</author>
</front>
<format type="HTML" target="http://cr.yp.to/ecdh/reports.html" />
</reference>
<reference anchor="Gaubatz05">
<front>
<title>State of the Art in Ultra-Low Power Public Key Cryptography for Wireless
Sensor Networks</title>
<author initials="G." surname="Gaubatz" fullname="Gunnar Gaubatz"></author>
<author initials="J.-P." surname="Kaps" fullname="Jens-Peter Kaps"></author>
<author initials="E." surname="Ozturk" fullname="Erdinc Ozturk"></author>
<author initials="B." surname="Sunar" fullname="Berk Sunar"></author>
<date year="2005" />
</front>
<seriesInfo name="2nd IEEE International Workshop on Pervasive Computing and
Communication Security (PerSec 2005)" value="" />
</reference>
<reference anchor='RFC4271'>
<front>
<title>A Border Gateway Protocol 4 (BGP-4)</title>
<author initials='Y.' surname='Rekhter' fullname='Y. Rekhter'>
<organization /></author>
<author initials='T.' surname='Li' fullname='T. Li'>
<organization /></author>
<author initials='S.' surname='Hares' fullname='S. Hares'>
<organization /></author>
<date year='2006' month='January' />
<abstract>
<t>This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.</t><t> The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.</t><t> BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.</t><t> This document obsoletes RFC 1771. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4271' />
<format type='TXT' octets='222702' target='http://www.rfc-editor.org/rfc/rfc4271.txt' />
</reference>
<reference anchor='RFC2796'>
<front>
<title abbrev='BGP Route Reflection'>BGP Route Reflection - An Alternative to Full Mesh IBGP</title>
<author initials='T.' surname='Bates' fullname='Tony Bates'>
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country></postal>
<email>tbates@cisco.com</email></address></author>
<author initials='R.' surname='Chandra' fullname='Ravi Chandra'>
<organization>Redback Networks Inc.</organization>
<address>
<postal>
<street>350 Holger Way</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country></postal>
<email>rchandra@redback.com</email></address></author>
<author initials='E.' surname='Chen' fullname='Enke Chen'>
<organization>Redback Networks Inc.</organization>
<address>
<postal>
<street>350 Holger Way</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country></postal>
<email>enke@redback.com</email></address></author>
<date year='2000' month='April' />
<abstract>
<t>The Border Gateway Protocolis an inter-autonomous system routing protocol designed for TCP/IP internets. Currently in the Internet BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed,.</t>
<t>This document describes the use and design of a method known as
"Route Reflection" to alleviate the the need for "full mesh" IBGP.</t></abstract></front>
<seriesInfo name='RFC' value='2796' />
<format type='TXT' octets='20174' target='http://www.rfc-editor.org/rfc/rfc2796.txt' />
</reference>
<reference anchor='RFC3046'>
<front>
<title>DHCP Relay Agent Information Option</title>
<author initials='M.' surname='Patrick' fullname='M. Patrick'>
<organization /></author>
<date year='2001' month='January' />
<abstract>
<t>Newer high-speed public Internet access technologies call for a high- speed modem to have a local area network (LAN) attachment to one or more customer premise hosts. It is advantageous to use the Dynamic Host Configuration Protocol (DHCP) as defined in RFC 2131 to assign customer premise host IP addresses in this environment. However, a number of security and scaling problems arise with such "public" DHCP use. This document describes a new DHCP option to address these issues. This option extends the set of DHCP options as defined in RFC 2132. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='3046' />
<format type='TXT' octets='30633' target='http://www.rfc-editor.org/rfc/rfc3046.txt' />
</reference>
<reference anchor='RFC5996'>
<front>
<title>Internet Key Exchange Protocol Version 2 (IKEv2)</title>
<author initials='C.' surname='Kaufman' fullname='C. Kaufman'>
<organization /></author>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'>
<organization /></author>
<author initials='Y.' surname='Nir' fullname='Y. Nir'>
<organization /></author>
<author initials='P.' surname='Eronen' fullname='P. Eronen'>
<organization /></author>
<date year='2010' month='September' />
<abstract>
<t>This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5996' />
<format type='TXT' octets='346466' target='http://www.rfc-editor.org/rfc/rfc5996.txt' />
</reference>
<reference anchor='RFC5246'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author initials='T.' surname='Dierks' fullname='T. Dierks'>
<organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
<organization /></author>
<date year='2008' month='August' />
<abstract>
<t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5246' />
<format type='TXT' octets='222395' target='http://www.rfc-editor.org/rfc/rfc5246.txt' />
</reference>
<reference anchor='RFC5280'>
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author initials='D.' surname='Cooper' fullname='D. Cooper'>
<organization /></author>
<author initials='S.' surname='Santesson' fullname='S. Santesson'>
<organization /></author>
<author initials='S.' surname='Farrell' fullname='S. Farrell'>
<organization /></author>
<author initials='S.' surname='Boeyen' fullname='S. Boeyen'>
<organization /></author>
<author initials='R.' surname='Housley' fullname='R. Housley'>
<organization /></author>
<author initials='W.' surname='Polk' fullname='W. Polk'>
<organization /></author>
<date year='2008' month='May' />
<abstract>
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5280' />
<format type='TXT' octets='352580' target='http://www.rfc-editor.org/rfc/rfc5280.txt' />
</reference>
<reference anchor='RFC2560'>
<front>
<title abbrev='PKIX OCSP'>X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP</title>
<author initials='M.' surname='Myers' fullname='Michael Myers'>
<organization>VeriSign, Inc.</organization>
<address>
<postal>
<street>1350 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country></postal>
<email>mmyers@verisign.com</email></address></author>
<author initials='R.' surname='Ankney' fullname='Rich Ankney'>
<organization>CertCo, LLC</organization>
<address>
<postal>
<street>13506 King Charles Dr.</street>
<city>Chantilly</city>
<region>VA</region>
<code>20151</code>
<country>US</country></postal>
<email>rankney@erols.com</email></address></author>
<author initials='A.' surname='Malpani' fullname='Ambarish Malpani'>
<organization>ValiCert, Inc.</organization>
<address>
<postal>
<street>1215 Terra Bella Avenue</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country></postal>
<phone>+1 650 567 5457</phone>
<email>ambarish@valicert.com</email></address></author>
<author initials='S.' surname='Galperin' fullname='Slava Galperin'>
<organization>My CFO, Inc.</organization>
<address>
<postal>
<street>1945 Charleston Road</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country></postal>
<email>galperin@mycfo.com</email></address></author>
<author initials='C.' surname='Adams' fullname='Carlisle Adams'>
<organization>Entrust Technologies</organization>
<address>
<postal>
<street>750 Heron Road</street>
<street>Suite E08</street>
<city>Ottawa</city>
<region>Ontario</region>
<code>K1V 1A7</code>
<country>CA</country></postal>
<email>cadams@entrust.com</email></address></author>
<date year='1999' month='June' />
<abstract>
<t>This document specifies a protocol useful in determining the current
status of a digital certificate without requiring CRLs. Additional
mechanisms addressing PKIX operational requirements are specified in
separate documents.</t>
<t>An overview of the protocol is provided in section 2. Functional
requirements are specified in section 4. Details of the protocol are
in section 5. We cover security issues with the protocol in section
6. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1
syntactic elements and appendix C specifies the mime types for the
messages.</t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document (in uppercase, as shown) are to be interpreted as described
in.</t></abstract></front>
<seriesInfo name='RFC' value='2560' />
<format type='TXT' octets='43243' target='http://www.rfc-editor.org/rfc/rfc2560.txt' />
</reference>
<reference anchor='I-D.ietf-dane-protocol'>
<front>
<title>Using Secure DNS to Associate Certificates with Domain Names For TLS</title>
<author initials='P' surname='Hoffman' fullname='Paul Hoffman'>
<organization />
</author>
<author initials='J' surname='Schlyter' fullname='Jakob Schlyter'>
<organization />
</author>
<date month='February' day='8' year='2012' />
<abstract><t>TLS and DTLS use PKIX certificates for authenticating the server. Users want their applications to verify that the certificate provided by the TLS server is in fact associated with the domain name they expect. TLSA provides bindings of keys to domains that are asserted not by external entities, but by the entities that operate the DNS. This document describes how to use secure DNS to associate the TLS server's certificate with the intended domain name.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-dane-protocol-16' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-16.txt' />
</reference>
<reference anchor='I-D.hoffman-dane-smime'>
<front>
<title>Using Secure DNS to Associate Certificates with Domain Names For S/MIME</title>
<author initials='P' surname='Hoffman' fullname='Paul Hoffman'>
<organization />
</author>
<author initials='J' surname='Schlyter' fullname='Jakob Schlyter'>
<organization />
</author>
<date month='August' day='22' year='2011' />
<abstract><t>S/MIME uses certificates for authenticating and encrypting messages. Users want their mail user agents to securely associate a certificate with the sender of an encrypted and/or signed message. DNSSEC provides a mechanism for a zone operator to sign DNS information directly. This way, bindings of certificates to users within a domain are asserted not by external entities, but by the entities that operate the DNS. This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name. IMPORTANT NOTE: This draft is intentionally sketchy. It is meant as a possible starting point for the DANE WG if it wants to consider making a protocol similar to TLSA, as described in draft-ietf-dane-protocol, but that applies to S/MIME. The WG may or may not want to adopt such work, or if it does, may want to use a very different scheme from the one described here.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-hoffman-dane-smime-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hoffman-dane-smime-01.txt' />
</reference>
<reference anchor='I-D.wouters-tls-oob-pubkey'>
<front>
<title>TLS out-of-band public key validation</title>
<author initials='P' surname='Wouters' fullname='Paul Wouters'>
<organization />
</author>
<author initials='J' surname='Gilmore' fullname='John Gilmore'>
<organization />
</author>
<author initials='S' surname='Weiler' fullname='Samuel Weiler'>
<organization />
</author>
<author initials='T' surname='Kivinen' fullname='Tero Kivinen'>
<organization />
</author>
<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
<organization />
</author>
<date month='November' day='17' year='2011' />
<abstract><t>This document specifies a new TLS certificate type for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) for use with out-of-band authentication. Currently, TLS authentication can only occur via PKIX or OpenPGP certificates. By specifying a minimum resource for raw public key exchange, implementations can use alternative authentication methods. One such method is using DANE Resource Records secured by DNSSEC, Another use case is to provide authentication functionality when used with devices in a constrained environment that use whitelists and blacklists, as is the case with sensors and other embedded devices that are constrained by memory, computational, and communication limitations where the usage of PKIX is not feasible. The new certificate type specified can also be used to reduce the latency of a TLS client that is already in possession of a validated public key of the TLS server before it starts a (non-resumed) TLS handshake.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-wouters-tls-oob-pubkey-02' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-wouters-tls-oob-pubkey-02.txt' />
</reference>
<reference anchor='RFC3748'>
<front>
<title>Extensible Authentication Protocol (EAP)</title>
<author initials='B.' surname='Aboba' fullname='B. Aboba'>
<organization /></author>
<author initials='L.' surname='Blunk' fullname='L. Blunk'>
<organization /></author>
<author initials='J.' surname='Vollbrecht' fullname='J. Vollbrecht'>
<organization /></author>
<author initials='J.' surname='Carlson' fullname='J. Carlson'>
<organization /></author>
<author initials='H.' surname='Levkowetz' fullname='H. Levkowetz'>
<organization /></author>
<date year='2004' month='June' />
<abstract>
<t>This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='3748' />
<format type='TXT' octets='157994' target='http://www.rfc-editor.org/rfc/rfc3748.txt' />
</reference>
<reference anchor="802.11">
<front>
<title>
Draft Standard for
Information Technology -
Telecommunications and information
exchange between systems -
Local and metropolitan area networks
Specific requirements -
Part 11: Wireless LAN Medium Access Control (MAC)
and Physical Layer (PHY) specifications
</title>
<author />
<date year="2006" />
</front>
<seriesInfo name="IEEE" value="802.11-REVma" />
</reference>
<reference anchor="NISTSP800-56A"
target="http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf">
<front>
<title>Recommendation for Pair-Wise
Key Establishment Schemes
Using Discrete Logarithm
Cryptography
(Revised)</title>
<author initials="E." surname="Barker" fullname="Elaine Barker"></author>
<author initials="D." surname="Johnson" fullname="Don Johnson"></author>
<author initials="M." surname="Smid" fullname="Miles Smid"></author>
<date month="March" year="2007" />
</front>
<seriesInfo name="NIST Special Publication" value="800-56A" />
</reference>
</references>
<!-- Change Log
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:47:29 |