One document matched: draft-nir-tls-eap-08.xml
<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='./rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="no"?>
<?rfc compact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >
<?xml-stylesheet type='text/xsl' href='./rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="no" ?>
<?rfc subcompact="yes" ?>
<?rfc sortrefs="yes" ?>
<rfc ipr="trust200902" docName="draft-nir-tls-eap-08" category="std">
<front>
<title abbrev="EAP-in-TLS">TLS using EAP Authentication</title>
<author initials="Y." surname="Nir" fullname="Yoav Nir">
<organization abbrev="Check Point">Check Point Software Technologies Ltd.</organization>
<address>
<postal>
<street>5 Hasolelim st.</street>
<city>Tel Aviv</city>
<code>67897</code>
<country>Israel</country>
</postal>
<email>ynir@checkpoint.com</email>
</address>
</author>
<author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">
<organization abbrev="Independent">Independent</organization>
<address>
<email>yaronf.ietf@gmail.com</email>
</address>
</author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization abbrev="NSN">Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<author initials="P." surname="Gutmann" fullname="Peter Gutmann">
<organization abbrev="University of Auckland">University of Auckland</organization>
<address>
<postal>
<street>Department of Computer Science</street>
<city>University of Auckland</city>
<city>Auckland</city>
<country>New Zealand</country>
</postal>
<email>pgut001@cs.auckland.ac.nz</email>
</address>
</author>
<date year="2010"/>
<area>Security Area</area>
<workgroup>TLS Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t> This document describes an extension to the TLS protocol to allow TLS clients to
authenticate with legacy credentials using the Extensible Authentication Protocol (EAP).</t>
<t> This work follows the example of IKEv2, where EAP has been added to the protocol to allow
clients to use different credentials such as passwords, token cards, and shared secrets.</t>
</abstract>
</front>
<middle>
<!-- ====================================================================== -->
<section anchor="introduction" title="Introduction">
<t> This document describes a new extension to <xref target="TLS"/>. This extension
allows a TLS client to authenticate using <xref target="EAP"/> instead of performing the
authentication at the application level. The extension follows <xref target="TLS-EXT"/>.
For the remainder of this document we will refer to this extension as TEE (TLS with EAP
Extension).</t>
<t> TEE extends the TLS handshake beyond the regular setup, to allow the EAP protocol to
run between the TLS server (called an "authenticator" in EAP) and the TLS client (called a
"supplicant"). This allows the TLS architecture to handle client authentication before
exposing the server application software to an unauthenticated client. In doing this, we
follow the approach taken for IKEv2 in <xref target="RFC4306"/>.
However, similar to regular TLS, we protect the user identity by only sending the client
identity after the server has authenticated. In this our solution differs from that of
IKEv2.</t>
<t> Currently used applications that rely on non-certificate user credentials use TLS
to authenticate the server only. After that, the application takes over, and presents a
login screen where the user is expected to present their credentials.</t>
<t> This creates several problems. It allows a client to access the application before
authentication, thus creating a potential for anonymous attacks on non-hardened
applications. Additionally, web pages are not particularly well suited for long shared
secrets and for interfacing with certain devices such as USB tokens.</t>
<t> TEE allows full mutual authentication to occur for all these applications within the TLS
exchange. The application receives control only when the user is identified and authenticated. The
authentication can be built into the server infrastructure by connecting to an AAA server. The client
side can be integrated into client software such as web browsers and mail clients. An EAP infrastructure
is already built into some operating systems providing a user interface for each authentication
method within EAP.</t>
<t>We intend TEE to be used for various protocols that use TLS such as HTTPS, in cases where
certificate based client authentication is not practical. This includes web-based mail
services, online banking, premium content websites and mail clients.</t>
<t>Another class of applications that may see benefit from TEE are TLS based VPN clients used
as part of so-called "SSL VPN" products. No such client protocols have so far been
standardized.</t>
<section anchor="eap_app" title="EAP Applicability">
<t>Section 1.3 of <xref target="EAP"/> states that EAP is only applicable for network access
authentication, rather than for "bulk data transfer". It then goes on to explain why the
transport properties of EAP indeed make it unsuitable for bulk data transfer, e.g. for
large file transport. Our proposed use of EAP falls squarely within the applicability as
defined, since we make no further use of EAP beyond access authentication.</t>
</section>
<section anchor="alternatives" title="Comparison with Design Alternatives">
<t>It has been suggested to implement EAP authentication as part of the protected application,
rather than as part of the TLS handshake. A BCP document could be used to describe a
secure way of doing this. The drawbacks we see in such an approach are listed below:<list style="symbols">
<t>EAP does not have a pre-defined transport method. Application designers would need
to specify an EAP transport for each application. Making this a part of TLS has
the benefit of a single specification for all protected applications.</t>
<t>The integration of EAP and TLS is security-sensitive and should be standardized and
interoperable. We do not believe that it should be left to application designers to
do this in a secure manner. Specifically on the server-side, integration with AAA
servers adds complexity and is more naturally part of the underlying infrastrcture.</t>
<t>Our current proposal provides channel binding between TLS and EAP, to counter the MITM
attacks described in <xref target="MITM"/>. TLS does not provide any standard way of
extracting cryptographic material from the TLS state, and in most implementations, the
TLS state is not exposed to the protected application. Because of this, it is difficult
for application designers to bind the user authentication to the protected channel
provided by TLS.</t>
</list></t>
</section>
<section anchor="mustshouldmay" title="Conventions Used in This Document">
<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"/>.</t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="usecase" title="Operating Environment">
<t> TEE will work between a client application and a server application, performing either
client authentication or mutual authentication within the TLS exchange.<figure>
<artwork><![CDATA[
Client Server
+-------------------------+ +------------------------+
| |GUI| | Client | |TLS+-+-----+-+TLS| |Server | |
| +-^-+ |Software| +-^-+ | +-+-^-+ |Application | |
| | +--------+ | | | | |Software | |
| | | | | | +------------+ |
| +-v----------------v-+ | | | |
| | EAP | | +---|--------------------+
| | Infrastructure | | |
| +--------------------+ | | +--------+
+-------------------------+ | | AAA |
| | Server |
+----- |
+--------+
]]></artwork>
</figure></t>
<t> The above diagram shows the typical deployment. The client has software that either includes
a UI for some EAP methods, or else is able to invoke some operating system EAP infrastructure
that takes care of the user interaction. The server is configured with the address and protocol
of the AAA server. Typically the AAA server communicates using the RADIUS protocol with EAP
(<xref target="RADIUS"/> and <xref target="RAD-EAP"/>), or the Diameter protocol
(<xref target="Diameter"/> and <xref target="Dia-EAP"/>).</t>
<t> As stated in the introduction, we expect TEE to be used in both browsers
and applications. Further uses may be authentication and key generation for other protocols, and
tunneling clients, which so far have not been standardized.</t>
</section>
<!-- ====================================================================== -->
<section anchor="protocol" title="Protocol Overview">
<t> When TLS is used with EAP, additional records are sent after the ChangeCipherSpec protocol
message and before the Finished message, effectively creating an extended handshake before the
application layer data can be sent. Each EapMsg handshake record contains exactly one EAP message.
Using EAP for client authentication allows TLS to be used with various AAA back-end servers such
as RADIUS or Diameter.</t>
<t> TLS with EAP may be used for securing a data connection such as HTTP or POP3. We believe it
has three main benefits:<list style="symbols">
<t> The ability of EAP to work with backend servers can remove that burden from the application
layer.</t>
<t> Moving the user authentication into the TLS handshake protects the presumably less secure
application layer from attacks by unauthenticated parties.</t>
<t> Using mutual authentication methods within EAP can help thwart certain classes of phishing
attacks.</t></list></t>
<t> The TEE extension defines the following: <list style="symbols">
<t>A new extension type called tee_supported, used to indicate that the communicating
application (either client or server) supports this extension.</t>
<t>A new message type for the handshake protocol, called InterimAuth, which is used to sign
previous messages.</t>
<t>A new message type for the handshake protocol, called EapMsg, which is used to carry a single
EAP message.</t></list></t>
<t> The diagram below outlines the protocol structure. For illustration purposes only, we
use the GPSK EAP method <xref target="EAP-GPSK"/>.<figure>
<artwork><![CDATA[
Client Server
------ ------
ClientHello(*) -------->
ServerHello(*)
(Certificate)
ServerKeyExchange
EapMsg(Identity-Request)
<-------- ServerHelloDone
ClientKeyExchange
(CertificateVerify)
ChangeCipherSpec
InterimAuth
EapMsg(Identity-Reply) -------->
ChangeCipherSpec
InterimAuth
EapMsg(GPSK-Request)
<--------
EapMsg(GPSK-Reply) -------->
EapMsg(GPSK-Request)
<--------
EapMsg(GPSK-Reply) -------->
EapMsg(Success)
<-------- Finished
Finished -------->
(*) The ClientHello and ServerHello include the tee_supported
extension to indicate support for TEE
]]></artwork>
</figure></t>
<t> The client indicates in the first message its support for TEE. The server sends an EAP
identity request in the reply. The client sends the identity reply after the handshake completion.
The EAP request-response sequence continues until the client is either authenticated or rejected.</t>
<section anchor="eaptls_ind" title="The tee_supported Extension">
<t> The tee_supported extension is a ClientHello and ServerHello extension as defined in
section 2.3 of <xref target="TLS-EXT"/>.
The extension_type field is TBA by IANA. The extension_data is zero-length.</t>
</section>
<section anchor="eaptls_interim" title="The InterimAuth Handshake Message">
<t> The InterimAuth message is identical in syntax to the Finished message described in section 7.4.9
of <xref target="TLS"/>. It is calculated in exactly the same way.</t>
<t> The semantics, however, are somewhat different. The "Finished" message indicates that application
data may now be sent. The "InterimAuth" message does not indicate this. Instead, further handshake messages
are needed.</t>
<t> The HandshakeType value for the InterimAuth handshake message is TBA by IANA.</t>
</section>
<section anchor="eaptls_eap" title="The EapMsg Handshake Message">
<t> The EapMsg handshake message carries exactly one EAP message as defined in
<xref target="EAP"/>.</t>
<t> The HandshakeType value for the EapMsg handshake message is TBA by IANA.</t>
<t> The EapMsg message is used to tunnel EAP messages between the authentication server, which
may be co-located with the TLS server, or else may be a separate AAA server, and the
supplicant, which is co-located with the TLS client. TLS on either side receives the EAP
data from the EAP infrastructure, and treats it as opaque. TLS does not make any changes
to the EAP payload or make any decisions based on the contents of an EapMsg handshake
message.</t>
<t> Note that it is expected that the authentication server notifies the TLS server about
authentication success or failure, and so TLS need not inspect the eap_payload within
the EapMsg to detect success or failure.
<figure>
<artwork><![CDATA[
struct {
opaque eap_payload[4..65535];
} EapMsg;
]]></artwork>
</figure></t>
<t> eap_payload is defined in section 4 of RFC 3748. It includes the Code, Identifier, Length
and Data fields of the EAP packet.</t>
</section>
<section anchor="MSK_finished" title="Calculating the Finished message">
<t>If the EAP method is key-generating (see <xref target="I-D.ietf-eap-keying"/>), the Finished message is
calculated as follows:
<figure>
<artwork><![CDATA[
struct {
opaque verify_data[12];
} Finished;
verify_data
PRF(MSK, finished_label, MD5(handshake_messages) +
SHA-1(handshake_messages)) [0..11];
]]></artwork>
</figure></t>
<t>The finished_label and the PRF are as defined in section 7.4.9 of <xref target="TLS"/>.</t>
<t>The handshake_messages field, unlike regular TLS, does not sign all the data in the
handshake. Instead it signs all the data that has not been signed by the previous
InterimAuth message. The handshake_messages field includes all of the octets beginning
with and including the InterimAuth message, up to but not including this Finished message.
This is the concatenation of all the Handshake structures exchanged thus far, and not yet
signed, as defined in section 7.4 of <xref target="TLS"/>and in this document.</t>
<t>The Master Session Key (MSK) is derived by the AAA server and by the client if the EAP
method is key-generating. On the server-side, it is typically received from the AAA
server over the RADIUS or Diameter protocol. On the client-side, it is passed to TLS by
some other method.</t>
<t>If the EAP method is not key-generating, then the master_secret is used to sign the
messages instead of the MSK. For a discussion on the use of such methods, see
<xref target="signing"/>.</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<section anchor="signing" title="InterimAuth vs. Finished">
<t>In regular TLS, the Finished message provides two functions: it signs all preceding
messages, and it signals that application data can now be sent. In TEE, it only signs
those messages that have not yet been signed.</t>
<t>Some EAP methods, such as EAP-TLS, EAP-IKEv2 and EAP-SIM generate keys in addition
to authenticating clients. Such methods are said to be resistant to man-in-the-middle
(MITM) attacks as discussed in <xref target="MITM"/>. Such methods are called
key-generating methods.</t>
<t>To realize the benefit of such methods, we need to verify the key that was generated within
the EAP method. This is referred to as the MSK in EAP. In TEE, the InterimAuth
message signs all previous messages with the master_secret, just like the Finished
message in regular TLS. The Finished message signs the rest of the messages using the MSK
if such exists. If not, then the messages are signed with the master_secret as in regular
TLS.</t>
<t>The need for signing twice arises from the fact that we need to use both the master_secret
and the MSK. It was possible to use just one Finished record and blend the MSK into
the master_secret. However, this would needlessly complicate the
protocol and make security analysis more difficult. Instead, we have decided to follow
the example of IKEv2, where two AUTH payloads are exchanged.</t>
<t>It should be noted that using non-key-generating methods may expose the client to a
MITM attack if the same method and credentials are used in some other situation, in which
the EAP is done outside of a protected tunnel with an authenticated server. Unless it can be
determined that the EAP method is never used in such a situation, non-key-generating
methods SHOULD NOT be used. This issue is discussed extensively in <xref target='Compound-Authentication'/>.</t>
</section>
<section anchor="iprotection" title="Identity Protection">
<t> Unlike <xref target="TLS-PSK"/>, TEE provides identity protection for the client.
The client's identity is hidden from a passive eavesdropper using TLS encryption. Active
attacks are discussed in <xref target="mauthentication"/>.</t>
<t> We could save one round-trip by having the client send its identity within the Client
Hello message. This is similar to TLS-PSK. However, we believe that identity protection
is a worthy enough goal, so as to justify the extra round-trip.</t>
</section>
<section anchor="mauthentication" title="Mutual Authentication">
<t> In order to achieve our security goals, we need to have both the server and the client
authenticate. Client authentication is obviously done using the EAP method. The server
authentication can be done in either of two ways:<list style="numbers">
<t>The client can verify the server certificate. This may work well depending on the
scenario, but implies that the client or its user can recognize the right DN or
alternate name, and distinguish it from plausible alternatives. The introduction to
<xref target="I.D.Webauth-phishing"/> shows that at least in HTTPS, this is not always
the case.</t>
<t>The client can use a mutually authenticated (MA) EAP method such as GPSK.
In this case, server certificate verification does not matter, and the TLS handshake may
as well be anonymous. Note that in this case, the client identity is sent to the server
before server authentication.</t></list></t>
<t>To summarize: <list style="symbols">
<t>Clients MUST NOT propose anonymous ciphersuites, unless they support MA EAP methods.</t>
<t>Clients MUST NOT accept non-MA methods if the ciphersuite is anonymous.</t>
<t>Clients MUST NOT accept non-MA methods if they are not able to verify the server credentials.
Note that this document does not define what verification involves. If the server DN is
known and stored on the client, verifying certificate signature and checking revocation
may be enough. For web browsers, the case is not as clear cut, and MA methods SHOULD be used.</t>
</list></t>
</section>
</section>
<section anchor="performance" title="Performance Considerations">
<t>Regular TLS adds two round-trips to a TCP connection. However, because of the stream
nature of TCP, the client does not really need to wait for the server's Finished message,
and can begin sending application data immediately after its own Finished message. In
practice, many clients do so, and TLS only adds one round-trip of delay.</t>
<t>TEE adds as many round-trips as the EAP method requires. For example, EAP-MD5
requires 1 round-trip, while EAP-GPSK requires 2 round-trips. Additionally, the client
MUST wait for the EAP-Success message before sending its own Finished message, so we
need at least 3 round-trips for the entire handshake. The best a client can do is two
round-trips plus however many round-trips the EAP method requires.</t>
<t>It should be noted, though, that these extra round-trips save processing time at the
application level. Two extra round-trips take a lot less time than presenting a log-in
web page and processing the user's input.</t>
<t>It should also be noted, that TEE reverses the order of the Finished messages. In
regular TLS the client sends the Finished message first. In TEE it is the server
that sends the Finished message first. This should not affect performance, and it is
clear that the client may send application data immediately after the Finished message.</t>
</section>
<section anchor="opcons" title="Operational Considerations">
<t><xref target="mauthentication"/> defines a dependency between the TLS state and the EAP
state in that it mandates that certain EAP methods should not be used with certain TLS
ciphersuites. To avoid such dependencies, there are two approaches that implementations
can take. They can either not use any anonymous ciphersuites, or else they can use only MA
EAP methods.</t>
<t>Where certificate validation is problematic, such as in browser-based HTTPS, we recommend
the latter approach.</t>
<t>In cases where the use of EAP within TLS is not known before opening the connection,
it is necessary to consider the implications of requiring the user to type in credentials
after the connection has already started. TCP sessions may time out, because of security
considerations, and this may lead to session setup failure.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>IANA is asked to assign an extension type value from the "ExtensionType Values" registry
for the tee_supported extension.</t>
<t>IANA is asked to assign two handshake message types from the "TLS HandshakeType Registry",
one for "EapMsg" and one for "InterimAuth".</t>
</section>
<section anchor="ia" title="Acknowledgments">
<t>The authors would like to thank Josh Howlett for his comments.</t>
<t>The TLS Inner Application Extension work (<xref target="TLS/IA"/>) has inspired the
authors to create this simplified work. TLS/IA provides a somewhat different approach to
integrating non-certificate credentials into the TLS protocol, in addition to several
other features available from the RADIUS namespace.</t>
<t>The authors would also like to thank the various contributors to <xref target="RFC4306"/>
whose work inspired this one.</t>
</section>
<section anchor="delta" title="Changes from Previous Versions">
<section anchor="delta_02" title="Changes in version -02">
<t><list style="symbols">
<t>Added discussion of alternative designs.</t>
</list></t>
</section>
<section anchor="delta_01" title="Changes in version -01">
<t><list style="symbols">
<t>Changed the construction of the Finished message</t>
<t>Replaced MS-CHAPv2 with GPSK in examples.</t>
<t>Added open issues section.</t>
<t>Added reference to <xref target='Compound-Authentication'/></t>
<t>Fixed reference to MITM attack</t>
</list></t>
</section>
<section anchor="delta_pm" title="Changes from the protocol model draft">
<t><list style="symbols">
<t>Added diagram for EapMsg</t>
<t>Added discussion of EAP applicability</t>
<t>Added discussion of mutually-authenticated EAP methods vs other methods in the security
considerations.</t>
<t>Added operational considerations.</t>
<t>Other minor nits.</t>
</list></t>
</section>
</section>
<section anchor="questions" title="Open Issues">
<t>
Some have suggested that since the protocol is identical to regular TLS up to the
InterimAuth message, we should call that the Finished message, and call the last
message in the extended handshake something like "EapFinished". This has the advantage that
the construction of Finished is already well defined and will not change. However, the
Finished message has a specific meaning as indicated by its name. It means that the handshake
is over and that application data can now be sent. This is not true of what is in this draft
called InterimAuth. We'd like the opinions of reviewrs about this issue.
</t>
<t>
The MSK from the EAP exchange is only used to sign the Finished message. It is not used again
in the data encryption. In this we followed the example of IKEv2. The reason is that TLS
already has perfectly good ways of exchanging keys, and we do not need this capability from
EAP methods. Also, using the MSK in keys would require an additional ChangeCipherSpec and
would complicate the protocol. We'd like the opinions of reviewrs about this issue.
</t>
<t>
Another response we got was that we should have a MUST requirement that only mutually
authenticated and key-generating methods be used in TEE. This would simplify the security
considerations section. While we agree that this is a good idea, most EAP methods in
common use are not compliant. Additionally, such requirements assume that EAP packets are
visible to a passive attacker. As EAP is used in protected tunnels such as in L2TP, in IKEv2
and here, this assumption may not be required. If we consider the server authenticated by
its certificate, it may be acceptable to use a non-MA method.
</t>
<t>
It has been suggested that identity protection is not important enough to add a roundtrip,
and so we should have the client send the username in the ClientHello. We are not sure
about how others feel about this, and would like to solicit the reviewers opinion. Note
that if this is done, the client sends the user name before ever receiving any indication
that the server actually supports TEE. This might be acceptable in an email client, where
the server is preconfigured, but it may be unacceptable in other uses, such as web browsers.
</t>
</section>
<!-- ====================================================================== -->
</middle>
<!-- ====================================================================== -->
<back>
<references title="Normative References">
<reference anchor='TLS'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.1</title>
<author initials='T.' surname='Dierks' fullname='T. Dierks'>
<organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
<organization /></author>
<date year='2006' month='April' />
<abstract><t>This document specifies Version 1.1 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='4346' />
<format type='TXT' octets='187041' target='http://www.ietf.org/rfc/rfc4346.txt' />
</reference>
<reference anchor='TLS-EXT'>
<front>
<title>Transport Layer Security (TLS) Extensions</title>
<author initials='S.' surname='Blake-Wilson' fullname='S. Blake-Wilson'>
<organization /></author>
<author initials='M.' surname='Nystrom' fullname='M. Nystrom'>
<organization /></author>
<author initials='D.' surname='Hopwood' fullname='D. Hopwood'>
<organization /></author>
<author initials='J.' surname='Mikkelsen' fullname='J. Mikkelsen'>
<organization /></author>
<author initials='T.' surname='Wright' fullname='T. Wright'>
<organization /></author>
<date year='2006' month='April' />
<abstract><t>This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms.</t><t> The extensions may be used by TLS clients and servers. The extensions are backwards compatible: communication is possible between TLS clients that support the extensions and TLS servers that do not support the extensions, and vice versa. [STANDARDS TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4366' />
<format type='TXT' octets='66344' target='http://www.ietf.org/rfc/rfc4366.txt' />
</reference>
<reference anchor='EAP'>
<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.ietf.org/rfc/rfc3748.txt' />
</reference>
<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>
</front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='ftp://ftp.isi.edu/in-notes/rfc2119.txt' />
<format type='HTML' octets='16553' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5703' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
</references>
<references title="Informative References">
<reference anchor="MITM">
<front>
<title>Man-in-the-Middle in Tunneled Authentication Protocols</title>
<author fullname="N. Asokan" initials="N" surname="Asokan">
<organization abbrev="Nokia"> Nokia Research Center </organization>
</author>
<author fullname="Valtteri Niemi" initials="V" surname="Niemi">
<organization abbrev="Nokia"> Nokia Research Center </organization>
</author>
<author fullname="Kaisa Nyberg" initials="K" surname="Nyberg">
<organization abbrev="Nokia"> Nokia Research Center </organization>
</author>
<date month="October" year="2002"/>
</front>
<seriesInfo name="IACR ePrint Archive" value=""/>
<format type='PDF' octets='462921' target='http://eprint.iacr.org/2002/163.pdf' />
</reference>
<reference anchor='RADIUS'>
<front>
<title>Remote Authentication Dial In User Service (RADIUS)</title>
<author initials='C.' surname='Rigney' fullname='C. Rigney'>
<organization /></author>
<author initials='S.' surname='Willens' fullname='S. Willens'>
<organization /></author>
<author initials='A.' surname='Rubens' fullname='A. Rubens'>
<organization /></author>
<author initials='W.' surname='Simpson' fullname='W. Simpson'>
<organization /></author>
<date year='2000' month='June' />
<abstract><t>This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS TRACK] </t></abstract>
</front>
<seriesInfo name='RFC' value='2865' />
<format type='TXT' octets='146456' target='http://www.ietf.org/rfc/rfc2865.txt' />
</reference>
<reference anchor='RAD-EAP'>
<front>
<title>RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)</title>
<author initials='B.' surname='Aboba' fullname='B. Aboba'>
<organization /></author>
<author initials='P.' surname='Calhoun' fullname='P. Calhoun'>
<organization /></author>
<date year='2003' month='September' />
<abstract><t>This document defines Remote Authentication Dial In User Service (RADIUS) support for the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication mechanisms. In the proposed scheme, the Network Access Server (NAS) forwards EAP packets to and from the RADIUS server, encapsulated within EAP-Message attributes. This has the advantage of allowing the NAS to support any EAP authentication method, without the need for method- specific code, which resides on the RADIUS server. While EAP was originally developed for use with PPP, it is now also in use with IEEE 802. This memo provides information for the Internet community. </t></abstract>
</front>
<seriesInfo name='RFC' value='3579' />
<format type='TXT' octets='104469' target='http://www.ietf.org/rfc/rfc3579.txt' />
</reference>
<reference anchor='TLS/IA'>
<front>
<title>TLS Inner Application Extension (TLS/IA)</title>
<author initials='P' surname='Funk' fullname='Paul Funk'><organization /></author>
<author initials='S' surname='Blake-Wilson' fullname='Simon Blake-Wilson'><organization /></author>
<author initials='H' surname='Smith' fullname='Ned Smith'><organization /></author>
<author initials='N' surname='Tschofenig' fullname='Hannes Tschofenig'><organization /></author>
<author initials='T' surname='Hardjono' fullname='Thomas Hardjono'><organization /></author>
<date month='June' day='28' year='2006' />
<abstract><t>This document defines a new TLS extension called "Inner Application". When TLS is used with the Inner Application extension (TLS/IA), additional messages are exchanged after completion of the TLS handshake, in effect providing an extended handshake prior to the start of upper layer data communications. Each TLS/IA message contains an encrypted sequence of Attribute-Value-Pairs (AVPs) from the RADIUS/Diameter namespace. Hence, the AVPs defined in RADIUS and Diameter have the same meaning in TLS/AI; that is, each attribute code point refers to the same logical attribute in any of these protocols. Arbitrary "applications" may be implemented using the AVP exchange. Possible applications include EAP or other forms of user authentication, client integrity checking, provisioning of additional tunnels, and the like. Use of the RADIUS/Diameter namespace provides natural compatibility between TLS/IA applications and widely deployed AAA infrastructures. It is anticipated that TLS/IA will be used with and without subsequent protected data communication within the tunnel established by the handshake. For example, TLS/IA may be used to secure an HTTP data connection, allowing more robust password-based user authentication to occur than would otherwise be possible using mechanisms available in HTTP. TLS/IA may also be used for its handshake portion alone; for example, EAP-TTLSv1 encapsulates a TLS/IA handshake in EAP as a means to mutually authenticate a client and server and establish keys for a separate data connection.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-funk-tls-inner-application-extension-03' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-funk-tls-inner-application-extension-03.txt' />
</reference>
<reference anchor='TLS-PSK'>
<front>
<title>Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)</title>
<author initials='P.' surname='Eronen' fullname='P. Eronen'>
<organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'>
<organization /></author>
<date year='2005' month='December' />
<abstract><t>This document specifies three sets of new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys (PSKs). These pre-shared keys are symmetric keys, shared in advance among the communicating parties. The first set of ciphersuites uses only symmetric key operations for authentication. The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key, and the third set combines public key authentication of the server with pre-shared key authentication of the client. [STANDARDS TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4279' />
<format type='TXT' octets='32160' target='http://www.ietf.org/rfc/rfc4279.txt' />
</reference>
<reference anchor='RFC4306'>
<front>
<title>Internet Key Exchange (IKEv2) Protocol</title>
<author initials='C.' surname='Kaufman' fullname='C. Kaufman'>
<organization /></author>
<date year='2005' month='December' />
<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).</t><t> This version of the IKE specification combines the contents of what were previously separate documents, including Internet Security Association and Key Management Protocol (ISAKMP, RFC 2408), IKE (RFC 2409), the Internet Domain of Interpretation (DOI, RFC 2407), Network Address Translation (NAT) Traversal, Legacy authentication, and remote address acquisition.</t><t> Version 2 of IKE does not interoperate with version 1, but it has enough of the header format in common that both versions can unambiguously run over the same UDP port. [STANDARDS TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4306' />
<format type='TXT' octets='250941' target='http://www.ietf.org/rfc/rfc4306.txt' />
</reference>
<reference anchor='Diameter'>
<front>
<title>Diameter Base Protocol</title>
<author initials='P.' surname='Calhoun' fullname='P. Calhoun'>
<organization /></author>
<author initials='J.' surname='Loughney' fullname='J. Loughney'>
<organization /></author>
<author initials='E.' surname='Guttman' fullname='E. Guttman'>
<organization /></author>
<author initials='G.' surname='Zorn' fullname='G. Zorn'>
<organization /></author>
<author initials='J.' surname='Arkko' fullname='J. Arkko'>
<organization /></author>
<date year='2003' month='September' />
<abstract><t>The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations. [STANDARDS TRACK] </t></abstract>
</front>
<seriesInfo name='RFC' value='3588' />
<format type='TXT' octets='341261' target='http://www.ietf.org/rfc/rfc3588.txt' />
</reference>
<reference anchor="Dia-EAP">
<front>
<title>Diameter Extensible Authentication Protocol (EAP) Application</title>
<author initials='P.' surname='Eronen' fullname='P. Eronen'><organization /></author>
<author initials='T.' surname='Hiller' fullname='T. Hiller'><organization /></author>
<author initials='G.' surname='Zorn' fullname='G. Zorn'><organization /></author>
<date year='2005' month='August' />
<abstract>
<t>The Extensible Authentication Protocol (EAP) provides a standard mechanism for support of various authentication methods. This document defines the Command-Codes and AVPs necessary to carry EAP packets between a Network Access Server (NAS) and a back-end authentication server. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name='RFC' value='4072' />
<format type='TXT' octets='79965' target='http://www.ietf.org/rfc/rfc4072.txt' />
</reference>
<reference anchor='EAP-GPSK'>
<front>
<title>EAP Generalized Pre-Shared Key (EAP-GPSK)</title>
<author initials='T' surname='Clancy' fullname='T. Charles Clancy'><organization /></author>
<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'><organization /></author>
<date month='April' day='5' year='2007' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-emu-eap-gpsk-05' />
<format type='TXT' target='http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-05.txt' />
</reference>
<reference anchor='I.D.Webauth-phishing'>
<front>
<title>Requirements for Web Authentication Resistant to Phishing</title>
<author initials='S' surname='Hartman' fullname='Sam Hartman'><organization /></author>
<date month='March' day='4' year='2007' />
</front>
<seriesInfo name='Internet-Draft' value='draft-hartman-webauth-phishing-03' />
<format type='TXT' target='http://www.ietf.org/internet-drafts/draft-hartman-webauth-phishing-03.txt' />
</reference>
<reference anchor='I-D.ietf-eap-keying'>
<front>
<title>Extensible Authentication Protocol (EAP) Key Management Framework</title>
<author initials='B' surname='Aboba' fullname='Bernard Aboba'><organization /></author>
<date month='February' day='8' year='2007' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-eap-keying-18' />
<format type='TXT' target='http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-18.txt' />
</reference>
<reference anchor='Compound-Authentication'>
<front>
<title>The Compound Authentication Binding Problem</title>
<author initials='J' surname='Puthenkulam' fullname='Jose Puthenkulam'><organization>Intel Corporation</organization></author>
<author initials='V' surname='Lortz' fullname='Victor Lortz'><organization>Intel Corporation</organization></author>
<author initials='A' surname='Palekar' fullname='Ashwin Palekar'><organization>Microsoft</organization></author>
<author initials='D' surname='Simon' fullname='Dan Simon'><organization>Microsoft</organization></author>
<date month='October' day='27' year='2003' />
</front>
<seriesInfo name='Internet-Draft' value='draft-puthenkulam-eap-binding-04' />
<format type='TXT' target='http://www.watersprings.org/pub/id/draft-puthenkulam-eap-binding-04.txt' />
</reference>
</references>
<!-- ====================================================================== -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:20:22 |