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.

Table of Contents

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

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 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

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 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 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 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 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 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.

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

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

10.2. Informative References

Author's Address