One document matched: draft-nir-tls-eap-13.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-13" category="std">
<front>
<title abbrev="TLS with EAP Extension (TEE)">A Flexible Authentication Framework for the
Transport Layer Security (TLS) Protocol using the Extensible Authentication Protocol (EAP)</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="2011"/>
<area>Security Area</area>
<workgroup>TLS Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t> Many of today's Web security problems have their root in the widespread usage of weak
authentication mechanisms bundled with the usage of password based credentials. Dealing
with both of these problems is the basis of this publication.</t>
<t> This document extends the Transport Layer Security (TLS) protocol with a flexible and
widely deployed authentication framework, namely the Extensible Authentication Protocol
(EAP), to improve security of Web- as well as non-Web-based applications. The EAP framework
allows so-called EAP methods, i.e. authentication and key exchange protocols, to be plugged
into EAP without having to re-design the underlying protocol. The benefit of such an easy
integration is the ability to run authentication protocols that fit a specific deployment
environment, both from a credential choice as well as from the security and performance
characteristics of the actual protocol.</t>
<t> This work follows the example of IKEv2, where EAP has been added to allow clients to
seamlessly use different forms of authentication 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
either a "supplicant" or a "peer"). 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="RFC5996"/>.
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. Although the technical mechanisms
have been standardized for a AAA client to dynamically discover a AAA server often the
address of the AAA server is statically configured. 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 EapMsg, which is used to carry a single
EAP message.</t>
<t>A new message type for the handshake protocol, called EapFinished, which is used to sign
previous messages.</t></list></t>
<t> The diagram below outlines the protocol structure. For illustration purposes only, we
use EAP Generalized Pre-Shared Key (EAP-GPSK) method <xref target="RFC5433"/>. This method
is a lightweight shared-key authentication protocol supporting mutual authentication and
key derivation.<figure>
<artwork><![CDATA[
Client Server
------ ------
ClientHello(*) -------->
ServerHello(*)
(Certificate)
ServerKeyExchange
EapMsg(Identity-Request)
<-------- ServerHelloDone
ClientKeyExchange
(CertificateVerify)
ChangeCipherSpec
Finished
EapMsg(Identity-Reply) -------->
ChangeCipherSpec
Finished
EapMsg(GPSK-Request)
<--------
EapMsg(GPSK-Reply) -------->
EapMsg(GPSK-Request)
<--------
EapMsg(GPSK-Reply) -------->
EapMsg(Success)
<-------- EaoFinished
EapFinished -------->
(*) 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 EapFinished Handshake Message">
<t> The EapFinished 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> When TEE is used, application data cannot follow the "Finished" message. Instead, it may
only begin after the EapFinished message</t>
<t> The HandshakeType value for the EapFinished 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 EapFinished message">
<t>If the EAP method is key-generating (see <xref target="RFC5247"/>), 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 does not include all the data in the handshake. Instead it
includes only the data that has not been signed by the previous Finished message. The
handshake_messages field includes all of the octets beginning with and including the
Finished message, up to but not including this EapFinished 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="EapFinished 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,
and the signal is given by EapFinished.</t>
<t> Many EAP methods, such as EAP-TLS, EAP-IKEv2 and EAP-SIM, generate keys in addition to
authenticating clients. Such methods are resistant to man-in-the-middle (MITM) attacks,
as discussed in <xref target="MITM"/> and 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 EapFinished message
signs the messages that have not yet been signed by the Finished message 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 EAP-GPSK. The
client would be authenticated to the AAA server and vice versa. Additionally
authenticating the application server to the client is not necessary and the TLS
handshake may as well be anonymous. Note that the authenticated client identity may be
sent from the AAA server to the application server (acting as a AAA client) if the
authenticated identity indeed matters for the purpose of the service fulfillment and
with the user's permission. </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 "EapFinished".</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="TLSIA"/>) 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="RFC5996"/>
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>
<!-- ====================================================================== -->
</middle>
<!-- ====================================================================== -->
<back>
<references title="Normative References">
<reference anchor='TLS'>
<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' />
</front>
<seriesInfo name='RFC' value='5246' />
<format type='TXT' target='http://tools.ietf.org/rfc/rfc5246.txt' />
<format type='HTML' target='http://tools.ietf.org/html/rfc5246' />
</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='TLSIA'>
<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='RFC5996'>
<front>
<title>Internet Key Exchange Protocol: IKEv2</title>
<author initials='C' surname='Kaufman' fullname='Charlie Kaufman'>
<organization>Microsoft</organization>
</author>
<author initials='P' surname='Hoffman' fullname='Paul Hoffman'>
<organization>VPN Consortium</organization>
</author>
<author initials='Y' surname='Nir' fullname='Yoav Nir'>
<organization>Check Point</organization>
</author>
<author initials='P' surname='Eronen' fullname='Pasi Eronen'>
<organization>Nokia</organization>
</author>
<date month='September' year='2010' />
</front>
<seriesInfo name='RFC' value='5996' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc5996.txt' />
<format type='HTML' target='http://xml.resource.org/public/rfc/html/rfc5996.html' />
<format type='XML' target='http://xml.resource.org/public/rfc/xml/rfc5996.xml' />
</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' />
</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='RFC5433'>
<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='February' year='2009' />
</front>
<seriesInfo name='RFC' value='5433' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc5433.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='August' day='15' year='2008' />
</front>
<seriesInfo name='Internet-Draft' value='draft-hartman-webauth-phishing-09' />
<format type='TXT' target='http://www.ietf.org/internet-drafts/draft-hartman-webauth-phishing-09.txt' />
</reference>
<reference anchor='RFC5247'>
<front>
<title>Extensible Authentication Protocol (EAP) Key Management Framework</title>
<author initials='B' surname='Aboba' fullname='Bernard Aboba'><organization /></author>
<author initials='D' surname='Simon' fullname='D. Simon'><organization /></author>
<author initials='P' surname='Eronen' fullname='Pasi Eronen'><organization /></author>
<date month='August' year='2008' />
</front>
<seriesInfo name='RFC' value='5247' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc5247.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 14:16:54 |