draft-funk-eap-ttls-v1-01.txt

来自「linux 下通过802.1认证的安装包」· 文本 代码 · 共 1,298 行 · 第 1/4 页

   that version number in all subsequent EAP messages. 

8.2.2 Fragmentation 

   Each EAP-TTLSv1 message contains a sequence of TLS messages that 
   represent a single leg of a half-duplex conversation. The EAP 
   carrier protocol (e.g., PPP, EAPOL, RADIUS) may impose constraints 
   on the length of of an EAP message. Therefore it may be necessary to 
   fragment an EAP-TTLSv1 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. 

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



Paul Funk               expires September 2006               [Page 17] 

Internet-Draft                                              March 2006         


8.2.3 Acknowledgement Packets 

   An Acknowledgement packet is an EAP-TTLSv1 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: 

   -  Fragment Acknowledgement 

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

   -  Error Alert Acknowledgement 

      Either party may at any time send a TLS error alert to fail the 
      TLS/IA handshake. 

      If the client sends an error alert to the server, no further EAP-
      TTLS messages are exchanged, and the server sends an EAP-Failure 
      to terminate the conversation. 

      If the server sends an error alert to the client, the client MUST 
      respond with an Acknowledgement packet to allow the conversation 
      to continue. Upon receipt of the Acknowledgement packet, the 
      server sends an EAP-Failure to terminate the conversation.  

   Note that, unlike EAP-TTLSv0, in EAP-TTLSv1 there is no case in 
   which a client sends a packet with data as a result of having no 
   AVPs to send. In EAP-TTLSv1, if no AVPs are to be sent, there will 
   nevertheless be an InnerApplication message carrying zero AVPs, 
   which the client must send. 

9. Security Claims 

   Pursuant to [RFC3748], security claims for EAP-TTLSv1 are as 
   follows: 

   Authentication mechanism: TLS plus arbitrary additional protected  
                              authentication(s) 
   Ciphersuite negotiation:  Yes 
   Mutual authentication:    Yes, in recommended implementation 
   Integrity protection:     Yes 
   Replay protection:        Yes 
   Confidentiality:          Yes 
   Key derivation:           Yes 
   Key strength:             384 bits or higher 
   Dictionary attack prot.:  Yes 
   Fast reconnect:           Yes 
   Crypt. binding:           Yes 



Paul Funk               expires September 2006               [Page 18] 

Internet-Draft                                              March 2006         


   Session independence:     Yes 
   Fragmentation:            Yes 
   Channel binding:          Supported via AVPs, though optional 

10. Security Considerations 

   This draft is entirely about security and the security 
   considerations associated with the mechanisms employed in this 
   document should be considered by implementers. 

   The following additional issues are relevant: 

   -  Anonymity and privacy. EAP-TTLS does not communicate a username 
      in the clear in the initial EAP-Response/Identity. This feature 
      is designed to support anonymity and location privacy from 
      attackers eavesdropping the network path between the client and 
      the TTLS server. However implementers should be aware that other 
      factors - both within EAP-TTLS and elsewhere - may compromise a 
      user's identity. For example, if a user authenticates with a 
      certificate, the subject name in the certificate may reveal the 
      user's identity. Outside of EAP-TTLS, the client's fixed MAC 
      address, or in the case of wireless connections, the client's 
      radio signature, may also reveal information. Additionally, 
      implementers should be aware that a user's identity is not hidden 
      from the TTLS server and may be included in the clear in AAA 
      messages between the TTLS server and the AAA/H server. 

   -  Trust in the TTLS server. EAP-TTLS is designed to allow the use 
      of legacy authentication methods to be extended to mediums like 
      wireless in which eavesdropping the link between the client and 
      the access point is easy. However implementers should be aware of 
      the possibility of attacks by rogue TTLS servers - for example in 
      the event that the inner authentication method is susceptible to 
      dictionary attacks. Therefore it is essential that clients be 
      properly configured to only proceed with inner authentications 
      with trusted TTLS servers, as evidenced by the certificate chain 
      presented by the TTLS server in the TTLS handshake. In general, 
      cipher suites that allow the TTLS server to remain anonymous 
      should be avoided, unless the inner authentication itself 
      provides mutual authentication and is resistant to dictionary 
      attack. 

   -  TTLS server certificate compromise. The use of TTLS server 
      certificates within EAP-TTLS makes EAP-TTLS susceptible to attack 
      in the event that a TTLS server's certificate is compromised. -
      TTLS servers should therefore take care to protect their private 
      key. In addition, certificate revocation methods may be used to 
      mitigate against the possibility of key compromise. [RFC3546] 
      describes a way to integrate one such method - OCSP [RFC2560] - 
      into the TLS handshake - use of this approach may be appropriate 
      within EAP-TTLS. 



Paul Funk               expires September 2006               [Page 19] 

Internet-Draft                                              March 2006         


   -  Listing of data cipher preferences. EAP-TTLS negotiates data 
      cipher suites by having the EAP-TTLS server select the first 
      cipher suite appearing on the client list that also appears on 
      the access point list. In order to maximize security, it is 
      therefore recommended that the client order its list according to 
      security - most secure acceptable cipher suite first, least 
      secure acceptable cipher suite last. 

   -  Forward secrecy. With forward secrecy, revelation of a secret 
      does not compromise session keys previously negotiated based on 
      that secret. Thus, when the TLS key exchange algorithm provides 
      forward secrecy, if a TTLS server certificate's private key is 
      eventually stolen or cracked, tunneled user password information 
      will remain secure as long as that certificate is no longer in 
      use. Diffie-Hellman key exchange is an example of an algorithm 
      that provides forward secrecy. A forward secrecy algorithm should 
      be considered if attacks against recorded authentication or data 
      sessions are considered to pose a significant threat. 

11. References 

11.1 Normative References 

   [TLS/IA]   Funk, P., Blake-Wilson, S., Smith, N., Tschofenig, H. 
               and T. Hardjono, " TLS Inner Application Extension  
               (TLS/IA)", draft-funk-tls-inner-application-extension-
               02.txt, March 2006. 

   [RFC1700]  Reynolds, J., and J. Postel, "Assigned Numbers", RFC 
               1700, October 1994. 

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate 
               Requirement Levels", RFC 2119, March 1997. 

   [RFC2246]  Dierks, T., and C. Allen, "The TLS Protocol Version 
               1.0", RFC 2246, November 1998. 

   [RFC2486]  Aboba, B., and M. Beadles, "The Network Access 
               Identifier", RFC 2486, January 1999. 

   [RFC2548]  Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 
               RFC 2548, March 1999. 

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson, 
               "Remote Authentication Dial In User Service (RADIUS)", 
               RFC 2865, June 2000. 

   [RFC3546]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, 
               J., and T. Wright, "Transport Layer Security (TLS) 
               Extensions", RFC 3546, June 2003. 




Paul Funk               expires September 2006               [Page 20] 

Internet-Draft                                              March 2006         


   [RFC3579]  Aboba, B., and P.Calhoun, "RADIUS (Remote Authentication 
               Dial In User Service) Support For Extensible 
               Authentication Protocol (EAP)", RFC 3579, September 
               2003. 

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 
               Arkko, "Diameter Base Protocol", RFC 3588, July 2003. 

   [RFC3784]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and 
               H. Levkowetz, "PPP Extensible Authentication Protocol 
               (EAP)", RFC 3784, June 2004. 

11.2 Informative References 

   [RFC1661]  Simpson, W. (Editor), "The Point-to-Point Protocol 
               (PPP)", STD 51, RFC 1661, July 1994. 

   [RFC1994]  Simpson, W., "PPP Challenge Handshake Authentication 
               Protocol (CHAP)", RFC 1994, August 1996. 

   [RFC2716]  Aboba, B., and D. Simon, "PPP EAP TLS Authentication 
               Protocol", RFC 2716, October 1999. 

   [RFC2433]  Zorn, G., and S. Cobb, "Microsoft PPP CHAP Extensions", 
               RFC 2433, October 1998. 

   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 
               Adams, "Internet X.509 Public Key Infrastructure: Online 
               Certificate Status Protocol - OCSP", RFC 2560, June 
               1999. 

   [RFC2759]  Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", 
               RFC 2759, January 2000. 

   [EAP-PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G., 
               and S. Josefsson, "Protected EAP Protocol (PEAP) Version 
               2", draft-josefsson-pppext-eap-tls-eap-08.txt, July 
               2004. 

   [TLS-PSK]  Eronen, P., and H. Tschofenig, "Pre-Shared Key 
               Ciphersuites for Transport Layer Security (TLS)", draft-
               ietf-tls-psk-01.txt, August 2004. 

   [802.1X]   IEEE Standards for Local and Metropolitan Area Networks:  
               Port based Network Access Control, IEEE Std 802.1X-2001, 
               June 2001. 

   [MITM]     Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 
               in Tunneled Authentication", 
               http://www.saunalahti.fi/~asokan/research/mitm.html, 
               Nokia Research Center, Finland, October 24 2002. 



Paul Funk               expires September 2006               [Page 21] 

Internet-Draft                                              March 2006         


   [KEYING]   Aboba, B., Simon, D., Arkko, J. and H. Levkowetz, "EAP 
               Key Management Framework", draft-ietf-eap-keying-01.txt 
               (work in progress), October 2003. 

   [IKEv2]    C.Kaufman, "Internet Key Exchange (IKEv2) Protocol", 
               draft-ietf-ipsec-ikev2-16.txt (work in progress), 
               September 2004. 

   [AAA-EAP]  Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 
               Authentication Protocol (EAP) Application", draft-ietf-
               aaa-eap-03.txt (work in progress), October 2003. 

12. Authors' Addresses 

   Questions about this memo can be directed to: 

      Paul Funk 
      Juniper Networks 
      222 Third Street 
      Cambridge, MA 02142 
      USA 
      Phone:  [phone] 
      E-mail: [e-mail] 

      Simon Blake-Wilson 
      Basic Commerce & Industries, Inc. 
      304 Harper Drive, Suite 203 
      Moorestown, NJ 08057 
      Phone: [phone] 
      E-mail: [e-mail] 

Disclaimer of Validity 

   This document and the information contained herein are provided on 
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 

Copyright Statement 

   Copyright (C) The Internet Society (2006).  This document is subject 
   to the rights, licenses and restrictions contained in BCP 78, and 
   except as set forth therein, the authors retain all their rights. 








Paul Funk               expires September 2006               [Page 22]