tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 5281

 
 
 

Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)

Part 2 of 3, p. 19 to 36
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 19 
8.  Generating Keying Material

   Upon successful conclusion of an EAP-TTLS negotiation, 128 octets of
   keying material are generated and exported for use in securing the
   data connection between client and access point.  The first 64 octets
   of the keying material constitute the MSK, the second 64 octets
   constitute the EMSK.

   The keying material is generated using the TLS PRF function
   [RFC4346], with inputs consisting of the TLS master secret, the
   ASCII-encoded constant string "ttls keying material", the TLS client
   random, and the TLS server random.  The constant string is not null-
   terminated.

      Keying Material = PRF-128(SecurityParameters.master_secret, "ttls
                keying material", SecurityParameters.client_random +
                SecurityParameters.server_random)

      MSK = Keying Material [0..63]

      EMSK = Keying Material [64..127]

Top      Up      ToC       Page 20 
   Note that the order of client_random and server_random for EAP-TTLS
   is reversed from that of the TLS protocol [RFC4346].  This ordering
   follows the key derivation method of EAP-TLS [RFC5216].  Altering the
   order of randoms avoids namespace collisions between constant strings
   defined for EAP-TTLS and those defined for the TLS protocol.

   The TTLS server distributes this keying material to the access point
   via the AAA carrier protocol.  When RADIUS is the AAA carrier
   protocol, the MPPE-Recv-Key and MPPE-Send-Key attributes [RFC2548]
   may be used to distribute the first 32 octets and second 32 octets of
   the MSK, respectively.

9.  EAP-TTLS Protocol

9.1.  Packet Format

   The EAP-TTLS packet format is shown below.  The fields are
   transmitted left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |   Identifier  |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Flags     |        Message Length
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Message Length         |             Data...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Code
      1 for request, 2 for response.

   Identifier
      The Identifier field is one octet and aids in matching responses
      with requests.  The Identifier field MUST be changed for each
      request packet and MUST be echoed in each response packet.

   Length
      The Length field is two octets and indicates the number of octets
      in the entire EAP packet, from the Code field through the Data
      field.

   Type
      21 (EAP-TTLS)

Top      Up      ToC       Page 21 
   Flags
        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      | L | M | S | R | R |     V     |
      +---+---+---+---+---+---+---+---+

      L = Length included
      M = More fragments
      S = Start
      R = Reserved
      V = Version (000 for EAP-TTLSv0)

      The L bit is set to indicate the presence of the four-octet TLS
      Message Length field.  The M bit indicates that more fragments are
      to come.  The S bit indicates a Start message.  The V field is set
      to the version of EAP-TTLS, and is set to 000 for EAP-TTLSv0.

   Message Length
      The Message Length field is four octets, and is present only if
      the L bit is set.  This field provides the total length of the raw
      data message sequence prior to fragmentation.

   Data
      For all packets other than a Start packet, the Data field consists
      of the raw TLS message sequence or fragment thereof.  For a Start
      packet, the Data field may optionally contain an AVP sequence.

9.2.  EAP-TTLS Start Packet

   The S bit MUST be set on the first packet sent by the server to
   initiate the EAP-TTLS protocol.  It MUST NOT be set on any other
   packet.

   This packet MAY contain additional information in the form of AVPs,
   which may provide useful hints to the client; for example, the server
   identity may be useful to the client to allow it to pick the correct
   TLS session ID for session resumption.  Each AVP must begin on a
   four-octet boundary relative to the first AVP in the sequence.  If an
   AVP is not a multiple of four octets, it must be padded with zeros to
   the next four-octet boundary.

9.2.1.  Version Negotiation

   The version of EAP-TTLS is negotiated in the first exchange between
   server and client.  The server sets the highest version number of
   EAP-TTLS that it supports in the V field of its Start message (in the
   case of EAP-TTLSv0, this is 0).  In its first EAP message in
   response, the client sets the V field to the highest version number

Top      Up      ToC       Page 22 
   that it supports that is no higher than the version number offered by
   the server.  If the client version is not acceptable to the server,
   it sends an EAP-Failure to terminate the EAP session.  Otherwise, the
   version sent by the client is the version of EAP-TTLS that MUST be
   used, and both server and client MUST set the V field to that version
   number in all subsequent EAP messages.

9.2.2.  Fragmentation

   Each EAP-TTLS message contains a single leg of a half-duplex
   conversation.  The EAP carrier protocol (e.g., PPP, EAPOL, RADIUS)
   may impose constraints on the length of an EAP message.  Therefore it
   may be necessary to fragment an EAP-TTLS message across multiple EAP
   messages.

   Each fragment except for the last MUST have the M bit set, to
   indicate that more data is to follow; the final fragment MUST NOT
   have the M bit set.

   If there are multiple fragments, the first fragment MUST have the L
   bit set and include the length of the entire raw message prior to
   fragmentation.  Fragments other than the first MUST NOT have the L
   bit set.  Unfragmented messages MAY have the L bit set and include
   the length of the message (though this information is redundant).

   Upon receipt of a packet with the M bit set, the receiver MUST
   transmit an Acknowledgement packet.  The receiver is responsible for
   reassembly of fragmented packets.

9.2.3.  Acknowledgement Packets

   An Acknowledgement packet is an EAP-TTLS packet with no additional
   data beyond the Flags octet, and with the L, M, and S bits of the
   Flags octet set to 0.  (Note, however, that the V field MUST still be
   set to the appropriate version number.)

   An Acknowledgement packet is sent for the following purposes:

   -  A Fragment Acknowledgement is sent in response to an EAP packet
      with the M bit set.

   -  When the final EAP packet of the EAP-TTLS negotiation is sent by
      the TTLS server, the client must respond with an Acknowledgement
      packet, to allow the TTLS server to proceed with the EAP protocol
      upon completion of EAP-TTLS (typically by sending or causing to be
      sent a final EAP-Success or EAP-Failure to the client).

Top      Up      ToC       Page 23 
10.  Encapsulation of AVPs within the TLS Record Layer

   Subsequent to the TLS handshake, information may be tunneled between
   client and TTLS server through the use of attribute-value pairs
   (AVPs) encrypted within the TLS record layer.

   The AVP format chosen for EAP-TTLS is compatible with the Diameter
   AVP format.  This does not represent a requirement that Diameter be
   supported by any of the devices or servers participating in an EAP-
   TTLS negotiation.  Use of this format is merely a convenience.
   Diameter is a superset of RADIUS and includes the RADIUS attribute
   namespace by definition, though it does not limit the size of an AVP
   as does RADIUS; RADIUS, in turn, is a widely deployed AAA protocol
   and attribute definitions exist for all commonly used password
   authentication protocols, including EAP.

   Thus, Diameter is not considered normative except as specified in
   this document.  Specifically, the representation of the Data field of
   an AVP in EAP-TTLS is identical to that of Diameter.

   Use of the RADIUS/Diameter namespace allows a TTLS server to easily
   translate between AVPs it uses to communicate to clients and the
   protocol requirements of AAA servers that are widely deployed.  Plus,
   it provides a well-understood mechanism to allow vendors to extend
   that namespace for their particular requirements.

   It is expected that the AVP Codes used in EAP-TTLS will carry roughly
   the same meaning in EAP-TTLS as they do in Diameter and, by
   extension, RADIUS.  However, although EAP-TTLS uses the same AVP
   Codes and syntax as Diameter, the semantics may differ, and most
   Diameter AVPs do not have any well-defined semantics in EAP-TTLS.  A
   separate "EAP-TTLS AVP Usage" registry lists the AVPs that can be
   used within EAP-TTLS and their semantics in this context (see Section
   16 for details).  A TTLS server copying AVPs between an EAP-TTLS
   exchange and a Diameter or RADIUS exchange with a backend MUST NOT
   make assumptions about AVPs whose usage in either EAP-TTLS or the
   backend protocol it does not understand.  Therefore, a TTLS server
   MUST NOT copy an AVP between an EAP-TTLS exchange and a Diameter or
   RADIUS exchange unless the semantics of the AVP are understood and
   defined in both contexts.

10.1.  AVP Format

   The format of an AVP is shown below.  All items are in network, or
   big-endian, order; that is, they have the most significant octet
   first.

Top      Up      ToC       Page 24 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V M r r r r r r|                  AVP Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Vendor-ID (opt)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Data ...
   +-+-+-+-+-+-+-+-+

   AVP Code
      The AVP Code is four octets and, combined with the Vendor-ID field
      if present, identifies the attribute uniquely.  The first 256 AVP
      numbers represent attributes defined in RADIUS [RFC2865].  AVP
      numbers 256 and above are defined in Diameter [RFC3588].

   AVP Flags

      The AVP Flags field is one octet and provides the receiver with
      information necessary to interpret the AVP.

      The 'V' (Vendor-Specific) bit indicates whether the optional
      Vendor-ID field is present.  When set to 1, the Vendor-ID field is
      present and the AVP Code is interpreted according to the namespace
      defined by the vendor indicated in the Vendor-ID field.

      The 'M' (Mandatory) bit indicates whether support of the AVP is
      required.  If this bit is set to 0, this indicates that the AVP
      may be safely ignored if the receiving party does not understand
      or support it.  If set to 1, this indicates that the receiving
      party MUST fail the negotiation if it does not understand the AVP;
      for a TTLS server, this would imply returning EAP-Failure, for a
      client, this would imply abandoning the negotiation.

      The 'r' (reserved) bits are unused and MUST be set to 0 by the
      sender and MUST be ignored by the receiver.

   AVP Length

      The AVP Length field is three octets and indicates the length of
      this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID
      (if present), and Data.

Top      Up      ToC       Page 25 
   Vendor-ID

      The Vendor-ID field is present if the V bit is set in the AVP
      Flags field.  It is four octets and contains the vendor's IANA-
      assigned "SMI Network Management Private Enterprise Codes"
      [RFC3232] value.  Vendors defining their own AVPs must maintain a
      consistent namespace for use of those AVPs within RADIUS,
      Diameter, and EAP-TTLS.

      A Vendor-ID value of zero is equivalent to absence of the Vendor-
      ID field altogether.

   Note that the M bit provides a means for extending the functionality
   of EAP-TTLS while preserving backward compatibility when desired.  By
   setting the M bit of the appropriate AVP(s) to 0 or 1, the party
   initiating the function indicates that support of the function by the
   other party is either optional or required.

10.2.  AVP Sequences

   Data encapsulated within the TLS record layer must consist entirely
   of a sequence of zero or more AVPs.  Each AVP must begin on a four-
   octet boundary relative to the first AVP in the sequence.  If an AVP
   is not a multiple of four octets, it must be padded with zeros to the
   next four-octet boundary.

   Note that the AVP Length does not include the padding.

10.3.  Guidelines for Maximum Compatibility with AAA Servers

   For maximum compatibility with AAA servers, the following guidelines
   for AVP usage are suggested:

   -  Non-vendor-specific AVPs intended for use with AAA servers should
      be selected from the set of attributes defined for RADIUS; that
      is, attributes with codes less than 256.  This provides
      compatibility with both RADIUS and Diameter.

   -  Vendor-specific AVPs intended for use with AAA servers should be
      defined in terms of RADIUS.  Vendor-specific RADIUS attributes
      translate to Diameter (and, hence, to EAP-TTLS) automatically; the
      reverse is not true.  RADIUS vendor-specific attributes use RADIUS
      attribute 26 and include Vendor-ID, vendor-specific attribute
      code, and length; see [RFC2865] for details.

Top      Up      ToC       Page 26 
11.  Tunneled Authentication

   EAP-TTLS permits user authentication information to be tunneled
   within the TLS record layer between client and TTLS server, ensuring
   the security of the authentication information against active and
   passive attack between the client and TTLS server.  The TTLS server
   decrypts and forwards this information to the AAA/H over the AAA
   carrier protocol.

   Any type of password or other authentication may be tunneled.  Also,
   multiple tunneled authentications may be performed.  Normally,
   tunneled authentication is used when the client has not been issued a
   certificate, and the TLS handshake provides only one-way
   authentication of the TTLS server to the client; however, in certain
   cases it may be desired to perform certificate authentication of the
   client during the TLS handshake as well as tunneled user
   authentication afterwards.

11.1.  Implicit Challenge

   Certain authentication protocols that use a challenge/response
   mechanism rely on challenge material that is not generated by the
   authentication server, and therefore the material requires special
   handling.

   In CHAP, MS-CHAP, and MS-CHAP-V2, for example, the access point
   issues a challenge to the client, the client then hashes the
   challenge with the password and forwards the response to the access
   point.  The access point then forwards both challenge and response to
   a AAA server.  But because the AAA server did not itself generate the
   challenge, such protocols are susceptible to replay attack.

   If the client were able to create both challenge and response, anyone
   able to observe a CHAP or MS-CHAP exchange could pose as that user,
   even using EAP-TTLS.

   To make these protocols secure under EAP-TTLS, it is necessary to
   provide a mechanism to produce a challenge that the client cannot
   control or predict.  This is accomplished using the same technique
   described above for generating data connection keying material.

   When a challenge-based authentication mechanism is used, both client
   and TTLS server use the pseudo-random function to generate as many
   octets as are required for the challenge, using the constant string
   "ttls challenge", based on the master secret and random values
   established during the handshake:

Top      Up      ToC       Page 27 
      EAP-TTLS_challenge = PRF-nn(SecurityParameters.master_secret,
                             "ttls challenge",
                             SecurityParameters.client_random +
                             SecurityParameters.server_random);

   The number of octets to be generated (nn) depends on the
   authentication method, and is indicated below for each authentication
   method requiring implicit challenge generation.

11.2.  Tunneled Authentication Protocols

   This section describes the methods for tunneling specific
   authentication protocols within EAP-TTLS.

   For the purpose of explication, it is assumed that the TTLS server
   and AAA/H use RADIUS as a AAA carrier protocol between them.
   However, this is not a requirement, and any AAA protocol capable of
   carrying the required information may be used.

   The client determines which authentication protocol will be used via
   the initial AVPs it sends to the server, as described in the
   following sections.

   Note that certain of the authentication protocols described below
   utilize vendor-specific AVPs originally defined for RADIUS.  RADIUS
   and Diameter differ in the encoding of vendor-specific AVPs: RADIUS
   uses the vendor-specific attribute (code 26), while Diameter uses
   setting of the V bit to indicate the presence of Vendor-ID.  The
   RADIUS form of the vendor-specific attribute is always convertible to
   a Diameter AVP with V bit set.  All vendor-specific AVPs described
   below MUST be encoded using the preferred Diameter V bit mechanism;
   that is, the AVP Code of 26 MUST NOT be used to encode vendor-
   specific AVPs within EAP-TTLS.

11.2.1.  EAP

   When EAP is the tunneled authentication protocol, each tunneled EAP
   packet between the client and TTLS server is encapsulated in an EAP-
   Message AVP, prior to tunneling via the TLS record layer.

   Note that because Diameter AVPs are not limited to 253 octets of
   data, as are RADIUS attributes, the RADIUS mechanism of concatenating
   multiple EAP-Message attributes to represent a longer-than-253-octet
   EAP packet is not appropriate in EAP-TTLS.  Thus, a tunneled EAP
   packet within a single EAP-TTLS message MUST be contained in a single
   EAP-Message AVP.

Top      Up      ToC       Page 28 
   The client initiates EAP by tunneling EAP-Response/Identity to the
   TTLS server.  Depending on the requirements specified for the inner
   method, the client MAY now place the actual username in this packet;
   the privacy of the user's identity is now guaranteed by the TLS
   encryption.  This username is typically a Network Access Identifier
   (NAI) [RFC4282]; that is, it is typically in the following format:

      username@realm

   The @realm portion is optional, and is used to allow the TTLS server
   to forward the EAP packet to the appropriate AAA/H.

   Note that the client has two opportunities to specify realms.  The
   first, in the initial, untunneled EAP-Response/Identity packet prior
   to starting EAP-TTLS, indicates the realm of the TTLS server.  The
   second, occurring as part of the EAP exchange within the EAP-TTLS
   tunnel, indicates the realm of the client's home network.  Thus, the
   access point need only know how to route to the realm of the TTLS
   server; the TTLS server is assumed to know how to route to the
   client's home realm.  This serial routing architecture is anticipated
   to be useful in roaming environments, allowing access points or AAA
   proxies behind access points to be configured only with a small
   number of realms.  (Refer to Section 7.3 for additional information
   distinguishing the untunneled and tunneled versions of the EAP-
   Response/Identity packets.)

   Note that TTLS processing of the initial identity exchange is
   different from plain EAP.  The state machine of TTLS is different.
   However, it is expected that the server side is capable of dealing
   with client initiation, because even normal EAP protocol runs are
   client-initiated over AAA.  On the client side, there are various
   implementation techniques to deal with the differences.  Even a
   TTLS-unaware EAP protocol run could be used, if TTLS makes it appear
   as if an EAP-Request/Identity message was actually received.  This is
   similar to what authenticators do when operating between a client and
   a AAA server.

   Upon receipt of the tunneled EAP-Response/Identity, the TTLS server
   forwards it to the AAA/H in a RADIUS Access-Request.

   The AAA/H may immediately respond with an Access-Reject; in which
   case, the TTLS server completes the negotiation by sending an EAP-
   Failure to the access point.  This could occur if the AAA/H does not
   recognize the user's identity, or if it does not support EAP.

   If the AAA/H does recognize the user's identity and does support EAP,
   it responds with an Access-Challenge containing an EAP-Request, with
   the Type and Type-Data fields set according to the EAP protocol with

Top      Up      ToC       Page 29 
   which the AAA/H wishes to authenticate the client; for example MD5-
   Challenge, One-Time Password (OTP), or Generic Token Card.

   The EAP authentication between client and AAA/H proceeds normally, as
   described in [RFC3748], with the TTLS server acting as a passthrough
   device.  Each EAP-Request sent by the AAA/H in an Access-Challenge is
   tunneled by the TTLS server to the client, and each EAP-Response
   tunneled by the client is decrypted and forwarded by the TTLS server
   to the AAA/H in an Access-Request.

   This process continues until the AAA/H issues an Access-Accept or
   Access-Reject.

   Note that EAP-TTLS does not impose special rules on EAP Notification
   packets; such packets MAY be used within a tunneled EAP exchange
   according to the rules specified in [RFC3748].

   EAP-TTLS provides a reliable transport for the tunneled EAP exchange.
   However, [RFC3748] assumes an unreliable transport for EAP messages
   (see Section 3.1), and provides for silent discard of any EAP packet
   that violates the protocol or fails a method-specific integrity
   check, on the assumption that such a packet is likely a counterfeit
   sent by an attacker.  But since the tunnel provides a reliable
   transport for the inner EAP authentication, errors that would result
   in silent discard according to [RFC3748] presumably represent
   implementation errors when they occur within the tunnel, and SHOULD
   be treated as such in preference to being silently discarded.
   Indeed, silently discarding an EAP message within the tunnel
   effectively puts a halt to the progress of the exchange, and will
   result in long timeouts in cases that ought to result in immediate
   failures.

11.2.2.  CHAP

   The CHAP algorithm is described in [RFC1661]; RADIUS attribute
   formats are described in [RFC2865].

   Both client and TTLS server generate 17 octets of challenge material,
   using the constant string "ttls challenge" as described above.  These
   octets are used as follows:

      CHAP-Challenge    [16 octets]
      CHAP Identifier   [1 octet]

   The client initiates CHAP by tunneling User-Name, CHAP-Challenge, and
   CHAP-Password AVPs to the TTLS server.  The CHAP-Challenge value is
   taken from the challenge material.  The CHAP-Password consists of

Top      Up      ToC       Page 30 
   CHAP Identifier, taken from the challenge material; and CHAP
   response, computed according to the CHAP algorithm.

   Upon receipt of these AVPs from the client, the TTLS server must
   verify that the value of the CHAP-Challenge AVP and the value of the
   CHAP Identifier in the CHAP-Password AVP are equal to the values
   generated as challenge material.  If either item does not match
   exactly, the TTLS server must reject the client.  Otherwise, it
   forwards the AVPs to the AAA/H in an Access-Request.

   The AAA/H will respond with an Access-Accept or Access-Reject.

11.2.3.  MS-CHAP

   The MS-CHAP algorithm is described in [RFC2433]; RADIUS attribute
   formats are described in [RFC2548].

   Both client and TTLS server generate 9 octets of challenge material,
   using the constant string "ttls challenge" as described above.  These
   octets are used as follows:

      MS-CHAP-Challenge  [8 octets]
      Ident              [1 octet]

   The client initiates MS-CHAP by tunneling User-Name, MS-CHAP-
   Challenge and MS-CHAP-Response AVPs to the TTLS server.  The MS-
   CHAP-Challenge value is taken from the challenge material.  The MS-
   CHAP-Response consists of Ident, taken from the challenge material;
   Flags, set according the client preferences; and LM-Response and NT-
   Response, computed according to the MS-CHAP algorithm.

   Upon receipt of these AVPs from the client, the TTLS server MUST
   verify that the value of the MS-CHAP-Challenge AVP and the value of
   the Ident in the client's MS-CHAP-Response AVP are equal to the
   values generated as challenge material.  If either item does not
   match exactly, the TTLS server MUST reject the client.  Otherwise, it
   forwards the AVPs to the AAA/H in an Access-Request.

   The AAA/H will respond with an Access-Accept or Access-Reject.

11.2.4.  MS-CHAP-V2

   The MS-CHAP-V2 algorithm is described in [RFC2759]; RADIUS attribute
   formats are described in [RFC2548].

   Both client and TTLS server generate 17 octets of challenge material,
   using the constant string "ttls challenge" as described above.  These
   octets are used as follows:

Top      Up      ToC       Page 31 
      MS-CHAP-Challenge  [16 octets]
      Ident              [1 octet]

   The client initiates MS-CHAP-V2 by tunneling User-Name, MS-CHAP-
   Challenge, and MS-CHAP2-Response AVPs to the TTLS server.  The MS-
   CHAP-Challenge value is taken from the challenge material.  The MS-
   CHAP2-Response consists of Ident, taken from the challenge material;
   Flags, set to 0; Peer-Challenge, set to a random value; and Response,
   computed according to the MS-CHAP-V2 algorithm.

   Upon receipt of these AVPs from the client, the TTLS server MUST
   verify that the value of the MS-CHAP-Challenge AVP and the value of
   the Ident in the client's MS-CHAP2-Response AVP are equal to the
   values generated as challenge material.  If either item does not
   match exactly, the TTLS server MUST reject the client.  Otherwise, it
   forwards the AVPs to the AAA/H in an Access-Request.

   If the authentication is successful, the AAA/H will respond with an
   Access-Accept containing the MS-CHAP2-Success attribute.  This
   attribute contains a 42-octet string that authenticates the AAA/H to
   the client based on the Peer-Challenge.  The TTLS server tunnels this
   AVP to the client.  Note that the authentication is not yet complete;
   the client must still accept the authentication response of the
   AAA/H.

   Upon receipt of the MS-CHAP2-Success AVP, the client is able to
   authenticate the AAA/H.  If the authentication succeeds, the client
   sends an EAP-TTLS packet to the TTLS server containing no data (that
   is, with a zero-length Data field).  Upon receipt of the empty EAP-
   TTLS packet from the client, the TTLS server considers the MS-CHAP-
   V2 authentication to have succeeded.

   If the authentication fails, the AAA/H will respond with an Access-
   Challenge containing the MS-CHAP-Error attribute.  This attribute
   contains a new Ident and a string with additional information such as
   the error reason and whether a retry is allowed.  The TTLS server
   tunnels this AVP to the client.  If the error reason is an expired
   password and a retry is allowed, the client may proceed to change the
   user's password.  If the error reason is not an expired password or
   if the client does not wish to change the user's password, it simply
   abandons the EAP-TTLS negotiation.

   If the client does wish to change the password, it tunnels MS-CHAP-
   NT-Enc-PW, MS-CHAP2-CPW, and MS-CHAP-Challenge AVPs to the TTLS
   server.  The MS-CHAP2-CPW AVP is derived from the new Ident and
   Challenge received in the MS-CHAP-Error AVP.  The MS-CHAP-Challenge
   AVP simply echoes the new Challenge.

Top      Up      ToC       Page 32 
   Upon receipt of these AVPs from the client, the TTLS server MUST
   verify that the value of the MS-CHAP-Challenge AVP and the value of
   the Ident in the client's MS-CHAP2-CPW AVP match the values it sent
   in the MS-CHAP-Error AVP.  If either item does not match exactly, the
   TTLS server MUST reject the client.  Otherwise, it forwards the AVPs
   to the AAA/H in an Access-Request.

   If the authentication is successful, the AAA/H will respond with an
   Access-Accept containing the MS-CHAP2-Success attribute.  At this
   point, the negotiation proceeds as described above; the TTLS server
   tunnels the MS-CHAP2-Success to the client, and the client
   authenticates the AAA/H based on this AVP.  Then, the client either
   abandons the negotiation on failure or sends an EAP-TTLS packet to
   the TTLS server containing no data (that is, with a zero-length Data
   field), causing the TTLS server to consider the MS-CHAP-V2
   authentication to have succeeded.

   Note that additional AVPs associated with MS-CHAP-V2 may be sent by
   the AAA/H; for example, MS-CHAP-Domain.  The TTLS server MUST tunnel
   such authentication-related attributes along with the MS-CHAP2-
   Success.

11.2.5.  PAP

   The client initiates PAP by tunneling User-Name and User-Password
   AVPs to the TTLS server.

   Normally, in RADIUS, User-Password is padded with nulls to a multiple
   of 16 octets, then encrypted using a shared secret and other packet
   information.

   An EAP-TTLS client, however, does not RADIUS-encrypt the password
   since no such RADIUS variables are available; this is not a security
   weakness since the password will be encrypted via TLS anyway.  The
   client SHOULD, however, null-pad the password to a multiple of 16
   octets, to obfuscate its length.

   Upon receipt of these AVPs from the client, the TTLS server forwards
   them to the AAA/H in a RADIUS Access-Request.  (Note that in the
   Access-Request, the TTLS server must encrypt the User-Password
   attribute using the shared secret between the TTLS server and AAA/H.)

   The AAA/H may immediately respond with an Access-Accept or Access-
   Reject.  The TTLS server then completes the negotiation by sending an
   EAP-Success or EAP-Failure to the access point using the AAA carrier
   protocol.

Top      Up      ToC       Page 33 
   The AAA/H may also respond with an Access-Challenge.  The TTLS server
   then tunnels the AVPs from the AAA/H's challenge to the client.  Upon
   receipt of these AVPs, the client tunnels User-Name and User-
   Password again, with User-Password containing new information in
   response to the challenge.  This process continues until the AAA/H
   issues an Access-Accept or Access-Reject.

   At least one of the AVPs tunneled to the client upon challenge MUST
   be Reply-Message.  Normally, this is sent by the AAA/H as part of the
   challenge.  However, if the AAA/H has not sent a Reply-Message, the
   TTLS server MUST issue one, with null value.  This allows the client
   to determine that a challenge response is required.

   Note that if the AAA/H includes a Reply-Message as part of an
   Access-Accept or Access-Reject, the TTLS server does not tunnel this
   AVP to the client.  Rather, this AVP and all other AVPs sent by the
   AAA/H as part of Access-Accept or Access-Reject are sent to the
   access point via the AAA carrier protocol.

11.3.  Performing Multiple Authentications

   In some cases, it is desirable to perform multiple user
   authentications.  For example, a AAA/H may want first to authenticate
   the user by password, then by token card.

   The AAA/H may perform any number of additional user authentications
   using EAP, simply by issuing a EAP-Request with a new EAP type once
   the previous authentication completes.  Note that each new EAP method
   is subject to negotiation; that is, the client may respond to the EAP
   request for a new EAP type with an EAP-Nak, as described in
   [RFC3748].

   For example, a AAA/H wishing to perform an MD5-Challenge followed by
   Generic Token Card would first issue an EAP-Request/MD5-Challenge and
   receive a response.  If the response is satisfactory, it would then
   issue an EAP-Request/Generic Token Card and receive a response.  If
   that response were also satisfactory, it would accept the user.

   The entire inner EAP exchange comprising multiple authentications is
   considered a single EAP sequence, in that each subsequent request
   MUST contain distinct a EAP Identifier from the previous request,
   even as one authentication completes and another begins.

   The peer identity indicated in the original EAP-Response/Identity
   that initiated the EAP sequence is intended to apply to each of the
   sequential authentications.  In the absence of an application profile
   standard specifying otherwise, additional EAP-Identity exchanges
   SHOULD NOT occur.

Top      Up      ToC       Page 34 
   The conditions for overall success or failure when multiple
   authentications are used are a matter of policy on client and server;
   thus, either party may require that all inner authentications
   succeed, or that at least one inner authentication succeed, as a
   condition for success of the overall authentication.

   Each EAP method is intended to run to completion.  Should the TTLS
   server abandon a method and start a new one, client behavior is not
   defined in this document and is a matter of client policy.

   Note that it is not always feasible to use the same EAP method twice
   in a row, since it may not be possible to determine when the first
   authentication completes and the new authentication begins if the EAP
   type does not change.  Certain EAP methods, such as EAP-TLS, use a
   Start bit to distinguish the first request, thus allowing each new
   authentication using that type to be distinguished from the previous.
   Other methods, such as EAP-MS-CHAP-V2, terminate in a well-defined
   manner, allowing a second authentication of the same type to commence
   unambiguously.  While use of the same EAP method for multiple
   authentications is relatively unlikely, implementers should be aware
   of the issues and avoid cases that would result in ambiguity.

   Multiple authentications using non-EAP methods or a mixture of EAP
   and non-EAP methods is not defined in this document, nor is it known
   whether such an approach has been implemented.

11.4.  Mandatory Tunneled Authentication Support

   To ensure interoperability, in the absence of an application profile
   standard specifying otherwise, an implementation compliant with this
   specification MUST implement EAP as a tunneled authentication method
   and MUST implement MD5-Challenge as an EAP type.  However, such an
   implementation MAY allow the use of EAP, any EAP type, or any other
   tunneled authentication method to be enabled or disabled by
   administrative action on either client or TTLS server.

   In addition, in the absence of an application profile standard
   specifying otherwise, an implementation compliant with this
   specification MUST allow an administrator to configure the use of
   tunneled authentication without the M (Mandatory) bit set on any AVP.

11.5.  Additional Suggested Tunneled Authentication Support

   The following information is provided as non-normative guidance based
   on the experience of the authors and reviewers of this specification
   with existing implementations of EAP-TTLSv0.

Top      Up      ToC       Page 35 
   The following authentication methods are commonly used, and servers
   wishing for broad interoperability across multiple media should
   consider implementing them:

   -  PAP (both for password and token authentication)

   -  MS-CHAP-V2

   -  EAP-MS-CHAP-V2

   -  EAP-GTC

12.  Keying Framework

   In compliance with [RFC5247], Session-Id, Peer-Id, and Server-Id are
   here defined.

12.1.  Session-Id

   The Session-Id uniquely identifies an authentication exchange between
   the client and TTLS server.  It is defined as follows:

      Session-Id = 0x15 || client.random || server.random

12.2.  Peer-Id

   The Peer-Id represents the identity to be used for access control and
   accounting purposes.  When the client presents a certificate as part
   of the TLS handshake, the Peer-Id is determined based on information
   in the certificate, as specified in Section 5.2 of [RFC5216].
   Otherwise, the Peer-Id is null.

12.3.  Server-Id

   The Server-Id identifies the TTLS server.  When the TTLS server
   presents a certificate as part of the TLS handshake, the Server-Id is
   determined based on information in the certificate, as specified in
   Section 5.2 of [RFC5216].  Otherwise, the Server-Id is null.

13.  AVP Summary

   The following table lists each AVP defined in this document, whether
   the AVP may appear in a packet from server to client ("Request")
   and/or in a packet from client to server ("Response"), and whether
   the AVP MUST be implemented ("MI").

Top      Up      ToC       Page 36 
   Name              Request  Response    MI
   ---------------------------------------------------
   User-Name                     X
   User-Password                 X
   CHAP-Password                 X
   Reply-Message        X
   CHAP-Challenge                X
   EAP-Message          X        X         X
   MS-CHAP-Response              X
   MS-CHAP-Error        X
   MS-CHAP-NT-Enc-PW             X
   MS-CHAP-Domain       X
   MS-CHAP-Challenge             X
   MS-CHAP2-Response             X
   MS-CHAP2-Success     X
   MS-CHAP2-CPW                  X



(page 36 continued on part 3)

Next RFC Part