EAP 번역자료

출처 : http://4ellene.net/tt/863

 

2.1 Support for Sequences An EAP conversation MAY utilize a sequence of methods. EAP통신에는 sequence of methods를 사용한다. A common example of this is an Identity request followed by a single EAP  authentication method such as an MD5-Challenge. 이에 대표적인 예는 MD5-Challenge같이 single EAP authentication method에 의해 Identity요청을 예로 들수 있다. However, the peer and authenticator MUST utilize only one authentication method (Type 4 or greater) within an EAP conversation, after which the authenticator  MUST send a Success or Failure packet. 그러나 peer and authenticator는 EAP통신시 꼭 하나의 authentication method (Type 4 or greater)만을 사용해야 한다. after which the authenticator MUST send a Success or Failure packet. Once a peer has sent a Response of the same Type as the initial Request, an authenticator MUST NOT send a Request of a different Type prior to completion of the final round of a given method (with the exception of a Notification-Request) and MUST NOT send a Request for an additional method of any Type after completion of the initial authentication method; Peer가 요청과 같은 타입의 응답 메시지를 보냈을 때 authenticator는 주어진 방법의 마지막 라운드가 끝나기 전까지는 다른 타입의 요청 메시지를 보내면 안된다. (Notification-Request는 제외) 또한, 초기 인증 방법을 결정후 다른 추가적인 방법을 요청하는 메시지를 보내면 안된다. a peer receiving such Requests MUST treat them as invalid, and silently discard them.  As a result, Identity Requery is not supported. 만약 peer가 그런 요청 메시지를 받았다면 무시 하고 그냥 파기 시켜야 한다. 결국 Identity Requery는 지원하지 않는 다는 뜻이다. A peer MUST NOT send a Nak (legacy or expanded) in reply to a Request after an initial non-Nak Response has been sent. initial non-Nak 응답이 보내지면 응답으로 peer는 Nak를 보내면 안된다.   Since spoofed EAP Request packets may be sent by an attacker, an authenticator  receiving an unexpected Nak SHOULD discard it and log the event. 공격자의 가짜 EAP요청 메시지가 보내 질수 있으므로 예상치 않은 Nak를 받으면 파기하고 로그 파일에 기록한다. Multiple authentication methods within an EAP conversation are not supported due to their vulnerability to man-in-the-middle attacks (see Section 7.4) and incompatibility with existing implementations. 기존 구현과의 충돌과 man-in-the-middle 공격의 취약점 때문에 EAP통신시 다중인증은 지원되지 않는다. (Section 7.4참조) Where a single EAP authentication method is utilized, but other methods are run within it (a "tunneled" method), the prohibition against multiple authentication methods does not apply. Single EAP 인증이 사용시에도 다른 인증법이 (tunneled방법으로) 그 안에서 작용할수 있다.위에서 말한 다중 인증에 대한 제한은 여기에 적용되지 않는다. Such "tunneled" methods appear as a single authentication method to EAP. 이런 tunneled방법은 EAP의 single authentication의 방법으로 사용된다. Backward compatibility can be provided, since a peer not supporting a "tunneled" method can reply to the initial EAP-Request with a Nak (legacy or expanded). Nak로initial EAP-Request응답을 하는 것을 위해 tunneled방법을 사용하지 못하는 peer에는 Backward compatibility가 지원된다. To address security vulnerabilities, "tunneled" methods MUST support protection against man-in-the-middle attacks. 보안상의 문제로 tunneled방식은 man-in-the-middle공격의 대처 방법을 가지고 있어야만 한다. 2.2.  EAP Multiplexing Model Conceptually, EAP implementations consist of the following components: 개념적으로 EAP는 다음과 같은 구성물로 구현된다. [a] Lower layer. The lower layer is responsible for transmitting and receiving EAP frames between the peer and authenticator. Lower layer는 peer와 authenticator사이에서 EAP 프레임 전송과 수신을 담당한다. EAP has been run over a variety of lower layers including PPP, wired IEEE 802 LANs [IEEE-802.1X], IEEE 802.11 wireless LANs [IEEE-802.11],UDP (L2TP [RFC2661] and IKEv2 [IKEv2]), and TCP [PIC]. EAP는 여려 종류의 lower later에서 작동한다. Ex) PPP, wired IEEE 802 LANs [IEEE-802.1X], IEEE 802.11 wireless LANs [IEEE-802.11],UDP (L2TP [RFC2661] and IKEv2 [IKEv2]), TCP [PIC]. Lower layer behavior is discussed in Section 3. Lower layer의 작동에대해서는 섹션 3에서 다루도록 하겠다. [b] EAP layer. The EAP layer receives and transmits EAP packets via the lower layer, implements duplicate detection and retransmission, and delivers and receives EAP messages to and   from the EAP peer and authenticator layers. EAP layer는 lower layey을 통해서 EAP 패킷을 수신하거나 전송한다. 재 전송과 중복 체크 메커니즘을 가지고 있다. EAP peer layer와 authenticator layers사이에서의 EAP메시지 수신 전송을 담당한다. [c] EAP peer and authenticator layers. Based on the Code field, the EAP layer demultiplexes incoming EAP packets to the EAP peer and authenticator layers. Code field의 값을 기반으로 EAP layer는 수신되는 EAP 패킷을 EAP peer layer와 authenticator layer로 demultiplex한다. Typically, an EAP implementation on a given host will support either peer or authenticator functionality, but it is possible for a host to act as both an EAP peer and authenticator. 일반적으로 EAP가 구현된 호스트는 peer나 authenticator 기능을 수행한다. 하지만 이 두가지 기능 모두를 수행 하는 것도 가능하다. In such an implementation both EAP peer and authenticator layers will be present. 이럴경우 EAP peer 와 authenticator layers가 모두 구현되어 있어야 한다. [d] EAP method layers. EAP methods implement the authentication algorithms and receive and transmit EAP messages via the EAP peer and authenticator layers. EAP methods은 EAP peer layer와 authenticator layer를 통한 전송&수신과  인증 알고리즘이 구현되어 있다. Since fragmentation support is not provided by EAP itself, this is the responsibility of EAP methods, which are discussed in Section 5. EAP 그 자체에는 단편화가 지원 되지 않으므로 단편화는 EAP method에 의 해 수행된다.이 내용은 섹션 5에서 다루겠다 The EAP multiplexing model is illustrated in Figure 1 below. EAP multiplexing 모델은 아래 표현되어 있다. Note that there is no requirement that an implementation conform to this model, as long as the on-the-wire behavior is consistent with it. Within EAP, the Code field functions much like a protocol number in IP. EAP경우 Code Field는 IP의 프로토콜 번호와 같은 역할을 한다. It is assumed that the EAP layer demultiplexes incoming EAP packets according to the Code field. EAP layer는 수신되는 EAP패킷을 Code Field 를 참조하여 demultiplex 하는 것으로 생각된다. Received EAP packets with Code=1 (Request), 3 (Success), and 4 (Failure) are delivered by the EAP layer to the EAP peer layer, if implemented. 제대로 구현되어 있다면 Code=1 (Request), 3 (Success), 4 (Failure)EAP 패킷은 EAP layer에 위하여 EAP peer layer로 전달된다. EAP packets with Code=2 (Response) are delivered to the EAP authenticator layer, if  implemented. 제대로 구현되어 있다면, Code=2 (Response) EAP 패킷은 EAP authenticator layer로 전달 된다. Within EAP, the Type field functions much like a port number in UDP or TCP. EAP 경우 Type code는 TCP,UDP의 포트 번호와 같은 역할을 한다. It is assumed that the EAP peer and authenticator layers demultiplex incoming EAP packets according to their Type, and deliver them only to the EAP method corresponding to that Type. EAP peer 와 authenticator layers 는 수신되는 EAP패킷을 type 을 참조하여 demultiplex 하고 적절한 Type에 따라 맞는 EAP method에게 전달 하는 것으로 생각 된다. An EAP method implementation on a host may register to receive packets from the peer or authenticator layers, or both, depending on which role(s) it supports. Since EAP authentication methods may wish to access the Identity,implementations SHOULD make the Identity Request and Response accessible to authentication methods (Types 4 or greater), in addition to the Identity method. EAP 인증 방식이 identity에 접속을 원할수도 있으므로 구현시 Identity 요청과 응답은 (type가 4나 이상일 경우) 인증 방식에 접근할수 있도로 하여야 한다. in addition to the Identity method. The Identity Type is discussed in Section 5.1. Identity Type에 대해서는 섹션 5.1에서 다루도록 하겠다. A Notification Response is only used as confirmation that the peer received the Notification Request, not that it has processed it, or displayed the message to the user. Notification Response은 peer가 Notification Request을 확인할때만 사용된다. 수행하거나 메시지를 사용자에게 보여줄수는 없다. It cannot be assumed that the contents of the Notification Request or Response are available to another method. Notification Request 나 Response의 내용은 다른 방법(method)에게는 유효하지 않을 것으로 예상 된다. The Notification Type is discussed in Section 5.2. Notification Type에 대해서는 섹션 5.2에서 살펴보도록 하겠다. Nak (Type 3) or Expanded Nak (Type 254) are utilized for the purposes of method negotiation. Nak (Type 3)나 Expanded Nak (Type 254)는 협상과정에서 사용된다. Peers respond to an initial EAP Request for an unacceptable Type with a Nak Response (Type 3) or Expanded Nak Response (Type 254). It cannot be assumed that the contents of the Nak Response(s) are available to another method. Nak Response의 내용은 다른 방법에게는 유효하지 않을것으로 예상된다. The Nak Type(s) are discussed in Section 5.3. Nak type에 대해서는 섹션 5.3에서 살펴 보도록 하겠다. EAP packets with Codes of Success or Failure do not include a Type field, and are not delivered to an EAP method. Success 나 Failure 코드의 EAP 패킷은 Type Field를 포함하고 있지 않다. EAP method에게 전달되지도 않는다. Success and Failure are discussed in Section 4.2. Success 와 Failure에 대해서는 섹션 4.2에서 살펴보도록 하겠다. Given these considerations, the Success, Failure, Nak Response(s),and Notification Request/Response messages MUST NOT be used to carry data destined for delivery to other EAP methods. 이런 고려 사항으로 볼 때 Success, Failure, Nak Response, Notification Request/Response 메시지들은 데이터 운반용으로 사용되어서는 안된다. destined for delivery to other EAP methods.   2.3.  Pass-Through Behavior When operating as a "pass-through authenticator", an authenticator   performs checks on the Code, Identifier, and Length fields as   described in Section 4.1. "pass-through authenticator"로 작동시 인증자는 섹션 4.1의 코드, ID, 필드길이 등을 확인 한다 . It forwards EAP packets received from the peer and destined to its authenticator layer to the backend authentication server; Pass-through authenticator는 peer에게서 수신 하거나 목적지가 pass-through authenticator의 authenticator layer 이면 backend authentication server에게 포워딩 한다. packets received from the backend authentication server destined to the peer are forwarded to it. Backend authentication server에게 받은 패킷의 목적지가 peer이면 pass-through authenticator에게 전달된다. A host receiving an EAP packet may only do one of three things with  it: act on it, drop it, or forward it. EAP를 받은 호스트는 다음 3가지 일을 수행한다. 수행,파기,전달 The forwarding decision is typically based only on examination of the Code, Identifier, and Length fields. 전달 작업은 코드,ID, 필드길이에 기반하여 수행된다. A pass-through authenticator implementation MUST be capable of forwarding EAP packets received from the peer with Code=2 (Response) to the backend authentication server. pass-through authenticator가 구현되면 peer에게 코드2(응답)으로 받은 패킷을 backend authentication server에게 전달할수 있어야 한다. It also MUST be capable of receiving EAP packets from the backend authentication   server and forwarding EAP packets of Code=1 (Request), Code=3  (Success), and Code=4 (Failure) to the peer. 또한, backend authentication server로부터 EAP패킷을 받을수 있어야 한다. 그리고 Code=1 (요청), Code=3(성공), and Code=4 (실패)들을 peer에게 전달 할수 있어야   Unless the authenticator implements one or more authentication methods locally which support the authenticator role, the EAP method layer header fields (Type, Type-Data) are not examined as part of the forwarding decision. Authenticator가 로컬하게 하나나 그 이상의 인증 메커니즘이 구현되지 않았다면, EAP 메소드 layer의 헤터 필드(Type, Type-Data)는 전달 기능을 수행 하지 않는다. Where the authenticator supports local authentication methods, it MAY examine the Type field to determine whether to act on the packet itself or forward it.  만약 authenticator가 로컬하게 인증 메커니즘을 지원한다면, type field정보를 이요하여 패킷을 처리 할지 전달 할지를 결정할것이다. Compliant pass-through authenticator implementations MUST by default forward EAP packets of any Type. Compliant pass-through authenticator가 적용되었다면 any type 이라도 EAP를 default값에 따라서 전달하여야 한다. EAP packets received with Code=1 (Request), Code=3 (Success), and Code=4 (Failure) are demultiplexed by the EAP layer and delivered to the peer layer. Code=1 (Request), Code=3 (Success), and Code=4 (Failure)인 EAP패킷은 EAP층에서 demultiplexed를 한후 peer층에게 전달된다. Therefore, unless a host implements an EAP peer layer, these packets will be silently discarded. 그러므로 EAP peer층을 구현되지 않았다면 이런 메시지들은 파기 될것이다. Similarly, EAP packets received with Code=2 (Response) are demultiplexed by the EAP layer and delivered to the authenticator layer. 비슷하게 with Code=2 (Response)인 EAP 패킷은 EAP층에서 demultiplex되고 authenticator층으로 전달 된다. Therefore, unless a host implements an EAP authenticator layer, these packets will be silently discarded. 그러므로 EAP authenticator층이 구현되지 않았다면 이런 패킷들은 파기될것이다. The behavior of a "pass-through peer" is undefined within this specification, and is unsupported by AAA protocols such as RADIUS [RFC3579] and Diameter [DIAM-EAP]. pass-through peer 절차(=behavior)들은 세세하게 정의되지 않았으며 레디우스타 디아미터 같은 AAA 프로토콜이 지원하지 않는다. For sessions in which the authenticator acts as a pass-through, it MUST determine the outcome of the authentication solely based on the Accept/Reject indication sent by the backend authentication server; Authenticator가 pass-through처럼 작동하는 섹션에서는……………. the outcome MUST NOT be determined by the contents of an EAP packet sent along with the Accept/Reject indication, or the absence of such an encapsulated EAP packet. Outcome은 허가/거절값,부재란 indication들 사이에서 보내진 EAP 패킷의 내용에 따라 결정되지 말아야 한다. 2.4.  Peer-to-Peer Operation Since EAP is a peer-to-peer protocol, an independent and simultaneous  authentication may take place in the reverse direction (depending on  the capabilities of the lower layer). EAP가 peer-to-peer protocol이기에 독립적이고 동시작용하는 인증에 대해서는 (low layer의 능력에 따라서) 역방향으로 발생 할수 있다. Both ends of the link may act as authenticators and peers at the same time. 링크의 양단 모두 한번에 authenticators과 peer역할을 동시에 수행할수 있다. In this case, it is necessary for both ends to implement EAP authenticator and peer layers. 이런경우 양단 모두 EAP authenticator layer 와 peer layers가 구현되어 있어야 한다. In addition, the EAP method implementations on both peers must support both authenticator and peer functionality. 더불어 EAP method가 구현된 모든 peer은 authenticator 와 peer 기능을 지원하여야 한다. Although EAP supports peer-to-peer operation, some EAP implementations, methods, AAA protocols, and link layers may not support this. 비록 EAP가 peer-to-peer operation을 지원하다고 해도 일부 EAP implementations, methods, AAA protocols, link layer에서 이것을 지원 못할수도 있다. Some EAP methods may support asymmetric authentication, with one type of credential being required for the peer /and another type for the authenticator. 일부 EAP method는 peer에게 하나의 인증서가 필요하고 authenticator 에게는 다른 인증서가 필요한 비대칭 인증을 지원 할지 모른다. Hosts supporting peer-to-peer operation with such a method would need to be provisioned with both types of credentials. 호스트 지원하는 peer-to-peer operation경우 위와 같은 두 종류의 인증서를 필요로 할것이다. For example, EAP-TLS [RFC2716] is a client-server protocol in which  distinct certificate profiles are typically utilized for the client  and server.  예를 들어 EAP-TLS의 경우 client-server protocol로써 별개의 확인 프로파일 들이 클라이언트와 서버 사이에서 사용된다. This implies that a host supporting peer-to-peer authentication with EAP-TLS would need to implement both the EAP peer and authenticator layers, support both peer and authenticator roles in the EAP-TLS implementation, and provision certificates appropriate for each role. EAP-TLS로 peer-to-peer 인증을 지원하는 호스트는 EAP peer 와 authenticator layer의 구현, EAP-TLS 구현 상에서의 peer and authenticator roles을 지원, 각 룰에 대한 적절한 인증서 등이 필요함을 의미한다. AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP [DIAM-EAP] only support "pass-through authenticator" operation. RADIUS/EAP [RFC3579] , Diameter EAP [DIAM-EAP]와 같은 AAA 프로토콜들은 "pass-through authenticator" operation만을 지원한다. As noted in [RFC3579] Section 2.6.2, a RADIUS server responds to an Access-Request encapsulating an EAP-Request, Success, or Failure packet with  an Access-Reject.  [RFC3579] Section 2.6.2에서 언급했듯이 래디우스 서버는 EAP-Request, Success,Failure packet, Access-Reject정보를 캡슐화 하고 있는 Access-Request에 응답한다. There is therefore no support for "pass-through peer" operation. 그러므로 "pass-through peer" operation에 대한 지원은 없다. Even where a method is used which supports mutual authentication and result indications, several considerations may dictate that two EAP authentications (one in each direction) are required. Method가 상호 인증과 result indications을 위해 사용되는 경우라도 일부 고려사항들은 각 방향마다 하나씩 2개의 EAP authentications이 필요 하다고 말하고 있다. These include: [1] Support for bi-directional session key derivation in the lower layer. lower layer에서의 양방향 섹션 키 derivation지원 Lower layers such as IEEE 802.11 may only support uni-directional derivation and transport of transient session keys. IEEE 802.11같은 Lower layer는 단방향 derivation만을 지원하고 transient 섹션 키를 전송한다. For example, the group-key handshake defined in [IEEE-802.11i] is uni-directional, since in IEEE 802.11 infrastructure mode, only the Access Point (AP) sends multicast/broadcast traffic. 예를 들어 [IEEE-802.11i]에서의 group-key handshake의 정의는 단 방향이다. IEEE 802.11 infrastructure mode에서는 오직 AP(access point)만이 multicast/broadcast을 보낸다. In IEEE802.11 ad hoc mode, where either peer may send multicast/broadcast traffic, two uni-directional group-key exchanges are required. IEEE802.11 ad hoc mode에서는 peer도 multicast/broadcast 트래픽을 보낼수 있다. 두개의 양방향 그룹키 교환이 필요하다. Due to limitations of the design, this also implies the need for unicast key derivations and EAP method exchanges to occur in each direction. 디자인상의 문제로 이것 또한 각 방향으로의 통신(occur)을 위해서는 unicast key derivations와 EAP method exchanges을 필요로 함을 의미한다. [2]Support for tie-breaking in the lower layer.Low layer에서의 tie-breaking지원 Lower layers such as IEEE 802.11 ad hoc do not support "tie breaking" where in two hosts initiating authentication with each other will only go forward with a single authentication. IEEE 802.11같은 lower layer의 ad-hoc은 ……………   This implies that even if 802.11 were to support a bi-directional group-key handshake, then two authentications, one in each direction, might still occur. 이것은 802.11가 양방향 group-key handshake을 지원 하더라도 (각 방향으로 하나씩) 2개의 인증이 필요함을 나타내고 있다. [3] Peer policy satisfaction.  EAP methods may support result indications, enabling the peer to indicate to the EAP server within the method that it successfully authenticated the EAP server, as well as for the server to indicate that it has authenticated the peer. However, a pass-through authenticator will not be aware that the peer has accepted the credentials offered by the EAP server, unless this information is provided to the authenticator via the AAA protocol. 그러나 pass-through authenticator는 peer가 EAP server에 의해 발부된 인증서를 허가 하였음을 AAA프로토콜을 통해 authenticator 에게 통보하기 전까지는 인지 하지 못한다.  The authenticator SHOULD interpret the receipt of a key attribute within an Accept packet as an indication that the peer has successfully authenticated the server. Authenticator는 peer가 서버를 인증(인증된?)했다는 것을 나타내는 허가 패킷들 중에서 응답 key attribute을 해석 하여야 한다.   However, it is possible that the EAP peer's access policy was not satisfied during the initial EAP exchange, even though mutual authentication occurred. 그러나, EAP peer의 접속 정책이 상호 인증을 하였다 하더라도 initial EAP exchange 과정중에는 충분치 않다는 것을 나타낸다. For example, the EAP authenticator may not have demonstrated authorization to act in both peer and authenticator roles. As a result, the peer may require an additional authentication in the reverse direction, even if the peer provided an indication that the EAP server had successfully authenticated to it. 결과적으로 peer는 EAP서버가 인증하였다는 것을 증명 하더라도 역방향시에는 추가적인 인증을 필요로 한다. 4.3.  Retransmission Behavior Because the authentication process will often involve user input, some care must be taken when deciding upon retransmission strategies and authentication timeouts. 인증 작업이 간혹 사용자의 입력값을 사용 하기 떄문에 재 전송 전략이나 인증 타임아웃을 결정할때는 신중을 기해야 한다. By default, where EAP is run over an unreliable lower layer, the EAP retransmission timer SHOULD be dynamically estimated. A maximum of 3-5 retransmissions is suggested. 기본적으로 EAP가 비 신뢰 저계층에서 작동할때는 EAP재전송 타이머는 유동적으로 결정된다. 최대한 재전송 횟수는 3~5로 제안하고 있다. When run over a reliable lower layer (e.g., EAP over ISAKMP/TCP, as within [PIC]), the authenticator retransmission timer SHOULD be set to an infinite value, so that retransmissions do not occur at the EAP layer. 하지만 ISAKMP/TCP같은 신뢰할수 있는 저 계층에서 작동할때는 재 전송 횟수는 무재한으로 설정된다. 그래서 재전송은 EAP layer에서 발생하지 않는다. The peer may still maintain a timeout value so as to avoid waiting indefinitely for a Request. Peer는 타임아웃 값을 계속 유지 할것이다. 그래서 요청에 대하여 무제한 기다리는 것을 피할수 있다. Where the authentication process requires user input, the measured round trip times may be determined by user responsiveness rather than network characteristics, so that dynamic RTO estimation may not be helpful. 인증과정에서 사용자의 입력값이 필요할 때 알맞은 Round trip time은 네트워크 특성이 아니라 사용자의 응답에 의해서 결정된다. 그래서 동적인 RTO 값은 별 도움이 되지 않는다. Instead, the retransmission timer SHOULD be set so as to provide sufficient time for the user to respond, with longer timeouts required in certain cases, such as where Token Cards (see Section 5.6) are involved. 대신에 재 전송 타이머는 사용자가 입력할수 있도록 충분한 시간을 준다. In order to provide the EAP authenticator with guidance as to the appropriate timeout value, a hint can be communicated to the authenticator by the backend authentication server (such as via the RADIUS Session-Timeout attribute). EAP authenticator에게 적절한 타임아웃 값에 대한 기준을 제공하기 위해 hint가 인증 서버에서 authenticator에게 전송된다. In order to dynamically estimate the EAP retransmission timer, the algorithms for the estimation of SRTT, RTTVAR, and RTO described in [RFC2988] are RECOMMENDED, including use of Karn's algorithm, with the following potential modifications: 동적으로 EAP 재전송 시간을 설정하기 위해 SRTT, RTTVAR, and RTO설정을 위한 알고리즘이 RFC2988에 제안 되어 있다. (Karn's algorithm, with the following potential modifications) [a] In order to avoid synchronization behaviors that can occur with fixed timers among distributed systems, the retransmission timer is calculated with a jitter by using the RTO value and randomly adding a value drawn between -RTOmin/2 and RTOmin/2.  분산 시스템의 정해진 타이머로 인해 발생할수 있는 동기화 작업을 피하기 위해 RTO값을 이용하여 jitter를 계산하게 된다. 이때 사용되는 값들은 -RTOmin/2 , RTOmin/2에서 추출한 무작위 수를 이용한다. Alternative  calculations to create jitter MAY be used.  These MUST be pseudo-random.  For a discussion of pseudo-random number generation, see [RFC1750]. Jitter를 구하기 위한 다른 계산법이 사용될수도 있다. 이것은 가짜 랜덤값(pseudo-random)을 사용한다. 이런 가짜 랜덤값을 구하기 위해서는 RFC1750을 참조하라. [b] When EAP is transported over a single link (as opposed to over the Internet), smaller values of RTOinitial, RTOmin, and RTOmax MAY be used. EAP가 single link를 이용해서 전송될떄는 RTOinitial, RTOmin, RTOmax의 작은 값들이 사용된다.   추천 값은 다음과 같다: RTOinitial=1 second, RTOmin=200ms, and RTOmax=20 seconds. [c] When EAP is transported over a single link (as opposed to over the Internet), estimates MAY be done on a per-authenticator basis, rather than a per-session basis.  EAP가 single link를 이용해서 전송될때는 per-session basis 보다는 per-authenticator basis를 통해서 추정된다. This enables the retransmission estimate to make the most use of information on       link-layer behavior. 이것이 재전송 평가를 가능하도록 하여 link layer 작업시 사용하는 유용한 정보를 생성한다. [d] An EAP implementation MAY clear SRTT and RTTVAR after backing off the timer multiple times, as it is likely that the current SRTT and RTTVAR are bogus in this situation.Once SRTT and RTTVAR are cleared, they should be initialized with the next RTT sample taken as described in [RFC2988] equation 2.2.   2006.05.17 by 임헌정 http://www.4ellene.net 짧은 시간에 갑자기 번역 한거라 오역이 많을수 있습니다. [출처] [RFC_3748] Extensible Authentication Protocol(EAP) 일부 번역|작성자 아톰