rfc2716.txt

radius服务器

RFC 2716          PPP EAP TLS Authentication Protocol       October 1999


      The L bit (length included) is set to indicate the presence of the
      four octet TLS Message Length field, and MUST be set for the first
      fragment of a fragmented TLS message or set of messages. The M bit
      (more fragments) is set on all but the last fragment. The S bit
      (EAP-TLS start) is set in an EAP-TLS Start message. This
      differentiates the EAP-TLS Start message from a fragment
      acknowledgement.

   TLS Message Length

      The TLS Message Length field is four octets, and is present only
      if the L bit is set.  This field provides the total length of the
      TLS message or set of messages that is being fragmented.

   TLS data

      The TLS data consists of the encapsulated TLS packet in TLS record
      format.

4.3.  PPP EAP TLS Response Packet

   A summary of the PPP EAP TLS Response packet format is shown below.
   The fields are transmitted from 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     |      TLS Message Length
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     TLS Message Length        |       TLS Data...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Code

      2

   Identifier

      The Identifier field is one octet and MUST match the Identifier
      field from the corresponding request.

   Length

      The Length field is two octets and indicates the length of the EAP
      packet including the Code, Identifir, Length, Type, and TLS data
      fields.



Aboba & Simon                 Experimental                     [Page 19]

RFC 2716          PPP EAP TLS Authentication Protocol       October 1999


   Type

      13 - EAP TLS

   Flags

      0 1 2 3 4 5 6 7 8
      +-+-+-+-+-+-+-+-+
      |L M S R R R R R|
      +-+-+-+-+-+-+-+-+

      L = Length included
      M = More fragments
      S = EAP-TLS start
      R = Reserved

      The L bit (length included) is set to indicate the presence of the
      four octet TLS Message Length field, and MUST be set for the first
      fragment of a fragmented TLS message or set of messages. The M bit
      (more fragments) is set on all but the last fragment. The S bit
      (EAP-TLS start) is set in an EAP-TLS Start message.  This
      differentiates the EAP-TLS Start message from a fragment
      acknowledgement.

   TLS Message Length

      The TLS Message Length field is four octets, and is present only
      if the L bit is set. This field provides the total length of the
      TLS message or set of messages that is being fragmented.

   TLS data

      The TLS data consists of the encapsulated TLS packet in TLS record
      format.

















Aboba & Simon                 Experimental                     [Page 20]

RFC 2716          PPP EAP TLS Authentication Protocol       October 1999


5.  References

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

   [2]  Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti,
        "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.

   [3]  Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January
        1994.

   [4]  Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC
        1321, April 1992.

   [5]  Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
        Protocol (EAP)", RFC 2284, March 1998.

   [6]  Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June
        1996.

   [7]  National Bureau of Standards, "Data Encryption Standard", FIPS
        PUB 46 (January 1977).

   [8]  National Bureau of Standards, "DES Modes of Operation", FIPS PUB
        81 (December 1980).

   [9]  Sklower, K. amd G. Meyer, "The PPP DES Encryption Protocol,
        Version 2 (DESE-bis)", RFC 2419, September 1998.

   [10] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)",
        RFC 2420, September 1998.

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

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

   [13] Rand, D., "The PPP Compression Control Protocol", RFC 1962, June
        1996.











Aboba & Simon                 Experimental                     [Page 21]

RFC 2716          PPP EAP TLS Authentication Protocol       October 1999


6.  Security Considerations

6.1.  Certificate revocation

   Since the EAP server is on the Internet during the EAP conversation,
   the server is capable of following a certificate chain or verifying
   whether the peer's certificate has been revoked. In contrast, the
   peer may or may not have Internet connectivity, and thus while it can
   validate the EAP server's certificate based on a pre-configured set
   of CAs, it may not be able to follow a certificate chain or verify
   whether the EAP server's certificate has been revoked.

   In the case where the peer is initiating a voluntary Layer 2 tunnel
   using PPTP or L2TP, the peer will typically already have a PPP
   interface and Internet connectivity established at the time of tunnel
   initiation.  As a result, during the EAP conversation it is capable
   of checking for certificate revocation.

   However, in the case where the peer is initiating an intial PPP
   conversation, it will not have Internet connectivity and is therefore
   not capable of checking for certificate revocation until after NCP
   negotiation completes and the peer has access to the Internet. In
   this case, the peer SHOULD check for certificate revocation after
   connecting to the Internet.

6.2.  Separation of the EAP server and PPP authenticator

   As a result of the EAP-TLS conversation, the EAP endpoints will
   mutually authenticate, negotiate a ciphersuite, and derive a session
   key for subsequent use in PPP encryption. Since the peer and EAP
   client reside on the same machine, it is necessary for the EAP client
   module to pass the session key to the PPP encryption module.

   The situation may be more complex on the PPP authenticator, which may
   or may not reside on the same machine as the EAP server. In the case
   where the EAP server and PPP authenticator reside on different
   machines, there are several implications for security. Firstly, the
   mutual authentication defined in EAP-TLS will occur between the peer
   and the EAP server, not between the peer and the authenticator. This
   means that as a result of the EAP-TLS conversation, it is not
   possible for the peer to validate the identity of the NAS or tunnel
   server that it is speaking to.

   The second issue is that the session key negotiated between the peer
   and EAP server will need to be transmitted to the authenticator.
   Therefore a mechanism needs to be provided to transmit the session
   key from the EAP server to the authenticator or tunnel server that
   needs to use the key. The specification of this transit mechanism is



Aboba & Simon                 Experimental                     [Page 22]

RFC 2716          PPP EAP TLS Authentication Protocol       October 1999


   outside the scope of this document.

6.3.  Relationship of PPP encryption to other security mechanisms

   It is envisaged that EAP-TLS will be used primarily with dialup PPP
   connections. However, there are also circumstances in which PPP
   encryption may be used along with Layer 2 tunneling protocols such as
   PPTP and L2TP.

   In compulsory layer 2 tunneling, a PPP peer makes a connection to a
   NAS or router which tunnels the PPP packets to a tunnel server.
   Since with compulsory tunneling a PPP peer cannot tell whether its
   packets are being tunneled, let alone whether the network device is
   securing the tunnel, if security is required then the client must
   make its own arrangements. In the case where all endpoints cannot be
   relied upon to implement IPSEC, TLS, or another suitable security
   protocol, PPP encryption provides a convenient means to ensure the
   privacy of packets transiting between the client and the tunnel
   server.

7.  Acknowledgments

   Thanks to Terence Spies, Glen Zorn and Narendra Gidwani of Microsoft
   for useful discussions of this problem space.

8.  Authors' Addresses

   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

   Phone: [phone]
   EMail: [e-mail]


   Dan Simon
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

   Phone: [phone]
   EMail: [e-mail]








Aboba & Simon                 Experimental                     [Page 23]

RFC 2716          PPP EAP TLS Authentication Protocol       October 1999


9.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Aboba & Simon                 Experimental                     [Page 24]