Internet DRAFT - draft-vanrein-eap-sasl

draft-vanrein-eap-sasl







Network Working Group                                        R. Van Rein
Internet-Draft                                                 ARPA2.net
Intended status: Standards Track                         August 14, 2017
Expires: February 15, 2018


     Simple Authentication and Security Layers over the Extensible
                   Authentication Protocol (EAP-SASL)
                       draft-vanrein-eap-sasl-00

Abstract

   This specification permits SASL authentication as an application of
   EAP.  This enhances SASL with several new protocols over which it can
   be used.  It enhances EAP with application-level credentials and
   mechanisms.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on February 15, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Van Rein                Expires February 15, 2018               [Page 1]

Internet-Draft                  EAP-SASL                     August 2017


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Inner and Outer Identities  . . . . . . . . . . . . . . . . .   4
   3.  Transporting SASL Frames over EAP . . . . . . . . . . . . . .   4
   4.  Interactions with the EAP Lower Layer . . . . . . . . . . . .   6
   5.  Key Derivation  . . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Keying under EAP-SASL . . . . . . . . . . . . . . . . . .   7
     5.2.  Keying under EAP-TTLS . . . . . . . . . . . . . . . . . .   8
   6.  Efficiency Considerations . . . . . . . . . . . . . . . . . .   9
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     10.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   EAP, or the Extensible Authentication Protocol, is a pluggable
   mechanism for the control of network or service access by users.  It
   is usually communicated with users during a login phase of IKEv2
   [Section 3.16 of [RFC7296]], PPP [Section 3.2 of [RFC3748]], 802.1x
   [Section 3.3 of [RFC3748]] or PANA [RFC5191] and passed on to backend
   servers in a RADIUS attribute [Section 5.1 of [RFC2865]] or Diameter
   AVP [Section 8.14 of [RFC6733]] set aside for EAP.  Note that PPP is
   used in technologies like PPPoE, PPPoA, L2TP and PPTP; and that
   802.1x is used in EAPOL authentication for wired networks, as well as
   for wireless ethernet where it is called WPA2; IKE is used to
   negotiate IPsec security associations.  In short, EAP is available in
   most places that grant network access.

   Although often used with password-based policies, EAP may also be
   used with more advanced cryptographic approaches.  What this
   specification adds, is a facility for the Simple Authentication and
   Security Layer, with a focus on the most generally used facilitation
   of client authentication.  Both EAP and SASL follow a request/
   response interaction, which makes their integration into EAP-SASL
   relatively straightforward.

   Typical applications of EAP are network access, while SASL is more
   oriented towards end-user applications.  There is no reason however,
   why the potential of SASL mechanisms should be held back from EAP.
   What EAP stands to gain from this is an independently standardised
   and implemented set of authentication mechanisms; depending on
   implementation choices, these may be made to share credentials for
   end-user applications, which can be helpful when networks move into



Van Rein                Expires February 15, 2018               [Page 2]

Internet-Draft                  EAP-SASL                     August 2017


   the user view, such as is the case with VPNs and single-user network
   logon (perhaps from a single-user machine).  What SASL stands to gain
   is the ability to be carried over widely used AAA backend protocols
   such as RADIUS and Diameter.  When a site is standardising its
   authentication on SASL, it is possible for both network access and
   end-user applications to isolate authentication sequences and relay
   them to a shared AAA backend.  This facilitates centralised
   management of identities and credentials.

   Some special attention is needed for one of the SASL mechanisms,
   namely Kerberos5 over GSSAPI.  This mechanism uses short-lived
   credentials, which may mean that a bootstrapping sequence is needed
   so these can be setup.  The work in progress on IAKERB
   [I-D.ietf-kitten-iakerb] enhances GSSAPI with just this facility.
   This is more general, and therefore better, than earlier work done on
   EAP-Kerberos [I-D.vanrein-eap-kerberos].  An explicit method for
   Kerberos over EAP is an improvement over current-day implementations
   that use the PAP method to pass the client password over RADIUS which
   then addresses a KDC by authenticating on behalf of the user.  It
   should be noted that such submission of user passwords contradicts
   Kerberos security design assumptions.

   There is a SASL method for EAP over GSSAPI [RFC7055], which could be
   combined with this specification to form stacks like EAP-SASL-GSSAPI-
   EAP and SASL-GSSAPI-EAP-SASL, both of which seem useless and are
   unintended.  These stacks may however occur as a result of
   abstraction layers that are unaware of lower or higher abstraction
   layers.  Although not a sign of good design, this specification
   cannot forecast all possible uses, so it limits itself to stating
   that such stacks are NOT RECOMMENDED.

   The following Security Claims [Section 7.2 of [RFC3748]] are made for
   EAP-Kerberos:

   Mechanism:                 SASL mechanisms with operator approval
   Ciphersuite negotiation:   Only with supporting SASL mechanisms
   Mutual authentication:     Only with supporting SASL mechanisms
   Integrity protection:      No
   Replay protection:         Only with supporting SASL mechanisms
   Confidentiality:           No
   Key derivation:            Yes, except with plaintext passwords
   Key strength:              Follows SASL credential entropy
   Dictionary attack protect: Follows SASL credential entropy
   Fast reconnect:            No
   Cryptographic binding:     No
   Session independence:      Yes, ensured through fresh random salts
   Fragmentation:             Yes
   Channel binding:           No



Van Rein                Expires February 15, 2018               [Page 3]

Internet-Draft                  EAP-SASL                     August 2017


2.  Inner and Outer Identities

   It is common for EAP to be encapsulated in a context that
   communicates an identity, independently of what the EAP does with it.
   This identity is sometimes referred to as the "outer" identity, to
   contrast it with an "inner" identity negotiated within the EAP
   transport.  As an example, when EAP is transported in RADIUS or
   Diameter, there is commonly a User-Name attribute at the same level
   as the EAP-Message attribute holding an EAP packet; the contents of
   this User-Name would be the outer identity.

   Only the inner identities of EAP-SASL relate to authenticated
   identities, at least when EAP approves the exchange.  This remains
   true when EAP-SASL is wrapped inside of EAP-TTLS, as described below.

   An outer identity may be added for routing purposes alone, where the
   realm part of the User-Name serves to indicate a backend to route to.
   In fact, for reasons of privacy, the outer identity often lacks the
   user name and may look like @example.com.

3.  Transporting SASL Frames over EAP

   Messages from the SASL client to the server are sent in an EAP packet
   with Code set to Request.  What is called a client in SASL is
   referred to as a peer in EAP.  Challenges from the server to the SASL
   client are sent in EAP packets with Code set to Response.  Both the
   EAP packets, which shall be referred to as EAP Request and EAP
   Response respectively, will set Type to TBD, as assigned by IANA.
   The Type-Data field in both an EAP Request and EAP Responses is
   referred to as EAP Payload below.  The names EAP Success and EAP
   Failure will be used to refer to an EAP packet with Code set to
   Success and Failure, respectively.

   The SASL specification [RFC4422] is often used with base64-encoding
   of binary data, to avoid problems of textual protocols.  EAP is a
   binary protocol, so it can carry binary content directly in EAP.  For
   this reason, no base64 or other mapping to text will be used.

   The EAP Payload consists of 20 bytes followed by the binary data for
   the SASL mechanism, the latter of which may be 0 bytes long.  The
   first 20 bytes hold the SASL mechanism name or an instruction.
   Instructions are easily recognised because they start with an
   asterisk (U+002a).  Note that instructions are not valid SASL
   mechanism names; they are used to expand EAP with specific semantics
   of EAP-SASL.  The SASL mechanism name or instruction starts in the
   first byte of the EAP Payload and is padded with space characters
   (U+0020) to fill up the 20 bytes.  Note that according to the syntax




Van Rein                Expires February 15, 2018               [Page 4]

Internet-Draft                  EAP-SASL                     August 2017


   of SASL names [Section 3.1 of [RFC4422]], 20 bytes can hold the
   longest SASL name.

   The instruction *RESET can be sent by EAP peers to terminate a
   current EAP session, if any; the EAP server responds with EAP
   Failure, which only counts as a failed session inasfar as one was
   currently active.  This form of termination is never used by the EAP
   server, which instead sends EAP Failure in its next EAP Response
   message.  The *RESET instruction is never followed by SASL mechanism
   data bytes.  The instruction SHOULD be used when the EAP Lower Layer
   is a multiplex of EAP links without explicit link ends, and it MAY be
   used when it uses a connection-less transport without any certainty
   about the remote peer's state (such as after a software restart on
   either end).  When no EAP interaction is taking place, the EAP
   Payload with this instruction has no effect.  On connection-less EAP
   transports, this instruction may be used to safely start an
   interaction after one side is restarted while the other may still
   keep state.  When an EAP Payload with this instruction is used, both
   its sender and recipient MUST discard any EAP-related state and
   forward the error to any other protocol layers that may depend on it.

   The instruction *DEFRAGMENT is used when an EAP Payload cannot be
   sent in one whole; any but the last EAP Payload is sent with this
   instruction.  It may be sent by the EAP peer or server when the MTU
   available for EAP is insufficient to carry a full EAP Reqeust or EAP
   Response.  The size of the data following this instruction and its
   padding to 20 bytes MUST be non-zero and should make the EAP Payload
   almost as large as the MTU will permit.  Upon receiving an EAP
   Payload with this instruction, it is held so that the next EAP
   Payload may be attached to it; the reconstituted EAP Payload will
   have its SASL mechanism name or instruction set to the first EAP
   Payload to follow without the *DEFRAGMENT instruction.  This
   reconsituted EAP Payload is then used instead of its constituent
   components, and processed as had it been sent without transport
   fragmentation.  The receiving party requests continuation with an EAP
   Request or Response (as implied by their role) with the *CONTINUE
   instruction and no appended bytes.

   The instruction *RANDOMSALT may be exchanged once before EAP Success
   or EAP Failure.  It is initially sent by the EAP peer, and results in
   the same instruction in an EAP server response.  Each party is
   allowed to send as much random bytes as it likes, but 16 bytes is the
   REQUIRED minimum and no more than the size of MSK/EMSK that could be
   generated from it, which means a maximum of 128 bytes under this
   specification.

   The first EAP Payload that names the SASL mechanism may just be 20
   bytes in size, in which case its optional initial data is considered



Van Rein                Expires February 15, 2018               [Page 5]

Internet-Draft                  EAP-SASL                     August 2017


   absent.  When a *DEFRAGMENT instruction precedes it, the optional
   initial data is considered present, even when it is 0 bytes long.
   SASL requires distinction between empty and absent initial data
   [Section 4 of [RFC3748]], which is implemented by these rules.

   The instruction *LISTMECHANISMS enables the EAP peer to obtain a list
   of server-supported SASL mechanism names.  The EAP Request with this
   instruction adds no data bytes; the EAP Response with this
   instruction adds supported SASL mechanism names separated by a space
   character (U+0020).  The use of this instruction is optional, at the
   discretion of the peer.  When sent, this exchange precedes the
   customary information.

   Any *DEFRAGMENT instructions preceding an EAP Success count as the
   optional data that a SASL mechanism may receive alongside a
   successful finish.  This even applies when the preceding instructions
   provide 0 bytes.  The absense of preceding *DEFRAGMENT instructions
   cause an EAP Success to be delivered to the EAP peer without such
   additional data.  Note the distinction between absense of additional
   data and empty but present This slightly contrived mechanism can fit
   carrier protocols that allow only one EAP Payload at a time, notably
   PPP [Section 2.2 of [RFC2284]] as well as others that depend on the
   EAP Success to be reported over EAP and not merely be derivable from
   this EAP-SASP instruction.  When EAP Failure is reported by the
   server, any preceding *DEFRAGMENT instructions from the server MUST
   be ignored, and silently discarded before delivery to the EAP peer.

4.  Interactions with the EAP Lower Layer

   SASL requires a number of specifications from the protocol that
   embeds it.  Some of these can be resolved in EAP in a generic manner,
   as was done in the preceding section; this section pushes a few
   requirements to the layers below EAP, which we shall refer to as the
   EAP Lower Layer, for which some possibilities are enumerated in the
   Extensible Authentication Protocol (EAP) Registry maintained by IANA,
   while others such as RADIUS and Diameter are only defined by
   incorporation of EAP in their messages.

   The Identity field in an EAP header [Section 4 of [RFC3748]] is the
   only mechanism that can distinguish EAP packets, and it is used to
   match a Response to a Request.  Though it might be used to allow 128
   or perhaps even 256 simultaneous EAP interactions, this is neither
   forbidden nor specified herein.  Instead, the RECOMMENDED place to
   implement concurrency is in the EAP Lower Layer; a PPP stream is
   always encapsulated into a session, as is the case for L2TP and PPPoE
   and even dialup networking; a RADIUS stream can include an EAP-
   Session-Id; a Diameter stream uses a Session-ID to connect parts of
   the same flow; IKEv2 uses SPIs; PANA message headers have a Session



Van Rein                Expires February 15, 2018               [Page 6]

Internet-Draft                  EAP-SASL                     August 2017


   Identifier field.  Adding an interpretation to the Identity field for
   reasons of concurrency would add complexity, but not functionality.
   In line with this reasoning, multiple SASL authentications within the
   same EAP session are not supported.

   SASL requires a service name to be specified for use with GSSAPI.
   This service name is easy to establish when protocols serve a
   specific application, but EAP is more general.  Therefore, the
   responsibility of selecting a service name must in general be
   specific to the EAP Lower Layer.  The name TBD:net is allocated as a
   default service name for the EAP Lower Layer protocols 1-7 and 9, as
   registered by IANA.  The EAP peer drives this choice.  When carried
   over RADIUS or Diameter, the EAP-Lower-Layer attribute [Section 7.2
   of [RFC6677]] SHOULD be used.  For EAP Lower Layer protocol 8 (GSS-
   API), this specification cannot assign a default service name,
   because it is another generic lower layer.  Also, it may be better to
   avoid the SASL method GSSAPI when GSSAPI is the EAP Lower Layer.

   SASL requires a standard syntax and semantics, as well as
   normalisation rules, for authorisation identifiers.  In general, this
   depends on the EAP Lower Layer.  We can provide a default mechanism,
   however, which is of use to customary EAP Lower Layers such as PPP
   and 802.1x.  This is either the format of a Fully Qualified Domain
   Name [Section 5.2 of [RFC1594]] or a Network Access Identitifier
   [RFC7542].

   TODO: channel binding, like in GS2-KRB5-PLUS and SCRAM-SHA1-PLUS
   requires a notion of the TLS channel; relaying it to a backend over
   EAP is not helpful; an attribute such as the NAS-Port-Instance may
   help?

5.  Key Derivation

   There are two mechanisms that may be used for key derivation; either
   directly using the SASL credentials, or by using an EAP-TTLS wrapper
   around EAP-SASL.  When both are used, EAP-TTLS is the RECOMMENDED
   choice on account of its stronger security.

5.1.  Keying under EAP-SASL

   Keying under SASL uses what shared secret is available in order to
   generate MSK/EMSK [RFC5247] for use in the EAP Lower Layer.  To
   enable this additional function, the shared secret MUST NOT be passed
   over EAP-SASL in an unprotected form, not even when protected with
   EAP-TTLS, meaning that the SASL PLAIN and OAUTHBEARER mechanisms are
   barred.  Some form of active use of the credential MUST pass over
   EAP-SASL, meaning that the SASL ANONYMOUS and EXTERNAL mechanisms are
   also barred.  Furthermore, the EAP-SASL method MUST have exchanged at



Van Rein                Expires February 15, 2018               [Page 7]

Internet-Draft                  EAP-SASL                     August 2017


   least 16 bytes from each side in precisely one *RANDOMSALT
   instruction exchange.

   SASL mechanisms that can negotiate a security layer are RECOMMENDED
   to use this facility to find a sesssion key for key generation under
   SASL; other SASL mechanisms may have to use a shared key that is
   fixed as the session key.  One SASL mechanism that SHOULD negotiate a
   session key when used is GSSAPI with Kerberos5.

   The session key is used in a variation on the EAP-TTLS computation:

   KeyMaterial = PRF-128 (eap_sasl.session_key,
                          "EAP-SASL keying material",
                          peer.RANDOMSALT + server.RANDOMSALT)

   MSK  = KeyMaterial [ 0.. 63]

   EMSK = KeyMaterial [64..127]

   The PRF-128 function is as used with EAP-TTLS [Section 7.8 of
   [RFC5281]].  Note the reversed order of the random material relative
   to TLS; as for EAP-TLS and EAP-TTLS, this intends to avoid clashes
   with similar TLS computations.  The EMSK may be used to derive root
   keys [RFC5295].

5.2.  Keying under EAP-TTLS

   Some SASL mechanisms cannot reliably be sent in plaintext; in such
   cases, it is customary to run the containing protocol in a secure
   transport such as TLS.  There is an EAP mechanism to do just that,
   namely EAP-TTLS [RFC5281].  The EAP-SASL flow can be embedded in EAP-
   TTLS if such is required.

   Wrapping EAP-SASL inside EAP-TTLS is not only of interest for
   protecting the credential, but also in assuring that the response is
   sent to an authentic server, thus mitigating man-in-the-middle
   attacks.  Finally, EAP-TTLS can be useful because it standardises a
   key that can be used to encrypt further traffic, for instance under
   the WPA2 technology.

   Finally, when EAP-TTLS wrapping is used, there is the option of using
   Keying Material Export [RFC5705] to derive a key.  Unlike the MSK/
   EMSK that EAP-TTLS shares with the EAP authenticator to establish
   one-hop encryption, this constitutes a key that reaches out to the
   site that performed authentication.  Such applications use the ASCII
   label "EAP-SASL key derivation" (without the quotes).  The context
   value is only provided when EAP-SASL has exchanged *RANDOMSALT, in




Van Rein                Expires February 15, 2018               [Page 8]

Internet-Draft                  EAP-SASL                     August 2017


   which case it is set to the concatenation of the peer and server
   random salt bytes.

6.  Efficiency Considerations

   EAP is a lock-stepped request/response protocol, which means that
   there are no window buffers, and so efficiency can be low, especially
   when EAP-SASL is run over EAP-TTLS.  This is agravated in setups with
   a backend AAA server, especially when the backend is dynamically
   switched to a remote site.  Since EAP is mostly used to bootstrap
   network connections, rather than consistently recurring events, this
   is usually considered acceptable.

   Some EAP-SASL mechanisms or encapsulations may derive an end-to-end
   secret key that cannot be observed by intermediates.  This may speed
   up further processing, for instance for the setup of IPsec shared
   keys.

   SASL is present in many protocols, each of which could be candidates
   for backend authentication.  Many protocols (like IMAP and SMTP) do
   not allow reuse of connections for multiple authentications.  LDAP
   does allow such reuse, and overcomes MTU-caused fragmentation, but
   only one LDAP bind interaction can be active at any time.  The best
   performance is to be expected from the multiplexed authentication
   sessions over AAA protocols.  Of these, Diameter over SCTP is likely
   the most efficient, because it (1) avoids head-of-line blocking by
   sending out-of-order, (2) avoids resend logic and timers with
   reliable delivery, (3) avoids fragmentation by allowing large user
   messages, (4) handles resends at the protocol level, and can notice
   intermediate frames being dropped, (5) can combine multiple small
   messages in one network packet.

7.  Privacy Considerations

   The EAP-SASL mechanism is as private as SASL is.  So, when a user
   identity is revealed in plaintext SASL, then it will also be visible
   in plaintext EAP-SASL.  A layer of EAP-TTLS can remedy any problems
   with this.

   In addition, EAP-SASL may be transported with a so-called outer
   identity.  If this is the case, then additional data may leak from
   there too.  The customary approach is then to avoid mentioning the
   username portion, but just the realm, as in @example.com User-Id
   attributes.







Van Rein                Expires February 15, 2018               [Page 9]

Internet-Draft                  EAP-SASL                     August 2017


8.  Security Considerations

   Anything that cannot travel securely in plaintext over SASL, also
   cannot travel securely over EAP-SASL.  Where needed, a layer of EAP-
   TTLS can be used to remedy that.

   SASL mechanisms are not only subjected to public showing of
   credentials, but also to the danger of entering in a challenge/
   response interaction with an unverified peer, which may then function
   as a man in the middle.  Such men are usually called Eve.  A wrapper
   of EAP-TTLS can remedy this, by supplying end-to-end server
   authenticity.

   Whether plaintext suffices for EAP-SASL depends largely on the
   intermediate network; when routing to an external network it is
   almost certainly not a good idea but when routing to a nearby AAA
   backend within a secure network premises or over a secure AAA
   backlink it can be made secure.

   When producing MSK/EMSK from EAP-SASL, it is vital to have good
   entropy from all the available places: the session key, the EAP peer
   and EAP server should all provide an ample amount of entropy.  The
   *RANDOMSALT provided by EAP peer and server helps each side to direct
   scattering of the MSK/EMSK, and thereby influence that other parties
   could attempt replay attacks; but regardless of the quality and size
   of these *RANDOMSALT fragments, the session key is still subject to
   password attacks upon observation of the MSK/EMSK and must therefore
   be carefully selected; this is especially a concern when the session
   key is just a shared secret, such as a password, which may be used
   without change over a prolonged period.

9.  IANA Considerations

   This specification requests the registration of a Method Type in the
   Extensible Authentication Protocol (EAP) Registry, from the range
   granted through the Designated Expert with Specification Required
   procedure.  IANA has assigned TBD to the EAP method specified herein.

   This specification defines an additional entry in the registry
   "Generic Security Service Application Program Interface
   (GSSAPI)/Kerberos/Simple Authentication and Security Layer (SASL)
   Service Names" namely:

   Service Name: net
   Usage:        authentication for network access
   Reference:    TBD:this specification





Van Rein                Expires February 15, 2018              [Page 10]

Internet-Draft                  EAP-SASL                     August 2017


   This specification defines an entry in the TLS Exporter Label
   registry, referencing this specification, namely: EAP-SASL key
   derivation

10.  References

10.1.  Normative References

   [I-D.ietf-kitten-iakerb]
              Kaduk, B., Schaad, J., Zhu, L., and J. Altman, "Initial
              and Pass Through Authentication Using Kerberos V5 and the
              GSS- API (IAKERB)", draft-ietf-kitten-iakerb-03 (work in
              progress), March 2017.

   [RFC1594]  Marine, A., Reynolds, J., and G. Malkin, "FYI on Questions
              and Answers - Answers to Commonly asked "New Internet
              User" Questions", RFC 1594, DOI 10.17487/RFC1594, March
              1994, <http://www.rfc-editor.org/info/rfc1594>.

   [RFC2284]  Blunk, L. and J. Vollbrecht, "PPP Extensible
              Authentication Protocol (EAP)", RFC 2284,
              DOI 10.17487/RFC2284, March 1998,
              <http://www.rfc-editor.org/info/rfc2284>.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, Ed., "Extensible Authentication Protocol
              (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
              <http://www.rfc-editor.org/info/rfc3748>.

   [RFC4422]  Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
              Authentication and Security Layer (SASL)", RFC 4422,
              DOI 10.17487/RFC4422, June 2006,
              <http://www.rfc-editor.org/info/rfc4422>.

   [RFC5247]  Aboba, B., Simon, D., and P. Eronen, "Extensible
              Authentication Protocol (EAP) Key Management Framework",
              RFC 5247, DOI 10.17487/RFC5247, August 2008,
              <http://www.rfc-editor.org/info/rfc5247>.

   [RFC5281]  Funk, P. and S. Blake-Wilson, "Extensible Authentication
              Protocol Tunneled Transport Layer Security Authenticated
              Protocol Version 0 (EAP-TTLSv0)", RFC 5281,
              DOI 10.17487/RFC5281, August 2008,
              <http://www.rfc-editor.org/info/rfc5281>.







Van Rein                Expires February 15, 2018              [Page 11]

Internet-Draft                  EAP-SASL                     August 2017


   [RFC5295]  Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
              "Specification for the Derivation of Root Keys from an
              Extended Master Session Key (EMSK)", RFC 5295,
              DOI 10.17487/RFC5295, August 2008,
              <http://www.rfc-editor.org/info/rfc5295>.

   [RFC5705]  Rescorla, E., "Keying Material Exporters for Transport
              Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
              March 2010, <http://www.rfc-editor.org/info/rfc5705>.

   [RFC6677]  Hartman, S., Ed., Clancy, T., and K. Hoeper, "Channel-
              Binding Support for Extensible Authentication Protocol
              (EAP) Methods", RFC 6677, DOI 10.17487/RFC6677, July 2012,
              <http://www.rfc-editor.org/info/rfc6677>.

   [RFC7542]  DeKok, A., "The Network Access Identifier", RFC 7542,
              DOI 10.17487/RFC7542, May 2015,
              <http://www.rfc-editor.org/info/rfc7542>.

10.2.  Informative References

   [I-D.vanrein-eap-kerberos]
              Rein, R., "Kerberos in the Extensible Authentication
              Protocol (EAP-Kerberos)", draft-vanrein-eap-kerberos-00
              (work in progress), March 2016.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, DOI 10.17487/RFC2865, June 2000,
              <http://www.rfc-editor.org/info/rfc2865>.

   [RFC5191]  Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
              and A. Yegin, "Protocol for Carrying Authentication for
              Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191,
              May 2008, <http://www.rfc-editor.org/info/rfc5191>.

   [RFC6733]  Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
              Ed., "Diameter Base Protocol", RFC 6733,
              DOI 10.17487/RFC6733, October 2012,
              <http://www.rfc-editor.org/info/rfc6733>.

   [RFC7055]  Hartman, S., Ed. and J. Howlett, "A GSS-API Mechanism for
              the Extensible Authentication Protocol", RFC 7055,
              DOI 10.17487/RFC7055, December 2013,
              <http://www.rfc-editor.org/info/rfc7055>.






Van Rein                Expires February 15, 2018              [Page 12]

Internet-Draft                  EAP-SASL                     August 2017


   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
              2014, <http://www.rfc-editor.org/info/rfc7296>.

Author's Address

   Rick van Rein
   ARPA2.net
   Haarlebrink 5
   Enschede, Overijssel  7544 WP
   The Netherlands

   Email: rick@openfortress.nl





































Van Rein                Expires February 15, 2018              [Page 13]