doc/rfc/rfc2716.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                            B. Aboba
   8 Requests for Commments: 2716                                     D. Simon
   9 Category: Experimental                                          Microsoft
  10                                                              October 1999
  11
  12
  13                   PPP EAP TLS Authentication Protocol
  14
  15 Status of this Memo
  16
  17    This memo defines an Experimental Protocol for the Internet
  18    community.  It does not specify an Internet standard of any kind.
  19    Discussion and suggestions for improvement are requested.
  20    Distribution of this memo is unlimited.
  21
  22 Copyright Notice
  23
  24    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  25
  26 1.  Abstract
  27
  28    The Point-to-Point Protocol (PPP) provides a standard method for
  29    transporting multi-protocol datagrams over point-to-point links.  PPP
  30    also defines an extensible Link Control Protocol (LCP), which can be
  31    used to negotiate authentication methods, as well as an Encryption
  32    Control Protocol (ECP), used to negotiate data encryption over PPP
  33    links, and a Compression Control Protocol (CCP), used to negotiate
  34    compression methods.  The Extensible Authentication Protocol (EAP) is
  35    a PPP extension that provides support for additional authentication
  36    methods within PPP.
  37
  38    Transport Level Security (TLS) provides for mutual authentication,
  39    integrity-protected ciphersuite negotiation and key exchange between
  40    two endpoints.  This document describes how EAP-TLS, which includes
  41    support for fragmentation and reassembly, provides for these TLS
  42    mechanisms within EAP.
  43
  44 2.  Introduction
  45
  46    The Extensible Authentication Protocol (EAP), described in [5],
  47    provides a standard mechanism for support of additional
  48    authentication methods within PPP.  Through the use of EAP, support
  49    for a number of authentication schemes may be added, including smart
  50    cards, Kerberos, Public Key, One Time Passwords, and others. To date
  51    however, EAP methods such as [6] have focussed on authenticating a
  52    client to a server.
  53
  54
  55
  56
  57
  58 Aboba & Simon                 Experimental                      [Page 1]
  59 \f
  60 RFC 2716          PPP EAP TLS Authentication Protocol       October 1999
  61
  62
  63    However, it may be desirable to support mutual authentication, and
  64    since PPP encryption protocols such as [9] and [10] assume existence
  65    of a session key, it is useful to have a mechanism for session key
  66    establishment. Since design of secure key management protocols is
  67    non-trivial, it is desirable to avoid creating new mechanisms for
  68    this. The EAP protocol described in this document allows a PPP peer
  69    to take advantage of the protected ciphersuite negotiation, mutual
  70    authentication and key management capabilities of the TLS protocol,
  71    described in [12].
  72
  73 2.1.  Requirements language
  74
  75    In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
  76    "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
  77    described in [11].
  78
  79 3.  Protocol overview
  80
  81 3.1.  Overview of the EAP-TLS conversation
  82
  83    As described in [5], the EAP-TLS conversation will typically begin
  84    with the authenticator and the peer negotiating EAP.  The
  85    authenticator will then typically send an EAP-Request/Identity packet
  86    to the peer, and the peer will respond with an EAP-Response/Identity
  87    packet to the authenticator, containing the peer's userId.
  88
  89    From this point forward, while nominally the EAP conversation occurs
  90    between the PPP authenticator and the peer, the authenticator MAY act
  91    as a passthrough device, with the EAP packets received from the peer
  92    being encapsulated for transmission to a RADIUS server or backend
  93    security server. In the discussion that follows, we will use the term
  94    "EAP server" to denote the ultimate endpoint conversing with the
  95    peer.
  96
  97    Once having received the peer's Identity, the EAP server MUST respond
  98    with an EAP-TLS/Start packet, which is an EAP-Request packet with
  99    EAP-Type=EAP-TLS, the Start (S) bit set, and no data.  The EAP-TLS
 100    conversation will then begin, with the peer sending an EAP-Response
 101    packet with EAP-Type=EAP-TLS.  The data field of that packet will
 102    encapsulate one or more TLS records in TLS record layer format,
 103    containing a TLS client_hello handshake message.  The current cipher
 104    spec for the TLS records will be TLS_NULL_WITH_NULL_NULL and null
 105    compression.  This current cipher spec remains the same until the
 106    change_cipher_spec message signals that subsequent records will have
 107    the negotiated attributes for the remainder of the handshake.
 108
 109
 110
 111
 112
 113
 114 Aboba & Simon                 Experimental                      [Page 2]
 115 \f
 116 RFC 2716          PPP EAP TLS Authentication Protocol       October 1999
 117
 118
 119    The client_hello message contains the client's TLS version number, a
 120    sessionId, a random number, and a set of ciphersuites supported by
 121    the client. The version offered by the client MUST correspond to TLS
 122    v1.0 or later.
 123
 124    The EAP server will then respond with an EAP-Request packet with
 125    EAP-Type=EAP-TLS. The data field of this packet will encapsulate one
 126    or more TLS records. These will contain a TLS server_hello handshake
 127    message, possibly followed by TLS certificate, server_key_exchange,
 128    certificate_request, server_hello_done and/or finished handshake
 129    messages, and/or a TLS change_cipher_spec message.  The server_hello
 130    handshake message contains a TLS version number, another random
 131    number, a sessionId, and a ciphersuite.  The version offered by the
 132    server MUST correspond to TLS v1.0 or later.
 133
 134    If the client's sessionId is null or unrecognized by the server, the
 135    server MUST choose the sessionId to establish a new session;
 136    otherwise, the sessionId  will  match  that  offered by the client,
 137    indicating a resumption of the previously established session with
 138    that sessionID.  The server will also choose a ciphersuite from those
 139    offered by  the client; if the session matches the client's, then the
 140    ciphersuite MUST match the one negotiated during the handshake
 141    protocol execution that established the session.
 142
 143    The purpose of the sessionId within the TLS protocol is to allow for
 144    improved efficiency in the case where a client repeatedly attempts to
 145    authenticate to an EAP server within a short period of time. While
 146    this model was developed for use with HTTP authentication, it may
 147    also have application to PPP authentication (e.g. multilink).
 148
 149    As a result, it is left up to the peer whether to attempt to continue
 150    a previous session, thus shortening the TLS conversation. Typically
 151    the peer's decision will be made based on the time elapsed since the
 152    previous authentication attempt to that EAP server. Based on the
 153    sessionId chosen by the peer, and the time elapsed since the previous
 154    authentication, the EAP server will decide whether to allow the
 155    continuation, or whether to choose a new session.
 156
 157    In the case where the EAP server and authenticator reside on the same
 158    device, then client will only be able to continue sessions when
 159    connecting to the same NAS or tunnel server. Should these devices be
 160    set up in a rotary or round-robin then it may not be possible for the
 161    peer to know in advance the authenticator it will be connecting to,
 162    and therefore which sessionId to attempt to reuse. As a result, it is
 163    likely that the continuation attempt will fail. In the case where the
 164    EAP authentication is remoted then continuation is much more likely
 165    to be successful, since multiple NAS devices and tunnel servers will
 166    remote their EAP authentications to the same RADIUS server.
 167
 168
 169
 170 Aboba & Simon                 Experimental                      [Page 3]
 171 \f
 172 RFC 2716          PPP EAP TLS Authentication Protocol       October 1999
 173
 174
 175    If the EAP server is resuming a previously established session, then
 176    it MUST include only a TLS change_cipher_spec message and a TLS
 177    finished handshake message after the server_hello message.  The
 178    finished message contains the EAP server's authentication response to
 179    the peer.  If the EAP server is not resuming a previously established
 180    session, then it MUST include a TLS server_certificate handshake
 181    message, and a server_hello_done handshake message MUST be the last
 182    handshake message encapsulated in this EAP-Request packet.
 183
 184    The certificate message contains a public key certificate chain for
 185    either a key exchange public key (such as an RSA or Diffie-Hellman
 186    key exchange public key) or a signature public key (such as an RSA or
 187    DSS signature public key).  In the latter case, a TLS
 188    server_key_exchange handshake message MUST also be included to allow
 189    the key exchange to take place.
 190
 191    The certificate_request message is included when the server desires
 192    the client to authenticate itself via public key. While the EAP
 193    server SHOULD require client authentication, this is not a
 194    requirement, since it may be possible that the server will require
 195    that the peer authenticate via some other means.
 196
 197    The peer MUST respond to the EAP-Request with an EAP-Response packet
 198    of EAP-Type=EAP-TLS.  The data field of this packet will encapsulate
 199    one or more TLS records containing a TLS change_cipher_spec message
 200    and finished handshake message, and possibly certificate,
 201    certificate_verify and/or client_key_exchange handshake messages.  If
 202    the preceding server_hello message sent by the EAP server in the
 203    preceding EAP-Request packet indicated the resumption of a previous
 204    session, then the peer MUST send only the change_cipher_spec and
 205    finished handshake messages.  The finished message contains the
 206    peer's authentication response to the EAP server.
 207
 208    If the preceding server_hello message sent by the EAP server in the
 209    preceeding EAP-Request packet did not indicate the resumption of a
 210    previous session, then the peer MUST send, in addition to the
 211    change_cipher_spec and finished messages, a client_key_exchange
 212    message, which completes the exchange of a shared master secret
 213    between the peer and the EAP server.  If the EAP server sent a
 214    certificate_request message in the preceding EAP-Request packet, then
 215    the peer MUST send, in addition, certificate and certificate_verify
 216    handshake messages.  The former contains a certificate for the peer's
 217    signature public key, while the latter contains the peer's signed
 218    authentication response to the EAP server. After receiving this
 219    packet, the EAP server will verify the peer's certificate and digital
 220    signature, if requested.
 221
 222
 223
 224
 225
 226 Aboba & Simon                 Experimental                      [Page 4]
 227 \f
 228 RFC 2716          PPP EAP TLS Authentication Protocol       October 1999
 229
 230
 231    If the peer's authentication is unsuccessful, the EAP server SHOULD
 232    send an EAP-Request packet with EAP-Type=EAP-TLS, encapsulating a TLS
 233    record containing the appropriate TLS alert message.  The EAP server
 234    SHOULD send a TLS alert message rather immediately terminating the
 235    conversation so as to allow the peer to inform the user of the cause
 236    of the failure and possibly allow for a restart of the conversation.
 237
 238    To ensure that the peer receives the TLS alert message, the EAP
 239    server MUST wait for the peer to reply with an EAP-Response packet.
 240    The EAP-Response packet sent by the peer MAY encapsulate a TLS
 241    client_hello handshake message, in which case the EAP server MAY
 242    allow the EAP-TLS conversation to be restarted, or it MAY contain an
 243    EAP-Response packet with EAP-Type=EAP-TLS and no data, in which case
 244    the EAP-Server MUST send an EAP-Failure packet, and terminate the
 245    conversation. It is up to the EAP server whether to allow restarts,
 246    and if so, how many times the conversation can be restarted. An EAP
 247    Server implementing restart capability SHOULD impose a limit on the
 248    number of restarts, so as to protect against denial of service
 249    attacks.
 250
 251    If the peers authenticates successfully, the EAP server MUST respond
 252    with an EAP-Request packet with EAP-Type=EAP-TLS, which includes, in
 253    the case of a new TLS session, one or more TLS records containing TLS
 254    change_cipher_spec and finished handshke messages.  The latter
 255    contains the EAP server's authentication response to the peer.  The
 256    peer will then verify the hash in order to authenticate the EAP
 257    server.
 258
 259    If the EAP server authenticates unsuccessfully, the peer MAY send an
 260    EAP-Response packet of EAP-Type=EAP-TLS containing a TLS Alert
 261    message identifying the reason for the failed authentication. The
 262    peer MAY send a TLS alert message rather than immediately terminating
 263    the conversation so as to allow the EAP server to log the cause of
 264    the error for examination by the system administrator.
 265
 266    To ensure that the EAP Server receives the TLS alert message, the
 267    peer MUST wait for the EAP-Server to reply before terminating the
 268    conversation.  The EAP Server MUST reply with an EAP-Failure packet
 269    since server authentication failure is a terminal condition.
 270
 271    If the EAP server authenticates successfully, the peer MUST send an
 272    EAP-Response packet of EAP-Type=EAP-TLS, and no data.  The EAP-Server
 273    then MUST respond with an EAP-Success message.
 274
 275
 276
 277
 278
 279
 280
 281
 282 Aboba & Simon                 Experimental                      [Page 5]
 283 \f
 284 RFC 2716          PPP EAP TLS Authentication Protocol       October 1999
 285
 286
 287 3.2.  Retry behavior
 288
 289    As with other EAP protocols, the EAP server is responsible for retry
 290    behavior. This means that if the EAP server does not receive a reply
 291    from the peer, it MUST resend the EAP-Request for which it has not
 292    yet received an EAP-Response. However, the peer MUST NOT resend EAP-
 293    Response packets without first being prompted by the EAP server.
 294
 295    For example, if the initial EAP-TLS start packet sent by the EAP
 296    server were to be lost, then the peer would not receive this packet,
 297    and would not respond to it. As a result, the EAP-TLS start packet
 298    would be resent by the EAP server. Once the peer received the EAP-TLS
 299    start packet, it would send an EAP-Response encapsulating the
 300    client_hello message.  If the EAP-Response were to be lost, then the
 301    EAP server would resend the initial EAP-TLS start, and the peer would
 302    resend the EAP-Response.
 303
 304    As a result, it is possible that a peer will receive duplicate EAP-
 305    Request messages, and may send duplicate EAP-Responses.  Both the
 306    peer and the EAP-Server should be engineered to handle this
 307    possibility.
 308
 309 3.3.  Fragmentation
 310
 311    A single TLS record may be up to 16384 octets in length, but a TLS
 312    message may span multiple TLS records, and a TLS certificate message
 313    may in principle be as long as 16MB. The group of EAP-TLS messages
 314    sent in a single round may thus be larger than the PPP MTU size, the
 315    maximum RADIUS packet size of 4096 octets, or even the Multilink
 316    Maximum Received Reconstructed Unit (MRRU).  As described in [2], the
 317    multilink MRRU is negotiated via the Multilink MRRU LCP option, which
 318    includes an MRRU length field of two octets, and thus can support
 319    MRRUs as large as 64 KB.
 320
 321    However, note that in order to protect against reassembly lockup and
 322    denial of service attacks, it may be desirable for an implementation
 323    to set a maximum size for one such group of TLS messages. Since a
 324    typical certificate chain is rarely longer than a few thousand
 325    octets, and no other field is likely to be anwhere near as long, a
 326    reasonable choice of maximum acceptable message length might be 64
 327    KB.
 328
 329    If this value is chosen, then fragmentation can be handled via the
 330    multilink PPP fragmentation mechanisms described in [2]. While this
 331    is desirable, there may be cases in which multilink or the MRRU LCP
 332    option cannot be negotiated. As a result, an EAP-TLS implementation
 333    MUST provide its own support for fragmentation and reassembly.
 334
 335
 336
 337
 338 Aboba & Simon                 Experimental                      [Page 6]
 339 \f
 340 RFC 2716          PPP EAP TLS Authentication Protocol       October 1999
 341
 342
 343    Since EAP is a simple ACK-NAK protocol, fragmentation support can be
 344    added in a simple manner. In EAP, fragments that are lost or damaged
 345    in transit will be retransmitted, and since sequencing information is
 346    provided by the Identifier field in EAP, there is no need for a
 347    fragment offset field as is provided in IPv4.
 348
 349    EAP-TLS fragmentation support is provided through addition of a flags
 350    octet within the EAP-Response and EAP-Request packets, as well as a
 351    TLS Message Length field of four octets. Flags include the Length
 352    included (L), More fragments (M), and EAP-TLS Start (S) bits. The L
 353    flag is set to indicate the presence of the four octet TLS Message
 354    Length field, and MUST be set for the first fragment of a fragmented
 355    TLS message or set of messages. The M flag is set on all but the last
 356    fragment. The S flag is set only within the EAP-TLS start message
 357    sent from the EAP server to the peer. The TLS Message Length field is
 358    four octets, and provides the total length of the TLS message or set
 359    of messages that is being fragmented; this simplifies buffer
 360    allocation.
 361
 362    When an EAP-TLS peer receives an EAP-Request packet with the M bit
 363    set, it MUST respond with an EAP-Response with EAP-Type=EAP-TLS and
 364    no data.  This serves as a fragment ACK. The EAP server MUST wait
 365    until it receives the EAP-Response before sending another fragment.
 366    In order to prevent errors in processing of fragments, the EAP server
 367    MUST increment the Identifier field for each fragment contained
 368    within an EAP-Request, and the peer MUST include this Identifier
 369    value in the fragment ACK contained within the EAP-Reponse.
 370    Retransmitted fragments will contain the same Identifier value.
 371
 372    Similarly, when the EAP server receives an EAP-Response with the M
 373    bit set, it MUST respond with an EAP-Request with EAP-Type=EAP-TLS
 374    and no data. This serves as a fragment ACK. The EAP peer MUST wait
 375    until it receives the EAP-Request before sending another fragment.
 376    In order to prevent errors in the processing of fragments, the EAP
 377    server MUST use increment the Identifier value for each fragment ACK
 378    contained within an EAP-Request, and the peer MUST include this
 379    Identifier value in the subsequent fragment contained within an EAP-
 380    Reponse.
 381
 382 3.4.  Identity verification
 383
 384    As part of the TLS negotiation, the server presents a certificate to
 385    the peer, and if mutual authentication is requested, the peer
 386    presents a certificate to the server.
 387
 388    Note that since the peer has made a claim of identity in the EAP-
 389    Response/Identity (MyID) packet, the EAP server SHOULD verify that
 390    the claimed identity corresponds to the certificate presented by the
 391
 392
 393
 394 Aboba & Simon                 Experimental                      [Page 7]
 395 \f
 396 RFC 2716          PPP EAP TLS Authentication Protocol       October 1999
 397
 398
 399    peer.  Typically this will be accomplished either by placing the
 400    userId within the peer certificate, or by providing a mapping between
 401    the peer certificate and the userId using a directory service.
 402
 403    Similarly, the peer MUST verify the validity of the EAP server
 404    certificate, and SHOULD also examine the EAP server name presented in
 405    the certificate, in order to determine whether the EAP server can be
 406    trusted. Please note that in the case where the EAP authentication is
 407    remoted that the EAP server will not reside on the same machine as
 408    the authenticator, and therefore the name in the EAP server's
 409    certificate cannot be expected to match that of the intended
 410    destination. In this case, a more appropriate test might be whether
 411    the EAP server's certificate is signed by a CA controlling the
 412    intended destination and whether the EAP server exists within a
 413    target sub-domain.
 414
 415 3.5.  Key derivation
 416
 417    Since the normal TLS keys are used in the handshake, and therefore
 418    should not be used in a different context, new encryption keys must
 419    be derived from the TLS master secret for use with PPP encryption.
 420    For both peer and EAP server, the derivation proceeds as follows:
 421    given the master secret negotiated by the TLS handshake, the
 422    pseudorandom function (PRF) defined in the specification for the
 423    version of TLS in use, and the value random defined as the
 424    concatenation of the handshake message fields client_hello.random and
 425    server_hello.random (in that order), the value PRF(master secret,
 426    "client EAP encryption", random) is computed up to 128 bytes, and the
 427    value PRF("", "client EAP encryption", random) is computed up to 64
 428    bytes (where "" is an empty string).  The peer encryption key (the
 429    one used for encrypting data from peer to EAP server) is obtained by
 430    truncating to the correct length the first 32 bytes of the first PRF
 431    of these two output strings.  TheEAP server encryption key (the one
 432    used for encrypting data from EAP server to peer), if different from
 433    the client encryption key, is obtained by truncating to the correct
 434    length the second 32 bytes of this same PRF output string.  The
 435    client authentication key (the one used for computing MACs for
 436    messages from peer to EAP server), if used, is obtained by truncating
 437    to the correct length the third 32 bytes of this same PRF output
 438    string.  The EAP server authentication key (the one used for
 439    computing MACs for messages from EAP server to peer), if used, and if
 440    different from the peer authentication key, is obtained by truncating
 441    to the correct length the fourth 32 bytes of this same PRF output
 442    string.  The peer initialization vector (IV), used for messages from
 443    peer to EAP server if a block cipher has been specified, is obtained
 444    by truncating to the cipher's block size the first 32 bytes of the
 445    second PRF output string mentioned above.  Finally, the server
 446    initialization vector (IV), used for messages from peer to EAP server
 447
 448
 449
 450 Aboba & Simon                 Experimental                      [Page 8]
 451 \f
 452 RFC 2716          PPP EAP TLS Authentication Protocol       October 1999
 453
 454
 455    if a block cipher has been specified, is obtained by truncating to
 456    the cipher's block size the second 32 bytes of this second PRF
 457    output.
 458
 459    The use of these encryption and authentication keys is specific to
 460    the PPP encryption mechanism used, such as those defined in [9] and
 461    [10].  Additional keys or other non-secret values (such as IVs) can
 462    be obtained as needed for future PPP encryption methods by extending
 463    the outputs of the PRF beyond 128 bytes and 64 bytes, respectively.
 464
 465 3.6.  ECP negotiation
 466
 467    Since TLS supports ciphersuite negotiation, peers completing the TLS
 468    negotiation will also have selected a ciphersuite, which includes key
 469    strength, encryption and hashing methods. As a result, a subsequent
 470    Encryption Control Protocol (ECP) conversation, if it occurs, has a
 471    predetermined result.
 472
 473    In order to ensure agreement between the EAP-TLS ciphersuite
 474    negotiation and the subsequent ECP negotiation (described in [6]),
 475    during ECP negotiation the PPP peer MUST offer only the ciphersuite
 476    negotiated inEAP-TLS.  This ensures that the PPP authenticator MUST
 477    accept the EAP-TLS negotiated ciphersuite in order for the
 478    onversation to proceed.  Should the authenticator not accept the
 479    EAP-TLS negotiated ciphersuite, then the peer MUST send an LCP
 480    terminate and disconnect.
 481
 482    Please note that it cannot be assumed that the PPP authenticator and
 483    EAP server are located on the same machine or that the authenticator
 484    understands the EAP-TLS conversation that has passed through it. Thus
 485    if the peer offers a ciphersuite other than the one negotiated in
 486    EAP-TLS there is no way for the authenticator to know how to respond
 487    correctly.
 488
 489 3.7.  CCP negotiation
 490
 491    TLS as described in [12] supports compression as well as ciphersuite
 492    negotiation. However, TLS only provides support for a limited number
 493    of compression types which do not overlap with the compression types
 494    used in PPP. As a result, during the EAP-TLS conversation the EAP
 495    endpoints MUST NOT request or negotiate compression. Instead, the PPP
 496    Compression Control Protocol (CCP), described in [13] should be used
 497    to negotiate the desired compression scheme.
 498
 499
 500
 501
 502
 503
 504
 505
 506 Aboba & Simon                 Experimental                      [Page 9]
 507 \f
 508 RFC 2716          PPP EAP TLS Authentication Protocol       October 1999
 509
 510
 511 3.8.  Examples
 512
 513    In the case where the EAP-TLS mutual authentication is successful,
 514    the conversation will appear as follows:
 515
 516    Authenticating Peer     Authenticator
 517    -------------------     -------------
 518                            <- PPP LCP Request-EAP
 519                            auth
 520    PPP LCP ACK-EAP
 521    auth ->
 522                            <- PPP EAP-Request/
 523                            Identity
 524    PPP EAP-Response/
 525    Identity (MyID) ->
 526                            <- PPP EAP-Request/
 527                            EAP-Type=EAP-TLS
 528                            (TLS Start)
 529    PPP EAP-Response/
 530    EAP-Type=EAP-TLS
 531    (TLS client_hello)->
 532                            <- PPP EAP-Request/
 533                            EAP-Type=EAP-TLS
 534                            (TLS server_hello,
 535                             TLS certificate,
 536                     [TLS server_key_exchange,]
 537                     [TLS certificate_request,]
 538                         TLS server_hello_done)
 539    PPP EAP-Response/
 540    EAP-Type=EAP-TLS
 541    (TLS certificate,
 542     TLS client_key_exchange,
 543    [TLS certificate_verify,]
 544     TLS change_cipher_spec,
 545     TLS finished) ->
 546                            <- PPP EAP-Request/
 547                            EAP-Type=EAP-TLS
 548                            (TLS change_cipher_spec,
 549                             TLS finished)
 550    PPP EAP-Response/
 551    EAP-Type=EAP-TLS ->
 552                            <- PPP EAP-Success
 553    PPP Authentication
 554    Phase complete,
 555    NCP Phase starts
 556
 557    ECP negotiation
 558    CCP negotiation
 559
 560
 561
 562 Aboba & Simon                 Experimental                     [Page 10]
 563 \f
 564 RFC 2716          PPP EAP TLS Authentication Protocol       October 1999
 565
 566
 567    In the case where the EAP-TLS mutual authentication is successful,
 568    and fragmentation is required, the conversation will appear as
 569    follows:
 570
 571    Authenticating Peer     Authenticator
 572    -------------------     -------------
 573                            <- PPP LCP Request-EAP
 574                            auth
 575    PPP LCP ACK-EAP
 576    auth ->
 577                            <- PPP EAP-Request/
 578                            Identity
 579    PPP EAP-Response/
 580    Identity (MyID) ->
 581                            <- PPP EAP-Request/
 582                            EAP-Type=EAP-TLS
 583                            (TLS Start, S bit set)
 584    PPP EAP-Response/
 585    EAP-Type=EAP-TLS
 586    (TLS client_hello)->
 587                            <- PPP EAP-Request/
 588                               EAP-Type=EAP-TLS
 589                              (TLS server_hello,
 590                                TLS certificate,
 591                      [TLS server_key_exchange,]
 592                      [TLS certificate_request,]
 593                          TLS server_hello_done)
 594                     (Fragment 1: L, M bits set)
 595    PPP EAP-Response/
 596    EAP-Type=EAP-TLS ->
 597                            <- PPP EAP-Request/
 598                               EAP-Type=EAP-TLS
 599                            (Fragment 2: M bit set)
 600    PPP EAP-Response/
 601    EAP-Type=EAP-TLS ->
 602                            <- PPP EAP-Request/
 603                            EAP-Type=EAP-TLS
 604                            (Fragment 3)
 605    PPP EAP-Response/
 606    EAP-Type=EAP-TLS
 607    (TLS certificate,
 608     TLS client_key_exchange,
 609    [TLS certificate_verify,]
 610     TLS change_cipher_spec,
 611     TLS inished)(Fragment 1:
 612     L, M bits set)->
 613                             <- PPP EAP-Request/
 614                            EAP-Type=EAP-TLS
 615
 616
 617
 618 Aboba & Simon                 Experimental                     [Page 11]
 619 \f
 620 RFC 2716          PPP EAP TLS Authentication Protocol       October 1999
 621
 622
 623    PPP EAP-Response/
 624    EAP-Type=EAP-TLS
 625    (Fragment 2)->
 626                           <- PPP EAP-Request/
 627                            EAP-Type=EAP-TLS
 628                            (TLS change_cipher_spec,
 629                             TLS finished)
 630    PPP EAP-Response/
 631    EAP-Type=EAP-TLS ->
 632                            <- PPP EAP-Success
 633    PPP Authentication
 634    Phase complete,
 635    NCP Phase starts
 636
 637    ECP negotiation
 638    CCP negotiation
 639
 640    In the case where the server authenticates to the client
 641    successfully, but the client fails to authenticate to the server, the
 642    conversation will appear as follows:
 643
 644    Authenticating Peer     Authenticator
 645    -------------------     -------------
 646                            <- PPP LCP Request-EAP
 647                            auth
 648    PPP LCP ACK-EAP
 649    auth ->
 650                            <- PPP EAP-Request/
 651                            Identity
 652    PPP EAP-Response/
 653    Identity (MyID) ->
 654                            <- PPP EAP-Request/
 655                            EAP-Type=EAP-TLS
 656                            (TLS Start)
 657    PPP EAP-Response/
 658    EAP-Type=EAP-TLS
 659    (TLS client_hello)->
 660                            <- PPP EAP-Request/
 661                            EAP-Type=EAP-TLS
 662                            (TLS server_hello,
 663                             TLS certificate,
 664                     [TLS server_key_exchange,]
 665                            TLS certificate_request,
 666                            TLS server_hello_done)
 667    PPP EAP-Response/
 668    EAP-Type=EAP-TLS
 669    (TLS certificate,
 670     TLS client_key_exchange,
 671
 672
 673
 674 Aboba & Simon                 Experimental                     [Page 12]
 675 \f
 676 RFC 2716          PPP EAP TLS Authentication Protocol       October 1999
 677
 678
 679     TLS certificate_verify,
 680     TLS change_cipher_spec,
 681     TLS finished) ->
 682                            <- PPP EAP-Request/
 683                            EAP-Type=EAP-TLS
 684                            (TLS change_cipher_spec,
 685                            TLS finished)
 686    PPP EAP-Response/
 687    EAP-Type=EAP-TLS ->
 688                            <- PPP EAP-Request
 689                            EAP-Type=EAP-TLS
 690                            (TLS Alert message)
 691    PPP EAP-Response/
 692    EAP-Type=EAP-TLS ->
 693                            <- PPP EAP-Failure
 694                            (User Disconnected)
 695
 696    In the case where server authentication is unsuccessful, the
 697    conversation will appear as follows:
 698
 699    Authenticating Peer     Authenticator
 700    -------------------     -------------
 701                            <- PPP LCP Request-EAP
 702                            auth
 703    PPP LCP ACK-EAP
 704    auth ->
 705                            <- PPP EAP-Request/
 706                            Identity
 707    PPP EAP-Response/
 708    Identity (MyID) ->
 709                            <- PPP EAP-Request/
 710                            EAP-Type=EAP-TLS
 711                            (TLS Start)
 712    PPP EAP-Response/
 713    EAP-Type=EAP-TLS
 714     (TLS client_hello)->
 715                            <- PPP EAP-Request/
 716                            EAP-Type=EAP-TLS
 717                            (TLS server_hello,
 718                             TLS certificate,
 719                        [TLS server_key_exchange,]
 720                        [TLS certificate_request,]
 721                         TLS server_hello_done)
 722    PPP EAP-Response/
 723    EAP-Type=EAP-TLS
 724     (TLS certificate,
 725     TLS client_key_exchange,
 726    [TLS certificate_verify,]
 727
 728
 729
 730 Aboba & Simon                 Experimental                     [Page 13]
 731 \f
 732 RFC 2716          PPP EAP TLS Authentication Protocol       October 1999
 733
 734
 735     TLS change_cipher_spec,
 736     TLS finished) ->
 737                            <- PPP EAP-Request/
 738                            EAP-Type=EAP-TLS
 739                            (TLS change_cipher_spec,
 740                             TLS finished)
 741    PPP EAP-Response/
 742    EAP-Type=EAP-TLS
 743    (TLS change_cipher_spec,
 744    TLS finished)
 745                            <- PPP EAP-Request/
 746                            EAP-Type=EAP-TLS
 747    PPP EAP-Response/
 748    EAP-Type=EAP-TLS
 749    (TLS Alert message) ->
 750                            <- PPP EAP-Failure
 751                            (User Disconnected)
 752
 753    In the case where a previously established session is being resumed,
 754    and both sides authenticate successfully, the conversation will
 755    appear as follows:
 756
 757    Authenticating Peer     Authenticator
 758    -------------------     -------------
 759                            <- PPP LCP Request-EAP
 760                            auth
 761    PPP LCP ACK-EAP
 762    auth ->
 763                            <- PPP EAP-Request/
 764                            Identity
 765    PPP EAP-Response/
 766    Identity (MyID) ->
 767                            <- PPP EAP-Request/
 768                            EAP-Request/
 769                            EAP-Type=EAP-TLS
 770                            (TLS Start)
 771    PPP EAP-Response/
 772    EAP-Type=EAP-TLS
 773    (TLS client_hello)->
 774                            <- PPP EAP-Request/
 775                            EAP-Type=EAP-TLS
 776                            (TLS server_hello,
 777                            TLS change_cipher_spec
 778                            TLS finished)
 779
 780
 781
 782
 783
 784
 785
 786 Aboba & Simon                 Experimental                     [Page 14]
 787 \f
 788 RFC 2716          PPP EAP TLS Authentication Protocol       October 1999
 789
 790
 791    PPP EAP-Response/
 792    EAP-Type=EAP-TLS
 793    (TLS change_cipher_spec,
 794     TLS finished) ->
 795                            <- PPP EAP-Success
 796    PPP Authentication
 797    Phase complete,
 798    NCP Phase starts
 799
 800    ECP negotiation
 801
 802    CCP negotiation
 803
 804    In the case where a previously established session is being resumed,
 805    and the server authenticates to the client successfully but the
 806    client fails to authenticate to the server, the conversation will
 807    appear as follows:
 808
 809    Authenticating Peer     Authenticator
 810    -------------------     -------------
 811                            <- PPP LCP Request-EAP
 812                            auth
 813    PPP LCP ACK-EAP
 814    auth ->
 815                            <- PPP EAP-Request/
 816                            Identity
 817    PPP EAP-Response/
 818    Identity (MyID) ->
 819                            <- PPP EAP-Request/
 820                            EAP-Request/
 821                            EAP-Type=EAP-TLS
 822                            (TLS Start)
 823    PPP EAP-Response/
 824    EAP-Type=EAP-TLS
 825    (TLS client_hello) ->
 826                            <- PPP EAP-Request/
 827                            EAP-Type=EAP-TLS
 828                            (TLS server_hello,
 829                             TLS change_cipher_spec,
 830                             TLS finished)
 831    PPP EA-Response/
 832    EAP-Type=EAP-TLS
 833    (TLS change_cipher_spec,
 834     TLS finished) ->
 835                            <- PPP EAP-Request
 836                            EAP-Type=EAP-TLS
 837                            (TLS Alert message)
 838
 839
 840
 841
 842 Aboba & Simon                 Experimental                     [Page 15]
 843 \f
 844 RFC 2716          PPP EAP TLS Authentication Protocol       October 1999
 845
 846
 847    PPP EAP-Response
 848    EAP-Type=EAP-TLS ->
 849                             <- PPP EAP-Failure
 850                             (User Disconnected)
 851
 852    In the case where a previously established session is being resumed,
 853    and the server authentication is unsuccessful, the conversation will
 854    appear as follows:
 855
 856    Authenticating Peer     Authenticator
 857    -------------------     -------------
 858                            <- PPP LCP Request-EAP
 859                            auth
 860    PPP LCP ACK-EAP
 861    auth ->
 862                            <- PPP EAP-Request/
 863                            Identity
 864    PPP EAP-Response/
 865    Identity (MyID) ->
 866                            <- PPP EAP-Request/
 867                            EAP-Request/
 868                            EAP-Type=EAP-TLS
 869                            (TLS Start)
 870    PPP EAP-Response/
 871    EAP-Type=EAP-TLS
 872    (TLS client_hello)->
 873                            <- PPP EAP-Request/
 874                            EAP-Type=EAP-TLS
 875                            (TLS server_hello,
 876                             TLS change_cipher_spec,
 877                             TLS finished)
 878    PPP EAP-Response/
 879    EAP-Type=EAP-TLS
 880    (TLS change_cipher_spec,
 881    TLS finished)
 882                            <- PPP EAP-Request/
 883                            EAP-Type=EAP-TLS
 884    PPP EAP-Response/
 885    EAP-Type=EAP-TLS
 886    (TLS Alert message) ->
 887                            <- PPP EAP-Failure
 888                            (User Disconnected)
 889
 890
 891
 892
 893
 894
 895
 896
 897
 898 Aboba & Simon                 Experimental                     [Page 16]
 899 \f
 900 RFC 2716          PPP EAP TLS Authentication Protocol       October 1999
 901
 902
 903 4.  Detailed description of the EAP-TLS protocol
 904
 905 4.1.  PPP EAP TLS Packet Format
 906
 907    A summary of the PPP EAP TLS Request/Response packet format is shown
 908    below.  The fields are transmitted from left to right.
 909
 910     0                   1                   2                   3
 911     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
 912    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 913    |     Code      |   Identifier  |            Length             |
 914    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 915    |     Type      |        Data...
 916    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 917
 918    Code
 919
 920       1 - Request
 921       2 - Response
 922
 923    Identifier
 924
 925       The identifier field is one octet and aids in matching responses
 926       with requests.
 927
 928    Length
 929
 930       The Length field is two octets and indicates the length of the EAP
 931       packet including the Code, Identifier, Length, Type, and Data
 932       fields.  Octets outside the range of the Length field should be
 933       treated as Data Link Layer padding and should be ignored on
 934       reception.
 935
 936    Type
 937
 938       13 - EAP TLS
 939
 940    Data
 941
 942       The format of the Data field is determined by the Code field.
 943
 944
 945
 946
 947
 948
 949
 950
 951
 952
 953
 954 Aboba & Simon                 Experimental                     [Page 17]
 955 \f
 956 RFC 2716          PPP EAP TLS Authentication Protocol       October 1999
 957
 958
 959 4.2.  PPP EAP TLS Request Packet
 960
 961    A summary of the PPP EAP TLS Request packet format is shown below.
 962    The fields are transmitted from left to right.
 963
 964    0                   1                   2                   3
 965    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
 966    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 967    |     Code      |   Identifier  |            Length             |
 968    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 969    |     Type      |     Flags     |      TLS Message Length
 970    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 971    |     TLS Message Length        |       TLS Data...
 972    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 973
 974    Code
 975
 976       1
 977
 978    Identifier
 979
 980       The Identifier field is one octet and aids in matching responses
 981       with requests.  The Identifier field MUST be changed on each
 982       Request packet.
 983
 984    Length
 985
 986       The Length field is two octets and indicates the length of the EAP
 987       packet including the Code, Identifier, Length, Type, and TLS
 988       Response fields.
 989
 990    Type
 991
 992       13 - EAP TLS
 993
 994    Flags
 995
 996       0 1 2 3 4 5 6 7 8
 997       +-+-+-+-+-+-+-+-+
 998       |L M S R R R R R|
 999       +-+-+-+-+-+-+-+-+
1000
1001       L = Length included
1002       M = More fragments
1003       S = EAP-TLS start
1004       R = Reserved
1005
1006
1007
1008
1009
1010 Aboba & Simon                 Experimental                     [Page 18]
1011 \f
1012 RFC 2716          PPP EAP TLS Authentication Protocol       October 1999
1013
1014
1015       The L bit (length included) is set to indicate the presence of the
1016       four octet TLS Message Length field, and MUST be set for the first
1017       fragment of a fragmented TLS message or set of messages. The M bit
1018       (more fragments) is set on all but the last fragment. The S bit
1019       (EAP-TLS start) is set in an EAP-TLS Start message. This
1020       differentiates the EAP-TLS Start message from a fragment
1021       acknowledgement.
1022
1023    TLS Message Length
1024
1025       The TLS Message Length field is four octets, and is present only
1026       if the L bit is set.  This field provides the total length of the
1027       TLS message or set of messages that is being fragmented.
1028
1029    TLS data
1030
1031       The TLS data consists of the encapsulated TLS packet in TLS record
1032       format.
1033
1034 4.3.  PPP EAP TLS Response Packet
1035
1036    A summary of the PPP EAP TLS Response packet format is shown below.
1037    The fields are transmitted from left to right.
1038
1039    0                   1                   2                   3
1040    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
1041    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1042    |     Code      |   Identifier  |            Length             |
1043    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1044    |     Type      |     Flags     |      TLS Message Length
1045    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1046    |     TLS Message Length        |       TLS Data...
1047    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1048
1049    Code
1050
1051       2
1052
1053    Identifier
1054
1055       The Identifier field is one octet and MUST match the Identifier
1056       field from the corresponding request.
1057
1058    Length
1059
1060       The Length field is two octets and indicates the length of the EAP
1061       packet including the Code, Identifir, Length, Type, and TLS data
1062       fields.
1063
1064
1065
1066 Aboba & Simon                 Experimental                     [Page 19]
1067 \f
1068 RFC 2716          PPP EAP TLS Authentication Protocol       October 1999
1069
1070
1071    Type
1072
1073       13 - EAP TLS
1074
1075    Flags
1076
1077       0 1 2 3 4 5 6 7 8
1078       +-+-+-+-+-+-+-+-+
1079       |L M S R R R R R|
1080       +-+-+-+-+-+-+-+-+
1081
1082       L = Length included
1083       M = More fragments
1084       S = EAP-TLS start
1085       R = Reserved
1086
1087       The L bit (length included) is set to indicate the presence of the
1088       four octet TLS Message Length field, and MUST be set for the first
1089       fragment of a fragmented TLS message or set of messages. The M bit
1090       (more fragments) is set on all but the last fragment. The S bit
1091       (EAP-TLS start) is set in an EAP-TLS Start message.  This
1092       differentiates the EAP-TLS Start message from a fragment
1093       acknowledgement.
1094
1095    TLS Message Length
1096
1097       The TLS Message Length field is four octets, and is present only
1098       if the L bit is set. This field provides the total length of the
1099       TLS message or set of messages that is being fragmented.
1100
1101    TLS data
1102
1103       The TLS data consists of the encapsulated TLS packet in TLS record
1104       format.
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122 Aboba & Simon                 Experimental                     [Page 20]
1123 \f
1124 RFC 2716          PPP EAP TLS Authentication Protocol       October 1999
1125
1126
1127 5.  References
1128
1129    [1]  Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
1130         51, RFC 1661, July 1994.
1131
1132    [2]  Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti,
1133         "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
1134
1135    [3]  Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January
1136         1994.
1137
1138    [4]  Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC
1139         1321, April 1992.
1140
1141    [5]  Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
1142         Protocol (EAP)", RFC 2284, March 1998.
1143
1144    [6]  Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June
1145         1996.
1146
1147    [7]  National Bureau of Standards, "Data Encryption Standard", FIPS
1148         PUB 46 (January 1977).
1149
1150    [8]  National Bureau of Standards, "DES Modes of Operation", FIPS PUB
1151         81 (December 1980).
1152
1153    [9]  Sklower, K. amd G. Meyer, "The PPP DES Encryption Protocol,
1154         Version 2 (DESE-bis)", RFC 2419, September 1998.
1155
1156    [10] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)",
1157         RFC 2420, September 1998.
1158
1159    [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement
1160         Levels", BCP 14, RFC 2119, March 1997.
1161
1162    [12] Dierks, T. and  C. Allen, "The TLS Protocol Version 1.0", RFC
1163         2246, November 1998.
1164
1165    [13] Rand, D., "The PPP Compression Control Protocol", RFC 1962, June
1166         1996.
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178 Aboba & Simon                 Experimental                     [Page 21]
1179 \f
1180 RFC 2716          PPP EAP TLS Authentication Protocol       October 1999
1181
1182
1183 6.  Security Considerations
1184
1185 6.1.  Certificate revocation
1186
1187    Since the EAP server is on the Internet during the EAP conversation,
1188    the server is capable of following a certificate chain or verifying
1189    whether the peer's certificate has been revoked. In contrast, the
1190    peer may or may not have Internet connectivity, and thus while it can
1191    validate the EAP server's certificate based on a pre-configured set
1192    of CAs, it may not be able to follow a certificate chain or verify
1193    whether the EAP server's certificate has been revoked.
1194
1195    In the case where the peer is initiating a voluntary Layer 2 tunnel
1196    using PPTP or L2TP, the peer will typically already have a PPP
1197    interface and Internet connectivity established at the time of tunnel
1198    initiation.  As a result, during the EAP conversation it is capable
1199    of checking for certificate revocation.
1200
1201    However, in the case where the peer is initiating an intial PPP
1202    conversation, it will not have Internet connectivity and is therefore
1203    not capable of checking for certificate revocation until after NCP
1204    negotiation completes and the peer has access to the Internet. In
1205    this case, the peer SHOULD check for certificate revocation after
1206    connecting to the Internet.
1207
1208 6.2.  Separation of the EAP server and PPP authenticator
1209
1210    As a result of the EAP-TLS conversation, the EAP endpoints will
1211    mutually authenticate, negotiate a ciphersuite, and derive a session
1212    key for subsequent use in PPP encryption. Since the peer and EAP
1213    client reside on the same machine, it is necessary for the EAP client
1214    module to pass the session key to the PPP encryption module.
1215
1216    The situation may be more complex on the PPP authenticator, which may
1217    or may not reside on the same machine as the EAP server. In the case
1218    where the EAP server and PPP authenticator reside on different
1219    machines, there are several implications for security. Firstly, the
1220    mutual authentication defined in EAP-TLS will occur between the peer
1221    and the EAP server, not between the peer and the authenticator. This
1222    means that as a result of the EAP-TLS conversation, it is not
1223    possible for the peer to validate the identity of the NAS or tunnel
1224    server that it is speaking to.
1225
1226    The second issue is that the session key negotiated between the peer
1227    and EAP server will need to be transmitted to the authenticator.
1228    Therefore a mechanism needs to be provided to transmit the session
1229    key from the EAP server to the authenticator or tunnel server that
1230    needs to use the key. The specification of this transit mechanism is
1231
1232
1233
1234 Aboba & Simon                 Experimental                     [Page 22]
1235 \f
1236 RFC 2716          PPP EAP TLS Authentication Protocol       October 1999
1237
1238
1239    outside the scope of this document.
1240
1241 6.3.  Relationship of PPP encryption to other security mechanisms
1242
1243    It is envisaged that EAP-TLS will be used primarily with dialup PPP
1244    connections. However, there are also circumstances in which PPP
1245    encryption may be used along with Layer 2 tunneling protocols such as
1246    PPTP and L2TP.
1247
1248    In compulsory layer 2 tunneling, a PPP peer makes a connection to a
1249    NAS or router which tunnels the PPP packets to a tunnel server.
1250    Since with compulsory tunneling a PPP peer cannot tell whether its
1251    packets are being tunneled, let alone whether the network device is
1252    securing the tunnel, if security is required then the client must
1253    make its own arrangements. In the case where all endpoints cannot be
1254    relied upon to implement IPSEC, TLS, or another suitable security
1255    protocol, PPP encryption provides a convenient means to ensure the
1256    privacy of packets transiting between the client and the tunnel
1257    server.
1258
1259 7.  Acknowledgments
1260
1261    Thanks to Terence Spies, Glen Zorn and Narendra Gidwani of Microsoft
1262    for useful discussions of this problem space.
1263
1264 8.  Authors' Addresses
1265
1266    Bernard Aboba
1267    Microsoft Corporation
1268    One Microsoft Way
1269    Redmond, WA 98052
1270
1271    Phone: 425-936-6605
1272    EMail: bernarda@microsoft.com
1273
1274
1275    Dan Simon
1276    Microsoft Corporation
1277    One Microsoft Way
1278    Redmond, WA 98052
1279
1280    Phone: 425-936-6711
1281    EMail: dansimon@microsoft.com
1282
1283
1284
1285
1286
1287
1288
1289
1290 Aboba & Simon                 Experimental                     [Page 23]
1291 \f
1292 RFC 2716          PPP EAP TLS Authentication Protocol       October 1999
1293
1294
1295 9.  Full Copyright Statement
1296
1297    Copyright (C) The Internet Society (1999).  All Rights Reserved.
1298
1299    This document and translations of it may be copied and furnished to
1300    others, and derivative works that comment on or otherwise explain it
1301    or assist in its implementation may be prepared, copied, published
1302    and distributed, in whole or in part, without restriction of any
1303    kind, provided that the above copyright notice and this paragraph are
1304    included on all such copies and derivative works.  However, this
1305    document itself may not be modified in any way, such as by removing
1306    the copyright notice or references to the Internet Society or other
1307    Internet organizations, except as needed for the purpose of
1308    developing Internet standards in which case the procedures for
1309    copyrights defined in the Internet Standards process must be
1310    followed, or as required to translate it into languages other than
1311    English.
1312
1313    The limited permissions granted above are perpetual and will not be
1314    revoked by the Internet Society or its successors or assigns.
1315
1316    This document and the information contained herein is provided on an
1317    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1318    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1319    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1320    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1321    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1322
1323 Acknowledgement
1324
1325    Funding for the RFC Editor function is currently provided by the
1326    Internet Society.
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346 Aboba & Simon                 Experimental                     [Page 24]
1347 \f