[要約] RFC 2716は、PPP EAP TLS認証プロトコルに関する仕様です。このプロトコルの目的は、PPP接続のセキュリティを向上させるために、EAPフレームワークを使用してTLS認証を提供することです。
Network Working Group B. Aboba
Requests for Commments: 2716 D. Simon
Category: Experimental Microsoft
October 1999
PPP EAP TLS Authentication Protocol
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol (LCP), which can be used to negotiate authentication methods, as well as an Encryption Control Protocol (ECP), used to negotiate data encryption over PPP links, and a Compression Control Protocol (CCP), used to negotiate compression methods. The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP.
ポイントツーポイントプロトコル（PPP）は、ポイントツーポイントリンク上でマルチプロトコルデータグラムを輸送するための標準的な方法を提供します。 PPPはまた、認証方法を交渉するために使用することができる拡張可能なリンク制御プロトコル（LCP）、ならびにPPPリンクを介してデータの暗号化を交渉するために使用される暗号化制御プロトコル（ECP）、および圧縮制御プロトコル（CCP）を定義します圧縮方法を交渉するために使用されます。拡張認証プロトコル（EAP）は、PPP内で追加の認証方法のサポートを提供PPP拡張です。
Transport Level Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation and key exchange between two endpoints. This document describes how EAP-TLS, which includes support for fragmentation and reassembly, provides for these TLS mechanisms within EAP.
トランスポートレベルセキュリティ（TLS）は、相互認証、完全性保護された暗号スイートネゴシエーションと2つのエンドポイント間の鍵交換を提供します。この文書では、断片化と再アセンブリのためのサポートを含むEAP-TLSは、EAP内のこれらのTLSメカニズムを提供する方法について説明します。
The Extensible Authentication Protocol (EAP), described in [5], provides a standard mechanism for support of additional authentication methods within PPP. Through the use of EAP, support for a number of authentication schemes may be added, including smart cards, Kerberos, Public Key, One Time Passwords, and others. To date however, EAP methods such as [6] have focussed on authenticating a client to a server.
[5]に記載の拡張認証プロトコル（EAP）は、PPP内で追加の認証方法をサポートするための標準的なメカニズムを提供します。 EAPを使用することにより、認証スキームの数に対するサポートは、スマートカード、ケルベロス、公開キー、ワンタイムパスワード、およびその他を含む、添加してもよいです。現在までしかし、そのような[6]などのEAPメソッドは、サーバーへのクライアントの認証に焦点を当ててきました。
However, it may be desirable to support mutual authentication, and since PPP encryption protocols such as [9] and [10] assume existence of a session key, it is useful to have a mechanism for session key establishment. Since design of secure key management protocols is non-trivial, it is desirable to avoid creating new mechanisms for this. The EAP protocol described in this document allows a PPP peer to take advantage of the protected ciphersuite negotiation, mutual authentication and key management capabilities of the TLS protocol, described in [12].
しかし、相互認証をサポートすることが望ましい場合、そのような[9]及び[10]のようなPPP暗号化プロトコルので、セッション鍵の存在を想定することができる、セッション鍵確立のための機構を有することが有用です。安全な鍵管理プロトコルの設計は、非自明であるので、このための新しいメカニズムを作成しないようにすることが望ましいです。この文書に記載されたEAPプロトコルは、PPPピアが[12]に記載の保護された暗号スイートネゴシエーション、相互認証及びTLSプロトコルの鍵管理機能の利点を取ることができます。
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [11].
この文書に記載されている、キーワード "MAY"、「MUST、 "MUST NOT"、 "オプション"、 "推奨"、 "SHOULD"、および "the" はならない、[11]に記載されているように解釈されるべきです。
As described in [5], the EAP-TLS conversation will typically begin with the authenticator and the peer negotiating EAP. The authenticator will then typically send an EAP-Request/Identity packet to the peer, and the peer will respond with an EAP-Response/Identity packet to the authenticator, containing the peer's userId.
[5]に記載されているように、EAP-TLSの会話は、典型的には、オーセンティケータとEAPを交渉ピアで始まります。オーセンティケータは、その後、典型的ピアにEAP要求/アイデンティティパケットを送信すると、ピアはピアのはuserIdを含む、オーセンティケータにEAP応答/アイデンティティパケットで応答します。
From this point forward, while nominally the EAP conversation occurs between the PPP authenticator and the peer, the authenticator MAY act as a passthrough device, with the EAP packets received from the peer being encapsulated for transmission to a RADIUS server or backend security server. In the discussion that follows, we will use the term "EAP server" to denote the ultimate endpoint conversing with the peer.
名目EAPの会話がPPP認証とピアとの間で発生しながら、オーセンティケータがピアから受信したEAPパケットを用いて、パススルーデバイスとして機能することができる、これ以降は、RADIUSサーバまたはバックエンドセキュリティサーバに送信するためにカプセル化されています。以下の議論では、我々は、ピアと会話究極のエンドポイントを示すために、用語「EAPサーバ」を使用します。
Once having received the peer's Identity, the EAP server MUST respond with an EAP-TLS/Start packet, which is an EAP-Request packet with EAP-Type=EAP-TLS, the Start (S) bit set, and no data. The EAP-TLS conversation will then begin, with the peer sending an EAP-Response packet with EAP-Type=EAP-TLS. The data field of that packet will encapsulate one or more TLS records in TLS record layer format, containing a TLS client_hello handshake message. The current cipher spec for the TLS records will be TLS_NULL_WITH_NULL_NULL and null compression. This current cipher spec remains the same until the change_cipher_spec message signals that subsequent records will have the negotiated attributes for the remainder of the handshake.
一旦ピアのIDを受信し、EAPタイプ= EAP-TLSとEAP-RequestパケットであるEAP-TLS /スタートパケットで応答しなければならないEAPサーバは、スタート（S）が設定されていない、とはデータビットです。 EAP-TLSの会話は、EAP-タイプ= EAP-TLSとEAP-Responseパケットを送信するピアと、開始されます。そのパケットのデータフィールドは、TLS CLIENT_HELLOハンドシェイク・メッセージを含む、TLSレコード層フォーマット内の1つまたは複数のTLSレコードをカプセル化します。 TLSレコードの現在の暗号仕様はTLS_NULL_WITH_NULL_NULLとヌル圧縮されます。この現在の暗号仕様は、後続のレコードが握手の残りのネゴシエート属性を持っていますchange_cipher_specメッセージ信号まで同じままです。
The client_hello message contains the client's TLS version number, a sessionId, a random number, and a set of ciphersuites supported by the client. The version offered by the client MUST correspond to TLS v1.0 or later.
CLIENT_HELLOメッセージは、クライアントのTLSのバージョン番号、セッションID、乱数、およびクライアントでサポートされている暗号スイートのセットが含まれています。クライアントによって提供されるバージョンは、TLS v1.0の以降に対応しなければなりません。
The EAP server will then respond with an EAP-Request packet with EAP-Type=EAP-TLS. The data field of this packet will encapsulate one or more TLS records. These will contain a TLS server_hello handshake message, possibly followed by TLS certificate, server_key_exchange, certificate_request, server_hello_done and/or finished handshake messages, and/or a TLS change_cipher_spec message. The server_hello handshake message contains a TLS version number, another random number, a sessionId, and a ciphersuite. The version offered by the server MUST correspond to TLS v1.0 or later.
EAPサーバは、EAP-タイプ= EAP-TLSとEAP-Requestパケットで応答します。このパケットのデータフィールドは、一つ以上のTLSレコードをカプセル化します。これらは、おそらくTLS証明書、server_key_exchange、証明書要求、server_hello_doneおよび/または仕上げハンドシェイクメッセージ、および/またはTLSのchange_cipher_specメッセージに続いてTLS server_helloハンドシェイクメッセージを、含まれています。 server_helloハンドシェイクメッセージは、TLSのバージョン番号、別の乱数、セッションID、および暗号スイートが含まれています。サーバによって提供されるバージョンは、TLS v1.0を以降に対応しなければなりません。
If the client's sessionId is null or unrecognized by the server, the server MUST choose the sessionId to establish a new session; otherwise, the sessionId will match that offered by the client, indicating a resumption of the previously established session with that sessionID. The server will also choose a ciphersuite from those offered by the client; if the session matches the client's, then the ciphersuite MUST match the one negotiated during the handshake protocol execution that established the session.
クライアントのセッションIDがサーバーによってnullまたは認識されない場合は、サーバーは新しいセッションを確立するためのセッションIDを選択する必要があります。そうでない場合、セッションIDは、そのセッションIDと以前に確立されたセッションの再開を指示する、クライアントによって提供されるものと一致します。また、サーバは、クライアントによって提供されるものから暗号スイートを選択します。セッションは、クライアントのと一致した場合、暗号スイートは、セッションを確立し、ハンドシェイクプロトコル実行中に交渉されたものと一致しなければなりません。
The purpose of the sessionId within the TLS protocol is to allow for improved efficiency in the case where a client repeatedly attempts to authenticate to an EAP server within a short period of time. While this model was developed for use with HTTP authentication, it may also have application to PPP authentication (e.g. multilink).
TLSプロトコル内でセッションIDの目的は、クライアントが繰り返し時間の短い期間内にEAPサーバに対して認証しようとした場合に改善された効率を可能にすることです。このモデルは、HTTP認証で使用するために開発されたが、それはまた、PPP認証（例えば、マルチリンク）への適用を有することができます。
As a result, it is left up to the peer whether to attempt to continue a previous session, thus shortening the TLS conversation. Typically the peer's decision will be made based on the time elapsed since the previous authentication attempt to that EAP server. Based on the sessionId chosen by the peer, and the time elapsed since the previous authentication, the EAP server will decide whether to allow the continuation, or whether to choose a new session.
その結果、このようにTLSの会話を短くし、前のセッションを継続しようとするかどうかを相手に任されています。通常、ピアの決定は、そのEAPサーバへの以前の認証の試行からの経過時間に基づいて行われます。ピアによって選ばれたセッションID、および以前の認証からの経過時間に基づいて、EAPサーバは、継続を許可するかどうか、または新しいセッションを選択するかどうかを決定します。
In the case where the EAP server and authenticator reside on the same device, then client will only be able to continue sessions when connecting to the same NAS or tunnel server. Should these devices be set up in a rotary or round-robin then it may not be possible for the peer to know in advance the authenticator it will be connecting to, and therefore which sessionId to attempt to reuse. As a result, it is likely that the continuation attempt will fail. In the case where the EAP authentication is remoted then continuation is much more likely to be successful, since multiple NAS devices and tunnel servers will remote their EAP authentications to the same RADIUS server.
EAPサーバとオーセンティケータが同じデバイス上に存在する場合には、クライアントは、同じNASまたはトンネルサーバーに接続するときにセッションを継続することができるであろう。ピアは、事前に再利用しようとするセッションIDそれ故への接続とされるオーセンティケータを知っているため、これらのデバイスは、回転またはラウンドロビンに設定する必要があり、それが可能ではないかもしれません。その結果、継続の試みが失敗する可能性があります。 EAP認証は、その後、リモーティングされた場合には継続が複数のNASデバイスとトンネルサーバいるので、成功するはるかに可能性があります、同じRADIUSサーバへのリモート彼らのEAP認証。
If the EAP server is resuming a previously established session, then it MUST include only a TLS change_cipher_spec message and a TLS finished handshake message after the server_hello message. The finished message contains the EAP server's authentication response to the peer. If the EAP server is not resuming a previously established session, then it MUST include a TLS server_certificate handshake message, and a server_hello_done handshake message MUST be the last handshake message encapsulated in this EAP-Request packet.
EAPサーバは、以前に確立されたセッションを再開した場合、それが唯一のTLS change_cipher_specメッセージやTLSを含まなければならないserver_helloメッセージの後に握手メッセージを終えました。完成したメッセージは、ピアへのEAPサーバの認証応答が含まれています。 EAPサーバは、以前に確立したセッションを再開していない場合、それはTLS server_certificateハンドシェイクメッセージを含まなければならない、とserver_hello_doneハンドシェイクメッセージは、このEAP-Requestパケットにカプセル化され、最後の握手メッセージでなければなりません。
The certificate message contains a public key certificate chain for either a key exchange public key (such as an RSA or Diffie-Hellman key exchange public key) or a signature public key (such as an RSA or DSS signature public key). In the latter case, a TLS server_key_exchange handshake message MUST also be included to allow the key exchange to take place.
証明書メッセージが（例えばRSAまたはディフィー・ヘルマン鍵共有公開鍵として）鍵交換公開鍵または（例えばRSAまたはDSS署名公開鍵など）署名公開鍵のいずれかの公開鍵証明書チェーンを含んでいます。後者の場合には、TLS server_key_exchangeハンドシェイクメッセージは、鍵交換が行われることを可能にするために含まれなければなりません。
The certificate_request message is included when the server desires the client to authenticate itself via public key. While the EAP server SHOULD require client authentication, this is not a requirement, since it may be possible that the server will require that the peer authenticate via some other means.
サーバは、公開鍵を経由して自身を認証するようにクライアントを希望する場合証明書要求メッセージが含まれています。 EAPサーバがクライアント認証を要求する必要がありますが、サーバがピアが他のいくつかの手段を介して認証を行うことを要求することが可能かもしれないので、これは、必須ではありません。
The peer MUST respond to the EAP-Request with an EAP-Response packet of EAP-Type=EAP-TLS. The data field of this packet will encapsulate one or more TLS records containing a TLS change_cipher_spec message and finished handshake message, and possibly certificate, certificate_verify and/or client_key_exchange handshake messages. If the preceding server_hello message sent by the EAP server in the preceding EAP-Request packet indicated the resumption of a previous session, then the peer MUST send only the change_cipher_spec and finished handshake messages. The finished message contains the peer's authentication response to the EAP server.
ピアは、EAP-タイプ= EAP-TLSのEAP-ResponseパケットでEAP-要求に応答しなければなりません。このパケットのデータフィールドには、場合によっては1つまたは複数のTLS change_cipher_specメッセージを含むTLSレコードと終了ハンドシェイクメッセージ、および証明書、certificate_verifyおよび/またはclient_key_exchangeハンドシェイクメッセージをカプセル化します。先行EAP-RequestパケットにEAPサーバによって送信された先行server_helloメッセージは、前のセッションの再開を示した場合、ピアは、change_cipher_specと終了ハンドシェイクメッセージを送らなければなりません。完成したメッセージは、EAPサーバへのピアの認証応答が含まれています。
If the preceding server_hello message sent by the EAP server in the preceeding EAP-Request packet did not indicate the resumption of a previous session, then the peer MUST send, in addition to the change_cipher_spec and finished messages, a client_key_exchange message, which completes the exchange of a shared master secret between the peer and the EAP server. If the EAP server sent a certificate_request message in the preceding EAP-Request packet, then the peer MUST send, in addition, certificate and certificate_verify handshake messages. The former contains a certificate for the peer's signature public key, while the latter contains the peer's signed authentication response to the EAP server. After receiving this packet, the EAP server will verify the peer's certificate and digital signature, if requested.
先行EAP-RequestパケットにEAPサーバによって送信される前のserver_helloメッセージは、前のセッションの再開を指示しなかった場合、ピアは、change_cipher_spec完成したメッセージに加えて、交換を完了client_key_exchangeメッセージを送信しなければなりませんピアとEAPサーバ間の共有マスタシークレットの。 EAPサーバは先行EAP-Requestパケットに証明書要求メッセージを送信した場合、ピアはまた、証明書とcertificate_verifyハンドシェークメッセージで送らなければなりません。後者は、EAPサーバにピアの署名された認証応答を含むが、前者は、ピアの署名公開鍵の証明書を含みます。要求された場合は、このパケットを受信した後、EAPサーバは、ピアの証明書とデジタル署名を検証します。
If the peer's authentication is unsuccessful, the EAP server SHOULD send an EAP-Request packet with EAP-Type=EAP-TLS, encapsulating a TLS record containing the appropriate TLS alert message. The EAP server SHOULD send a TLS alert message rather immediately terminating the conversation so as to allow the peer to inform the user of the cause of the failure and possibly allow for a restart of the conversation.
ピアの認証に失敗した場合は、EAPサーバは、適切なTLS警告メッセージを含むTLSレコードをカプセル化し、EAP-タイプ= EAP-TLSとEAP-Requestパケットを送るべきです。ピアは、障害の原因をユーザに通知し、おそらく会話の再起動を可能にすることを可能にするようにEAPサーバではなく、すぐに会話を終了するTLS警告メッセージを送信する必要があります。
To ensure that the peer receives the TLS alert message, the EAP server MUST wait for the peer to reply with an EAP-Response packet. The EAP-Response packet sent by the peer MAY encapsulate a TLS client_hello handshake message, in which case the EAP server MAY allow the EAP-TLS conversation to be restarted, or it MAY contain an EAP-Response packet with EAP-Type=EAP-TLS and no data, in which case the EAP-Server MUST send an EAP-Failure packet, and terminate the conversation. It is up to the EAP server whether to allow restarts, and if so, how many times the conversation can be restarted. An EAP Server implementing restart capability SHOULD impose a limit on the number of restarts, so as to protect against denial of service attacks.
ピアがTLS警告メッセージを受け取ることを保証するために、EAPサーバは、EAP-Responseパケットで応答するピアのを待たなければなりません。 EAPサーバがEAP-TLS会話を可能にすることができる場合には、ハンドシェイクメッセージをCLIENT_HELLO TLSをカプセル化することができるピアによって送信されたEAP-Responseパケットは、再起動する、またはそれがEAP-タイプのEAP-Responseパケットを含むかもしれ= EAP- TLSとEAP-Serverは、EAP-失敗パケットを送信し、会話を終えなければなりません。その場合にはデータがありません、。これは、再起動を許可するかどうかEAPサーバに任されて、そうであれば、何回の会話を再開することができます。サービス拒否攻撃から保護するために再起動機能を実装するEAP Serverは、再起動の回数に制限を課すべきです。
If the peers authenticates successfully, the EAP server MUST respond with an EAP-Request packet with EAP-Type=EAP-TLS, which includes, in the case of a new TLS session, one or more TLS records containing TLS change_cipher_spec and finished handshke messages. The latter contains the EAP server's authentication response to the peer. The peer will then verify the hash in order to authenticate the EAP server.
ピアの認証が成功した場合、EAPサーバは、新しいTLSセッション、TLSのchange_cipher_specを含む1つ以上のTLSレコードの場合には、含まれるEAP-タイプ= EAP-TLSとEAP-Requestパケットで応答し、メッセージをhandshke終えなければなりません。 。後者は、ピアへのEAPサーバの認証応答が含まれています。ピアは、EAPサーバを認証するためにハッシュを確認します。
If the EAP server authenticates unsuccessfully, the peer MAY send an EAP-Response packet of EAP-Type=EAP-TLS containing a TLS Alert message identifying the reason for the failed authentication. The peer MAY send a TLS alert message rather than immediately terminating the conversation so as to allow the EAP server to log the cause of the error for examination by the system administrator.
EAPサーバが認証に失敗した場合、ピアは、認証失敗の理由を特定するTLS警告メッセージを含むEAP-タイプ= EAP-TLSのEAP-Responseパケットを送信することができます。ピアは、EAPサーバは、システム管理者が検査のために、エラーの原因をログに記録することを可能にするように、すぐに会話を終了するのではなく、TLS警告メッセージを送信することができます。
To ensure that the EAP Server receives the TLS alert message, the peer MUST wait for the EAP-Server to reply before terminating the conversation. The EAP Server MUST reply with an EAP-Failure packet since server authentication failure is a terminal condition.
EAPサーバがTLSの警告メッセージを受け取ることを保証するために、ピアは、会話を終了する前に返信するEAP-Serverのを待つ必要があります。サーバー認証の失敗は、端末の状態であるので、EAPサーバは、EAP-Failureパケットで応答しなければなりません。
If the EAP server authenticates successfully, the peer MUST send an EAP-Response packet of EAP-Type=EAP-TLS, and no data. The EAP-Server then MUST respond with an EAP-Success message.
EAPサーバが認証に成功した場合、ピアは、EAP-タイプ= EAP-TLSのEAP-Responseパケット、及びデータなしを送らなければなりません。 EAP-Serverは、EAP-Successメッセージで応じなければなりません。
As with other EAP protocols, the EAP server is responsible for retry behavior. This means that if the EAP server does not receive a reply from the peer, it MUST resend the EAP-Request for which it has not yet received an EAP-Response. However, the peer MUST NOT resend EAP-Response packets without first being prompted by the EAP server.
他のEAPプロトコルと同様に、EAPサーバは再試行動作を担当しています。これは、EAPサーバがピアから応答を受信しない場合、それはまだEAP-レスポンスを受信していないいるEAP-Requestを再送しなければならないことを意味します。しかし、ピアは、最初のEAPサーバによって要求されることなく、EAP-応答パケットを再送してはなりません。
For example, if the initial EAP-TLS start packet sent by the EAP server were to be lost, then the peer would not receive this packet, and would not respond to it. As a result, the EAP-TLS start packet would be resent by the EAP server. Once the peer received the EAP-TLS start packet, it would send an EAP-Response encapsulating the client_hello message. If the EAP-Response were to be lost, then the EAP server would resend the initial EAP-TLS start, and the peer would resend the EAP-Response.
最初のEAP-TLSが失われたEAPサーバによって送信されたパケットを開始した場合、その後、ピアはこのパケットを受信しないだろうし、それに応答しないでしょう。その結果、EAP-TLSスタートパケットは、EAPサーバによって再送されるだろう。ピアは、EAP-TLS開始パケットを受信したら、それはCLIENT_HELLOメッセージをカプセル化するEAP-応答を送信します。 EAP-Responseが失われた場合には、EAPサーバは、最初のEAP-TLSの開始を再送だろう、とピアは、EAP-レスポンスを再送します。
As a result, it is possible that a peer will receive duplicate EAP-Request messages, and may send duplicate EAP-Responses. Both the peer and the EAP-Server should be engineered to handle this possibility.
その結果、ピアが重複したEAP-Requestメッセージを受信すると、重複したEAP-応答を送信することが可能です。ピアとEAP-サーバーの両方が、この可能性に対処するように設計されなければなりません。
A single TLS record may be up to 16384 octets in length, but a TLS message may span multiple TLS records, and a TLS certificate message may in principle be as long as 16MB. The group of EAP-TLS messages sent in a single round may thus be larger than the PPP MTU size, the maximum RADIUS packet size of 4096 octets, or even the Multilink Maximum Received Reconstructed Unit (MRRU). As described in [2], the multilink MRRU is negotiated via the Multilink MRRU LCP option, which includes an MRRU length field of two octets, and thus can support MRRUs as large as 64 KB.
単一TLSレコードの長さは、最大16384オクテットかもしれないが、TLSメッセージは、複数のTLSレコードにまたがること、およびTLS証明書メッセージは、原則的に16メガバイトほどの長さであってもよいです。単一ラウンドで送信されるEAP-TLSメッセージのグループは、このようPPP MTUサイズよりも大きくてもよい、4096オクテットの最大RADIUSパケットサイズ、あるいはマルチ最大は、再構成ユニット（MRRU）を受けました。記載のように、[2]、マルチMRRUは、2つのオクテットのMRRU長フィールドを含むマルチMRRU LCPオプションを介して交渉され、したがって、64キロバイトのような大きなとしてMRRUsをサポートすることができます。
However, note that in order to protect against reassembly lockup and denial of service attacks, it may be desirable for an implementation to set a maximum size for one such group of TLS messages. Since a typical certificate chain is rarely longer than a few thousand octets, and no other field is likely to be anwhere near as long, a reasonable choice of maximum acceptable message length might be 64 KB.
しかし、実装がTLSメッセージのような一グループの最大サイズを設定するための再組み立てロックやサービス拒否攻撃から保護するために、それは望ましいかもしれないことに注意してください。典型的な証明書チェーンはめったに長い数千オクテットよりでなく、他のフィールドがanwhere限り近くになりそうではありませんので、最大許容メッセージ長の合理的な選択は、64キロバイトかもしれません。
If this value is chosen, then fragmentation can be handled via the multilink PPP fragmentation mechanisms described in [2]. While this is desirable, there may be cases in which multilink or the MRRU LCP option cannot be negotiated. As a result, an EAP-TLS implementation MUST provide its own support for fragmentation and reassembly.
この値が選択される場合、フラグメンテーションは、[2]に記載のマルチリンクPPPフラグメンテーションメカニズムを介して処理することができます。これは望ましいが、マルチリンクまたはMRRU LCPオプションが交渉することができない場合があります。その結果、EAP-TLSの実装では、断片化と再アセンブリのための独自のサポートを提供しなければなりません。
Since EAP is a simple ACK-NAK protocol, fragmentation support can be added in a simple manner. In EAP, fragments that are lost or damaged in transit will be retransmitted, and since sequencing information is provided by the Identifier field in EAP, there is no need for a fragment offset field as is provided in IPv4.
EAPは、単純なACK-NAKプロトコルであるため、フラグメンテーションサポートを簡単に追加することができます。 EAPには、輸送中に紛失または破損しているフラグメントが再送され、情報がEAP内の識別子フィールドによって提供される配列決定するため、IPv4の提供されたようにフラグメントオフセットフィールドは不要です。
EAP-TLS fragmentation support is provided through addition of a flags octet within the EAP-Response and EAP-Request packets, as well as a TLS Message Length field of four octets. Flags include the Length included (L), More fragments (M), and EAP-TLS Start (S) bits. The L flag 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 flag is set on all but the last fragment. The S flag is set only within the EAP-TLS start message sent from the EAP server to the peer. The TLS Message Length field is four octets, and provides the total length of the TLS message or set of messages that is being fragmented; this simplifies buffer allocation.
EAP-TLSの断片化のサポートはEAP応答およびEAP-Requestパケット内のフラグオクテット、並びに4つのオクテットのTLSメッセージ長フィールドの添加を介して提供されます。フラグが（L）を含む長さ、複数のフラグメント（M）、及びEAP-TLSスタート（S）ビットを含みます。 Lフラグは、4つのオクテットTLSメッセージ長フィールドの存在を示すために設定され、断片化されたTLSメッセージ又はメッセージのセットの最初の断片に設定しなければなりません。 Mフラグが最後のフラグメント以外のすべてに設定されています。 SフラグのみピアにEAPサーバから送信されたEAP-TLS開始メッセージ内に設定されています。 TLSメッセージ長フィールドは、4つのオクテットであり、TLSメッセージまたは断片化されるメッセージのセットの全体の長さを提供します。これは、バッファ割り当てを簡素化します。
When an EAP-TLS peer receives an EAP-Request packet with the M bit set, it MUST respond with an EAP-Response with EAP-Type=EAP-TLS and no data. This serves as a fragment ACK. The EAP server MUST wait until it receives the EAP-Response before sending another fragment. In order to prevent errors in processing of fragments, the EAP server MUST increment the Identifier field for each fragment contained within an EAP-Request, and the peer MUST include this Identifier value in the fragment ACK contained within the EAP-Reponse. Retransmitted fragments will contain the same Identifier value.
EAP-TLSのピアがMビットが設定されたEAP-Requestパケットを受信すると、EAPタイプ= EAP-TLSおよびデータのないEAP-応答で応答しなければなりません。これは、断片ACKとして機能します。それは別のフラグメントを送る前に、EAP-応答を受信するまで、EAPサーバは待たなければなりません。フラグメントの処理のエラーを防止するために、EAPサーバはEAP-要求内に含まれる各フラグメントの識別子フィールドをインクリメントしなければならない、とピアはEAP-REPONSE内に含まれる断片のACKにおけるこの識別子の値を含まなければなりません。再送されたフラグメントは、同じ識別子の値が含まれます。
Similarly, when the EAP server receives an EAP-Response with the M bit set, it MUST respond with an EAP-Request with EAP-Type=EAP-TLS and no data. This serves as a fragment ACK. The EAP peer MUST wait until it receives the EAP-Request before sending another fragment. In order to prevent errors in the processing of fragments, the EAP server MUST use increment the Identifier value for each fragment ACK contained within an EAP-Request, and the peer MUST include this Identifier value in the subsequent fragment contained within an EAP-Reponse.
EAPサーバはMビットセットでEAP-応答を受信すると同様に、それはEAPタイプ= EAP-TLSおよびデータのないEAP-要求に応じなければなりません。これは、断片ACKとして機能します。それは別のフラグメントを送る前に、EAP-Requestを受信するまで、EAPピアは待たなければなりません。フラグメントの処理のエラーを防止するために、EAPサーバはEAP-要求内に含まれる各断片ACKのための識別子の値をインクリメント使用しなければなりません、そしてピアはEAP-REPONSE内に含まれる後続の断片におけるこの識別子の値を含まなければなりません。
As part of the TLS negotiation, the server presents a certificate to the peer, and if mutual authentication is requested, the peer presents a certificate to the server.
TLSネゴシエーションの一部として、サーバーは、ピアに証明書を提示し、相互認証が要求された場合、ピアはサーバに証明書を提示します。
Note that since the peer has made a claim of identity in the EAP-Response/Identity (MyID) packet, the EAP server SHOULD verify that the claimed identity corresponds to the certificate presented by the peer. Typically this will be accomplished either by placing the userId within the peer certificate, or by providing a mapping between the peer certificate and the userId using a directory service.
ピアはEAP応答/アイデンティティ（のMyID）パケットに同一の請求を行っているため、EAPサーバは要求されたアイデンティティがピアによって提示された証明書に対応することを確認すべきであることに留意されたいです。典型的には、これは、ピア証明書内にuserIdを配置することによって、またはディレクトリサービスを使用して、ピア証明書、そのユーザーIDの間のマッピングを提供することによってのいずれかで達成されます。
Similarly, the peer MUST verify the validity of the EAP server certificate, and SHOULD also examine the EAP server name presented in the certificate, in order to determine whether the EAP server can be trusted. Please note that in the case where the EAP authentication is remoted that the EAP server will not reside on the same machine as the authenticator, and therefore the name in the EAP server's certificate cannot be expected to match that of the intended destination. In this case, a more appropriate test might be whether the EAP server's certificate is signed by a CA controlling the intended destination and whether the EAP server exists within a target sub-domain.
同様に、ピアはEAPサーバ証明書の有効性を検証しなければならない、また、EAPサーバが信頼できるかどうかを決定するために、証明書に提示EAPサーバ名を調べる必要があります。 EAP認証がEAPサーバがオーセンティケータと同じマシン上に存在しませんので、EAPサーバの証明書の名前が意図した宛先と一致することが期待できないことをリモーティングされた場合にはご注意ください。この場合には、より適切なテストは、EAPサーバの証明書が意図された宛先を制御するCAによって、およびEAPサーバがターゲットサブドメイン内に存在するか否かを署名されているかどうかであるかもしれません。
Since the normal TLS keys are used in the handshake, and therefore should not be used in a different context, new encryption keys must be derived from the TLS master secret for use with PPP encryption. For both peer and EAP server, the derivation proceeds as follows: given the master secret negotiated by the TLS handshake, the pseudorandom function (PRF) defined in the specification for the version of TLS in use, and the value random defined as the concatenation of the handshake message fields client_hello.random and server_hello.random (in that order), the value PRF(master secret, "client EAP encryption", random) is computed up to 128 bytes, and the value PRF("", "client EAP encryption", random) is computed up to 64 bytes (where "" is an empty string). The peer encryption key (the one used for encrypting data from peer to EAP server) is obtained by truncating to the correct length the first 32 bytes of the first PRF of these two output strings. TheEAP server encryption key (the one used for encrypting data from EAP server to peer), if different from the client encryption key, is obtained by truncating to the correct length the second 32 bytes of this same PRF output string. The client authentication key (the one used for computing MACs for messages from peer to EAP server), if used, is obtained by truncating to the correct length the third 32 bytes of this same PRF output string. The EAP server authentication key (the one used for computing MACs for messages from EAP server to peer), if used, and if different from the peer authentication key, is obtained by truncating to the correct length the fourth 32 bytes of this same PRF output string. The peer initialization vector (IV), used for messages from peer to EAP server if a block cipher has been specified, is obtained by truncating to the cipher's block size the first 32 bytes of the second PRF output string mentioned above. Finally, the server initialization vector (IV), used for messages from peer to EAP server if a block cipher has been specified, is obtained by truncating to the cipher's block size the second 32 bytes of this second PRF output.
通常のTLSキーはハンドシェイクで使用されているため、異なるコンテキストで使用すべきではありませんので、新しい暗号化キーは、PPPの暗号化で使用するためのTLSマスターシークレットから派生しなければなりません。次のように、ピアとEAPサーバの両方のために、派生進む：TLSハンドシェイクによって交渉マスターシークレットを与え、使用中のTLSのバージョンの仕様で定義された擬似ランダム関数（PRF）、及びランダム値の連結として定義されハンドシェイクメッセージは「「クライアントEAPをclient_hello.randomとserver_hello.random（そのために）、値PRF（マスタシークレット、「クライアントEAP暗号化」、ランダム）128のバイトまで計算され、値PRFを（」フィールド暗号化 『空の文字列である）」、ランダム）が64バイト（どこまで計算されます』。ピア暗号鍵（EAPサーバにピアからデータを暗号化するために使用されるもの）は、適切な長さに、これら二つの出力列の最初のPRFの最初の32のバイトを切り捨てることにより得られます。 TheEAPサーバー暗号化キー（ピア・ツーEAPサーバからのデータを暗号化するために使用されるもの）、クライアントの暗号化キーと異なる場合、正しい長さにこの同じPRF出力列の第32バイトを切り捨てることにより得られます。クライアント認証キー（EAPサーバにピアからのメッセージのMACを計算するために使用されるもの）、使用される場合、正しい長さにこの同じPRF出力列の第三の32のバイトを切り捨てることにより得られます。 EAPサーバ認証キー（ピア・ツーEAPサーバからのメッセージのMACを計算するために使用されるもの）、使用される場合、ピア認証キーと異なる場合、正しい長さにこの同じPRF出力の第32バイトを切り捨てることにより得られます文字列。ブロック暗号が指定されている場合、EAPサーバにピアからのメッセージに使用されるピア初期化ベクトル（IV）は、暗号のブロックサイズと上記第二PRF出力列の最初の32のバイトを切り捨てることにより得られます。最後に、ブロック暗号が指定されている場合、EAPサーバにピアからのメッセージに使用サーバー初期化ベクトル（IV）は、暗号のブロックサイズに、この第二PRF出力の第32バイトを切り捨てることにより得られます。
The use of these encryption and authentication keys is specific to the PPP encryption mechanism used, such as those defined in [9] and [10]. Additional keys or other non-secret values (such as IVs) can be obtained as needed for future PPP encryption methods by extending the outputs of the PRF beyond 128 bytes and 64 bytes, respectively.
これらの暗号化および認証鍵の使用は、[9]及び[10]で定義されたものとして、使用されるPPPの暗号化メカニズムに特異的です。それぞれ、128バイト、64のバイトを超えPRFの出力を拡張することによって、将来のPPP暗号化方法のために必要に応じて追加のキーまたは（例えばのIVのような）他の非秘密の値を得ることができます。
Since TLS supports ciphersuite negotiation, peers completing the TLS negotiation will also have selected a ciphersuite, which includes key strength, encryption and hashing methods. As a result, a subsequent Encryption Control Protocol (ECP) conversation, if it occurs, has a predetermined result.
TLSは、暗号スイートネゴシエーションをサポートしているため、TLSネゴシエーションを完了したピアはまた、キーの強度、暗号化とハッシュ方式を含んで暗号スイートを選択しています。その結果、後続の暗号化制御プロトコル（ECP）会話は、それが発生した場合、所定の結果を有しています。
In order to ensure agreement between the EAP-TLS ciphersuite negotiation and the subsequent ECP negotiation (described in [6]), during ECP negotiation the PPP peer MUST offer only the ciphersuite negotiated inEAP-TLS. This ensures that the PPP authenticator MUST accept the EAP-TLS negotiated ciphersuite in order for the onversation to proceed. Should the authenticator not accept the EAP-TLS negotiated ciphersuite, then the peer MUST send an LCP terminate and disconnect.
EAP-TLSの暗号スイートネゴシエーションとECPネゴシエーション中PPPピアがinEAP-TLSネゴシエートのみ暗号スイートを提供しなければならない（[6]に記載の）後続のECPネゴシエーション、の間の契約を確保するために。これは、PPP認証は、EAP-TLSはonversationを続行するために暗号スイートを交渉し受け入れなければならないことを保証します。オーセンティケータがEAP-TLSは、暗号スイートを交渉し受け入れるべきではない、その後、ピアが終了し、接続を切断LCPを送らなければなりません。
Please note that it cannot be assumed that the PPP authenticator and EAP server are located on the same machine or that the authenticator understands the EAP-TLS conversation that has passed through it. Thus if the peer offers a ciphersuite other than the one negotiated in EAP-TLS there is no way for the authenticator to know how to respond correctly.
PPP認証とEAPサーバが同じマシン上またはオーセンティケータは、それを通過したEAP-TLSの会話を理解していることにあることを想定することはできませんのでご注意ください。ピアは、EAP-TLSで交渉以外の暗号スイートを提供していますこのように正しく応答する方法を知っているために、認証のための方法はありません。
TLS as described in [12] supports compression as well as ciphersuite negotiation. However, TLS only provides support for a limited number of compression types which do not overlap with the compression types used in PPP. As a result, during the EAP-TLS conversation the EAP endpoints MUST NOT request or negotiate compression. Instead, the PPP Compression Control Protocol (CCP), described in [13] should be used to negotiate the desired compression scheme.
で説明したようにTLS [12]は圧縮だけでなく、暗号スイートネゴシエーションをサポートしています。しかし、TLSは、PPPで使用される圧縮タイプと重ならない圧縮タイプの限られた数のためのサポートを提供します。その結果、EAP-TLSの会話中にEAPエンドポイントは、圧縮を要求したり、交渉してはなりません。代わりに、[13]に記載のPPP圧縮制御プロトコル（CCP）は、所望の圧縮方式を交渉するために使用されるべきです。
In the case where the EAP-TLS mutual authentication is successful, the conversation will appear as follows:
次のようにEAP-TLS相互認証が成功した場合には、会話が表示されます。
Authenticating Peer Authenticator
------------------- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
PPP EAP-Response/
EAP-Type=EAP-TLS ->
<- PPP EAP-Success
PPP Authentication
Phase complete,
NCP Phase starts
ECP negotiation CCP negotiation
ECP交渉CCPのネゴシエーション
In the case where the EAP-TLS mutual authentication is successful, and fragmentation is required, the conversation will appear as follows:
次のようにEAP-TLS相互認証が成功すると、断片化が必要な場合には、会話が表示されます。
Authenticating Peer Authenticator
------------------- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS Start, S bit set)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
(Fragment 1: L, M bits set)
PPP EAP-Response/
EAP-Type=EAP-TLS ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(Fragment 2: M bit set)
PPP EAP-Response/
EAP-Type=EAP-TLS ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(Fragment 3)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS inished)(Fragment 1:
L, M bits set)->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
PPP EAP-Response/ EAP-Type=EAP-TLS (Fragment 2)-> <- PPP EAP-Request/ EAP-Type=EAP-TLS (TLS change_cipher_spec, TLS finished) PPP EAP-Response/ EAP-Type=EAP-TLS -> <- PPP EAP-Success PPP Authentication Phase complete, NCP Phase starts
PPP EAP応答/ EAP-タイプ= EAP-TLS（フラグメント2） - > < - PPP EAP要求/ EAP-タイプ= EAP-TLS（TLSのchange_cipher_spec、TLS終了）PPP EAP応答/ EAP-タイプ= EAP- TLS - > < - PPP EAP-成功PPP認証フェーズ完了し、NCPフェーズの開始
ECP negotiation CCP negotiation
ECP交渉CCPのネゴシエーション
In the case where the server authenticates to the client successfully, but the client fails to authenticate to the server, the conversation will appear as follows:
次のようにサーバーが正常にクライアントに認証しますが、クライアントがサーバへの認証に失敗した場合には、会話が表示されます。
Authenticating Peer Authenticator
------------------- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
TLS certificate_request,
TLS server_hello_done)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
TLS certificate_verify, TLS change_cipher_spec, TLS finished) -> <- PPP EAP-Request/ EAP-Type=EAP-TLS (TLS change_cipher_spec, TLS finished) PPP EAP-Response/ EAP-Type=EAP-TLS -> <- PPP EAP-Request EAP-Type=EAP-TLS (TLS Alert message) PPP EAP-Response/ EAP-Type=EAP-TLS -> <- PPP EAP-Failure (User Disconnected)
TLSのcertificate_verify、TLSのchange_cipher_specは、TLS）が終了 - > < - PPP EAP要求/ EAP-タイプ= EAP-TLS（TLSのchange_cipher_spec、TLS終了）PPP EAP応答/ EAP-タイプ= EAP-TLS - > < - PPP EAP -request EAPタイプ= EAP-TLS（TLS警告メッセージ）PPP EAP応答/ EAP-タイプ= EAP-TLS - > < - PPP EAP-障害（ユーザー切断）
In the case where server authentication is unsuccessful, the conversation will appear as follows:
次のようにサーバー認証が失敗した場合には、会話が表示されます。
Authenticating Peer Authenticator
------------------- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec, TLS finished) -> <- PPP EAP-Request/ EAP-Type=EAP-TLS (TLS change_cipher_spec, TLS finished) PPP EAP-Response/ EAP-Type=EAP-TLS (TLS change_cipher_spec, TLS finished) <- PPP EAP-Request/ EAP-Type=EAP-TLS PPP EAP-Response/ EAP-Type=EAP-TLS (TLS Alert message) -> <- PPP EAP-Failure (User Disconnected)
TLSのchange_cipher_spec、TLS終了） - > < - PPP EAP要求/ EAP-TypeがEAP-TLSは、（TLSのchange_cipher_specは、TLSは<）PPP EAP応答/ EAP-タイプ= EAP-TLS（TLSのchange_cipher_specは、TLS終了）終了しました= - PPP EAP要求/ EAP-タイプ= EAP-TLS PPP EAP応答/ EAP-タイプ= EAP-TLS（TLS警告メッセージ） - > < - PPP EAP-失敗（ユーザー切断）
In the case where a previously established session is being resumed, and both sides authenticate successfully, the conversation will appear as follows:
以前に確立されたセッションが再開され、両側が正常に認証次のように、会話が表示される場合：
Authenticating Peer Authenticator
------------------- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
<- PPP EAP-Request/
EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS change_cipher_spec
TLS finished)
PPP EAP-Response/ EAP-Type=EAP-TLS (TLS change_cipher_spec, TLS finished) -> <- PPP EAP-Success PPP Authentication Phase complete, NCP Phase starts
PPP EAP応答/ EAP-タイプ= EAP-TLS（TLSが終了TLSのchange_cipher_spec、） - > < - PPP EAP-成功PPP認証フェーズ完了し、NCPフェーズが開始
ECP negotiation
ECP交渉
CCP negotiation
CCPのネゴシエーション
In the case where a previously established session is being resumed, and the server authenticates to the client successfully but the client fails to authenticate to the server, the conversation will appear as follows:
次のように以前に確立されたセッションが再開されている場合は、サーバが正常にクライアントに認証しますが、クライアントがサーバーへの認証に失敗し、会話が表示されます。
Authenticating Peer Authenticator
------------------- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
<- PPP EAP-Request/
EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello) ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS change_cipher_spec,
TLS finished)
PPP EA-Response/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished) ->
<- PPP EAP-Request
EAP-Type=EAP-TLS
(TLS Alert message)
PPP EAP-Response EAP-Type=EAP-TLS -> <- PPP EAP-Failure (User Disconnected)
PPP EAP-応答EAP-タイプ= EAP-TLS - > < - PPP EAP-失敗（ユーザー切断）
In the case where a previously established session is being resumed, and the server authentication is unsuccessful, the conversation will appear as follows:
以前に確立されたセッションが再開され、サーバの認証に失敗したところ、次のようにケースでは、会話が表示されます。
Authenticating Peer Authenticator
------------------- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
<- PPP EAP-Request/
EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS change_cipher_spec,
TLS finished)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
<- PPP EAP-Request/
EAP-Type=EAP-TLS
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS Alert message) ->
<- PPP EAP-Failure
(User Disconnected)
A summary of the PPP EAP TLS Request/Response packet format is shown below. The fields are transmitted from left to right.
PPP EAP TLS要求/応答パケットフォーマットの概要は以下の通りです。フィールドは左から右に送信されます。
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 | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
コード
1 - Request 2 - Response
1 - 要求2 - 応答
Identifier
識別
The identifier field is one octet and aids in matching responses with requests.
識別子フィールドは、リクエストとレスポンスのマッチングで1オクテットとエイズです。
Length
長さ
The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception.
長さフィールドは2つのオクテットで、コード、識別子、長さ、タイプ、およびデータフィールドを含むEAPパケットの長さを示します。長さフィールドの範囲外のオクテットは、データリンク層のパディングとして扱われるべきで、レセプションで無視しなければなりません。
Type
タイプ
13 - EAP TLS
13 - EAP TLS
Data
データ
The format of the Data field is determined by the Code field.
データフィールドの形式はコードフィールドによって決定されます。
A summary of the PPP EAP TLS Request packet format is shown below. The fields are transmitted from left to right.
PPP EAP TLS要求パケットフォーマットの概要は以下に示されています。フィールドは左から右に送信されます。
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
コード
1
１
Identifier
識別
The Identifier field is one octet and aids in matching responses with requests. The Identifier field MUST be changed on each Request packet.
識別子フィールドは、リクエストとレスポンスのマッチングで1つのオクテットとエイズです。識別子フィールドは、各Requestパケットに変更する必要があります。
Length
長さ
The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, and TLS Response fields.
長さフィールドは2つのオクテットで、コード、識別子、長さ、タイプ、およびTLSの応答フィールドを含むEAPパケットの長さを示します。
Type
タイプ
13 - EAP TLS
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
L =長さはM =以上の断片のSが含ま= EAP-TLSは、=予約Rを起動します
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.
Lビットは、（長さが含まれる）は、4つのオクテットTLSメッセージ長フィールドの存在を示すために設定され、断片化されたTLSメッセージの最初のフラグメントに対して設定またはメッセージの設定しなければなりません。 Mビット（複数の断片）が最後のフラグメント以外のすべてに設定されています。 Sビットは（EAP-TLS開始）EAP-TLS開始メッセージに設定されています。これは、フラグメントの確認からEAP-TLS Startメッセージを区別します。
TLS Message Length
TLSのメッセージの長さ
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メッセージ長フィールドは、4つのオクテットであり、Lビットが設定されている場合にのみ存在します。このフィールドは、TLSメッセージまたは断片化されているメッセージのセットの全体の長さを提供します。
TLS data
TLSデータ
The TLS data consists of the encapsulated TLS packet in TLS record format.
TLSデータは、TLSレコード形式でカプセル化されたTLSパケットで構成されています。
A summary of the PPP EAP TLS Response packet format is shown below. The fields are transmitted from left to right.
PPP EAP TLS応答パケットフォーマットの概要は以下の通りです。フィールドは左から右に送信されます。
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.
識別子フィールドは1つのオクテットであり、対応する要求の識別子フィールドに一致しなければなりません。
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.
長さフィールドは2つのオクテットで、コード、Identifir、長さ、タイプ、およびTLSデータフィールドを含むEAPパケットの長さを示します。
Type
タイプ
13 - EAP TLS
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
L =長さはM =以上の断片のSが含ま= EAP-TLSは、=予約Rを起動します
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.
Lビットは、（長さが含まれる）は、4つのオクテットTLSメッセージ長フィールドの存在を示すために設定され、断片化されたTLSメッセージの最初のフラグメントに対して設定またはメッセージの設定しなければなりません。 Mビット（複数の断片）が最後のフラグメント以外のすべてに設定されています。 Sビットは（EAP-TLS開始）EAP-TLS開始メッセージに設定されています。これは、フラグメントの確認からEAP-TLS Startメッセージを区別します。
TLS Message Length
TLSのメッセージの長さ
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メッセージ長フィールドは、4つのオクテットであり、Lビットが設定されている場合にのみ存在します。このフィールドは、TLSメッセージまたは断片化されているメッセージのセットの全体の長さを提供します。
TLS data
TLSデータ
The TLS data consists of the encapsulated TLS packet in TLS record format.
TLSデータは、TLSレコード形式でカプセル化されたTLSパケットで構成されています。
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[1]シンプソン、W.、エディタ、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[2] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[2] Sklower、K.、ロイド、B.、マクレガー、G.、カー、D.およびT. Coradetti、 "PPPマルチリンクプロトコル（MP）"、RFC 1990、1996年8月。
[3] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January 1994.
[3]シンプソン、W.、エディタ、 "PPP LCP拡張機能"、RFC 1570、1994年1月。
[4] Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[4]のRivest、R.およびS. Dusse、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[5] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[5]ブルンク、L.及びJ. Vollbrecht、 "PPP拡張認証プロトコル（EAP）"、RFC 2284、1998年3月。
[6] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June 1996.
[6]マイヤー、G.、 "PPP暗号化プロトコル（ECP）"、RFC 1968、1996年6月。
[7] National Bureau of Standards, "Data Encryption Standard", FIPS PUB 46 (January 1977).
[7]国立標準局、 "データ暗号化規格"、FIPS PUBの46（1977年1月）。
[8] National Bureau of Standards, "DES Modes of Operation", FIPS PUB 81 (December 1980).
[8]国立標準局、 "動作のDESモード"、FIPS PUBの81（1980年12月）。
[9] Sklower, K. amd G. Meyer, "The PPP DES Encryption Protocol, Version 2 (DESE-bis)", RFC 2419, September 1998.
[9] Sklower、K.およびG.メイヤー、 "PPP DES暗号化プロトコル、バージョン2（DESEビス）"、RFC 2419、1998年9月。
[10] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", RFC 2420, September 1998.
[10] Hummert、K.、 "PPPトリプルDES暗号化プロトコル（3DESE）"、RFC 2420、1998年9月。
[11] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[11]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[12] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, November 1998.
[12]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1998年11月。
[13] Rand, D., "The PPP Compression Control Protocol", RFC 1962, June 1996.
[13]ランド、D.、 "PPP圧縮制御プロトコル"、RFC 1962、1996年6月。
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.
EAPサーバがEAPの会話の間に、インターネット上にあるので、サーバーは、証明書チェーンを、以下のか、ピアの証明書が失効しているかどうかを検証することが可能です。対照的に、ピアは、またはインターネット接続がない場合があり、したがって、それはEAPサーバの証明書は、CAの事前構成されたセットに基づいて検証することができるが、証明書チェーンをたどるか、確認することができないかもしれないEAPサーバの証明書かどうか取り消されました。
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.
ピアがPPTPまたはL2TPを用いた自発的レイヤ2トンネルを開始する場合には、ピアは、典型的には、既にトンネル開始時に確立されたPPPインターフェースおよびインターネット接続性を有することになります。その結果、EAPの会話の間にそれは、証明書の取り消しを確認することが可能です。
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.
しかし、ピアがintial PPP会話を開始している場合には、それがインターネットに接続されていませんので、NCPネゴシエーションが完了し、ピアがインターネットへのアクセスを持っていた後まで、証明書の取り消しを確認することはできません。この場合、ピアは、インターネットに接続した後、証明書の取り消しを確認する必要があります。
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.
EAP-TLSの会話の結果として、EAPのエンドポイントは、相互に、認証暗号スイートを交渉し、PPPの暗号化に使用するためのセッションキーを導出します。ピアとEAPクライアントが同じマシン上に存在するので、EAPクライアントモジュールは、PPPの暗号化モジュールへのセッションキーを渡すために、それが必要です。
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.
状況は、またはEAPサーバと同じマシン上に存在しない場合があり、PPP認証、上より複雑です。 EAPサーバとPPP認証が異なるマシン上に存在する場合には、セキュリティのためのいくつかの意味があります。まず、EAP-TLSで定義された相互認証は、ピアとEAPサーバとの間ではなく、ピアとオーセンティケータとの間で発生します。これは、ピアがNASまたはそれが話しているトンネルサーバのアイデンティティを検証するためのEAP-TLSの会話の結果として、それが不可能であることを意味します。
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 outside the scope of this document.
第二の問題は、ピアとEAPサーバとの間で交渉セッションキーがオーセンティケータに送信する必要があることです。したがって、機構は、キーを使用する必要がオーセンティケータまたはトンネルサーバーにEAPサーバからセッション鍵を送信するために提供される必要があります。この輸送機構の仕様は、この文書の範囲外です。
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.
EAP-TLSは、ダイアルアップPPP接続で主に使用されることが想定されます。しかし、PPP暗号化は、PPTPとL2TPなどのレイヤ2トンネリングプロトコルと共に使用することが可能な状況もあります。
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.
強制的なレイヤ2トンネリングでは、PPPピアは、トンネルサーバーにPPPパケットをトンネルNASまたはルータに接続します。強制的トンネリングでPPPピアはそのパケットがトンネリングされているかどうかを言うことができないので、セキュリティが必要な場合、クライアントは、独自の手配をする必要があり、ネットワークデバイスがトンネルを確保しているかどうかはおろか。すべてのエンドポイントは、IPSEC、TLS、または別の適切なセキュリティプロトコルを実装するために頼ることができない場合には、PPPの暗号化は、クライアントとトンネルサーバー間遷移パケットのプライバシーを確保するために便利な手段を提供します。
Thanks to Terence Spies, Glen Zorn and Narendra Gidwani of Microsoft for useful discussions of this problem space.
この問題空間の有益な議論のためのテレンススパイ、グレンソーンとMicrosoftのナレンドラGidwaniに感謝します。
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052
Phone: 425-936-6605 EMail: bernarda@microsoft.com
電話：425-936-6605 Eメール：bernarda@microsoft.com
Dan Simon Microsoft Corporation One Microsoft Way Redmond, WA 98052
だん しもん みｃろそｆｔ こｒぽらちおん おね みｃろそｆｔ わｙ れｄもんｄ、 わ ９８０５２
Phone: 425-936-6711 EMail: dansimon@microsoft.com
電話：425-936-6711 Eメール：dansimon@microsoft.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。