draft-ietf-pppext-eap-ttls-05.txt

Linux上的802.1x 的supplicant的实现。很多supplicant程序都是基于它开发的

   The client must, however, send other required AVPs, in particular 
   key distribution AVPs, that are not associated with tunneled 
   authentication in its first EAP-TTLS packet to the server that is 
   capable of containing phase 2 TLS messages. The TTLS server does not 
   retain client AVPs or key distribution preferences as part of 
   session state, and the client is expected to resend those AVPs in 
   each negotiation.  

   Thus phase 2 of a resumed session proceeds just as would a new 
   session, minus tunneled authentication AVPs. For example, the client 
   would send its key distribution preferences, and the TTLS server 
   would respond with its key distribution selection. 




Paul Funk                expires January 2005                [Page 15] 

Internet-Draft                                              April 2004         


   While the TTLS server does not retain client AVPs from session to 
   session, it must retain authorization information returned by the 
   AAA/H for use in resumed sessions. A resumed session must operate 
   under the same authorizations as the original session, and the TTLS 
   server must be prepared to send the appropriate information back to 
   the access point. Authorization information might include the 
   maximum time for the session, the maximum allowed bandwidth, packet 
   filter information and the like. The TTLS server is responsible for 
   modifying time values, such as Session-Timeout, appropriately for 
   each resumed session. 

   A TTLS server must not permit a session to be resumed if that 
   session did not result in a successful authentication of the user 
   during phase 2. The consequence of incorrectly implementing this 
   aspect of session resumption would be catastrophic; any attacker 
   could easily gain network access by first initiating a session that 
   succeeds in the TLS handshake but fails during phase 2 
   authentication, and then resuming that session. 

   [Implementation note: Toolkits that implement TLS often cache 
   resumable TLS sessions automatically. Implementers must take care to 
   override such automatic behavior, and prevent sessions from being 
   cached for possible resumption until the user has been positively 
   authenticated during phase 2.] 

6.4.1 TTLS Server Guidelines for Session Resumption 

   When a domain comprises multiple TTLS servers, a client's attempt to 
   resume a session may fail because each EAP-TTLS negotiation may be 
   routed to a different TTLS server. 

   One strategy to ensure that subsequent EAP-TTLS negotiations are 
   routed to the original TTLS server is for each TTLS server to encode 
   its own identifying information, for example, IP address, in the 
   session IDs that it generates. This would allow any TTLS server 
   receiving a session resumption request to forward the request to the 
   TTLS server that established the original session. 

7. Generating Keying Material 

   When record layer security is instantiated at the end of a TLS 
   handshake, a pseudo-random function (PRF) is used to expand the 
   negotiated master secret, server random value and client random 
   value into a sequence of octets that is used as keying material for 
   the record layer. The length of this sequence depends on the 
   negotiated cipher suite, and contains the following components: 








Paul Funk                expires January 2005                [Page 16] 

Internet-Draft                                              April 2004         


      client_write_MAC_secret 
      server_write_MAC_secret 
      client_write_key 
      server_write_key 
      client_write_IV (optional) 
      server_write_IV (optional) 

   The ASCII-encoded constant string "key expansion" is used as input 
   to the pseudo-random function to generate this sequence. 

   EAP-TTLS leverages this technique to create keying material for use 
   in the data connection between client and access point. Exactly the 
   same PRF is used to generate as much keying material as required, 
   with the constant string set to "ttls keying material", as follows: 

      EAP-TTLS_keying_material = PRF(SecurityParameters.master_secret, 
                             "ttls keying material", 
                             SecurityParameters.client_random + 
                             SecurityParameters.server_random); 

   The master secret, client random and server random used to generate 
   the data connection keying material must be those established during 
   the TLS handshake. Both client and TTLS server generate this keying 
   material, and they are guaranteed to be the same if the handshake 
   succeeded. The TTLS server distributes this keying material to the 
   access point via the AAA carrier protocol. 

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

8. EAP-TTLS Encoding 

   EAP-TTLS is a protocol within EAP. Its assigned EAP number is 21. 

   Except as described in the subsections below, EAP-TTLS's encoding of 
   TLS messages within EAP is identical to EAP-TLS's encoding of TLS 
   messages within EAP. See [1] for details. 

8.1 EAP-TTLS Start Packet 

   The EAP-TTLS Start packet (with S-bit set) may, in a future 
   specification, be allowed to contain data (the EAP-TLS Start packet 
   does not).  

   Thus, the data contents of an EAP-TTLS Start packet are reserved for 
   future standardization; in the meantime, servers must not include 
   any data in an EAP-TTLS Start packet, and clients must ignore such 
   data but must not reject a Start packet that contains data. 



Paul Funk                expires January 2005                [Page 17] 

Internet-Draft                                              April 2004         


8.2 EAP-TTLS Packets with No Data 

   One point of clarification has to do with an EAP-TTLS packet (other 
   than a Start packet) that contains no data. 

   EAP-TLS defines the use of such a packet as a fragment ACK. When 
   either party must fragment an EAP-TLS packet, the other party 
   responds with a fragment ACK to allow the original party to send the 
   next fragment. 

   EAP-TTLS uses the fragment ACK in the same way. There are also other 
   instances where a EAP-TTLS packet with no data might be sent: 

   -  When the final EAP packet of the EAP-TTLS negotiation is sent by 
      the TTLS server, the client must respond with a EAP-TTLS packet 
      with no data, to allow the TTLS server to issue its final EAP-
      Success or EAP-Failure packet. 

   -  It is possible for a EAP-TTLS packet with no data to be sent in 
      the middle of a negotiation. Such a packet is simply interpreted 
      as packet with no AVPs. For example, during session resumption, 
      the client sends its Finished message first, then the TTLS server 
      replies with its Finished message. The TTLS server cannot 
      piggyback key distribution AVPs within the Record Layer in the 
      same EAP-TTLS packet containing its Finished message, because it 
      must wait for the client to indicate its key distribution 
      preferences. But it is possible that the client has no 
      preferences, and thus has no AVPs to send. The client simply 
      sends a EAP-TTLS packet with no data, to allow the server to 
      continue the negotiation by sending its key distribution 
      selection. 

9. Encapsulation of AVPs within the TLS Record Layer 

   Subsequent to the TLS handshake, information is 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 at all represent a requirement that 
   Diameter be supported by any of the devices or servers participating 
   in a 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 AVP Codes used in EAP-TTLS are 
   semantically equivalent to those defined for Diameter, and, by 



Paul Funk                expires January 2005                [Page 18] 

Internet-Draft                                              April 2004         


   extension, RADIUS. Also, 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. 

9.1 AVP Format 

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

    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. AVP 
      numbers 256 and above are defined in Diameter. 

   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. 




Paul Funk                expires January 2005                [Page 19] 

Internet-Draft                                              April 2004         


      The 'r' (reserved) bits are unused and must be set to 0. 

   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. 

   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" [9] 
      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. 

9.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 4-octet 
   boundary relative to the first AVP in the sequence. If an AVP is not 
   a multiple of 4 octets, it must be padded with 0s to the next 4-
   octet boundary. 

   Note that the AVP Length does not include the padding.