8.2.1. CHAP Considerations
8.2.1. CHAP 고려 사항
Compliant iSCSI initiators and targets MUST implement the CHAP authentication method [RFC1994] (according to Section 11.1.4 Challenge Handshake Authentication Protocol (CHAP) including the target authentication option).
규정을 준수하는 iSCSI 이니시에이터 및 타겟은 타겟 인증 옵션을 포함하는 섹션 11.1.4 CHAP (Challenge Handshake 인증 프로토콜)에 따라 CHAP 인증 방법 [RFC1994]을 구현해야 합니다.
When CHAP is performed over a non-encrypted channel, it is vulnerable to an off-line dictionary attack.
암호화되지 않은 채널을 통해 CHAP를 수행하는 경우 오프라인 사전 공격에 취약합니다.
Implementations MUST support use of up to 128 bit random CHAP secrets, including the means to generate such secrets and to accept them from an external generation source.
구현에서는 이러한 비밀을 생성하고 외부 생성 소스에서 이를 수락하는 수단을 포함하여 최대 128비트 무작위 CHAP 비밀의 사용을 지원해야 합니다.
Implementations MUST NOT provide secret generation (or expansion) means other than random generation.
구현은 무작위 생성 이외의 비밀 생성 (또는 확장) 수단을 제공해서는 안 됩니다.
An administrative entity of an environment in which CHAP is used with a secret that has less than 96 random bits MUST enforce IPsec encryption (according to the implementation requirements in Section 8.3.2 Confidentiality) to protect the connection.
CHAP가 96개 미만의 임의 비트를 가진 비밀과 함께 사용되는 환경의 관리 엔터티는 연결을 보호하기 위해 IPsec 암호화 (섹션 8.3.2 기밀성의 구현 요구 사항에 따라)를 시행해야 합니다.
Moreover, in this case IKE authentication with group pre-shared cryptographic keys SHOULD NOT be used unless it is not essential to protect group members against off-line dictionary attacks by other members.
또한 이 경우 그룹 사전 공유 암호화 키를 사용한 IKE 인증은 다른 구성원의 오프라인 사전 공격으로부터 그룹 구성원을 보호하는 데 필수적이지 않은 한 사용해서는 안 됩니다.
CHAP secrets MUST be an integral number of bytes (octets).
CHAP 비밀은 정수 바이트 (옥텟)여야 합니다.
A compliant implementation SHOULD NOT continue with the login step in which it should send a CHAP response (CHAP_R, Section 11.1.4 Challenge Handshake Authentication Protocol (CHAP)) unless it can verify that the CHAP secret is at least 96 bits, or that IPsec encryption is being used to protect the connection.
규정을 준수하는 구현은 CHAP 비밀이 최소 96비트인지 또는 IPsec이 IPsec인지 확인할 수 없는 한 CHAP 응답 (CHAP_R, 섹션 11.1.4 CHAP(Challenge Handshake 인증 프로토콜))을 보내야 하는 로그인 단계를 계속해서는 안 됩니다. 연결을 보호하기 위해 암호화가 사용되고 있습니다.
Any CHAP secret used for initiator authentication MUST NOT be configured for authentication of any target, and any CHAP secret used for target authentication MUST NOT be configured for authentication of any initiator.
이니시에이터 인증에 사용되는 CHAP 비밀은 타겟 인증을 위해 구성되어서는 안 되며,타겟 인증에 사용되는 CHAP 비밀은 이니시에이터 인증을 위해 구성되어서는 안 됩니다.
If the CHAP response received by one end of an iSCSI connection is the same as the CHAP response that the receiving endpoint would have generated for the same CHAP challenge, the response MUST be treated as an authentication failure and cause the connection to close (this ensures that the same CHAP secret is not used for authentication in both directions).
iSCSI 연결의 한쪽 끝에서 수신한 CHAP 응답이 수신 끝점이 동일한 CHAP 챌린지에 대해 생성한 CHAP 응답과 동일한 경우 해당 응답은 인증 실패로 처리되어야 하며 연결이 닫혀야 합니다. (이렇게 하면 동일한 CHAP 비밀번호가 양방향 인증에 사용되지 않음이 보장됩니다).
Also, if an iSCSI implementation can function as both initiator and target, different CHAP secrets and identities MUST be configured for these two roles.
또한 iSCSI 구현이 이니시에이터와 타겟 모두로 작동할 수 있는 경우 이 두 역할에 대해 서로 다른 CHAP 암호와 ID를 구성해야 합니다.
The following is an example of the attacks prevented by the above requirements:
다음은 위의 요구 사항으로 방지되는 공격의 예입니다:
Rogue wants to impersonate Storage to Alice, and knows that a single secret is used for both directions of Storage-Alice authentication.
Rogue는 저장소를 Alice로 가장하려고 하며 Storage-Alice 인증의 양방향에 단일 비밀이 사용된다는 것을 알고 있습니다.
Rogue convinces Alice to open two connections to Rogue, and Rogue identifies itself as Storage on both connections.
Rogue는 Alice를 설득해 Rogue와의 두 개의 연결을 열게 하고, 로그는 두 연결 모두에서 자신을 저장소라고 밝힙니다.
Rogue issues a CHAP challenge on connection 1, waits for Alice to respond, and then reflects Alice's challenge as the initial challenge to Alice on connection 2.
Rogue는 연결 1에서 CHAP 챌린지를 발행하고, Alice가 응답할 때까지 기다린 후, Alice의 챌린지를 연결 2에서 Alice에게 최초 챌린지로 반영합니다.
If Alice doesn't check for the reflection across connections, Alice's response on connection 2 enables Rogue to impersonate Storage on connection 1, even though Rogue does not know the Alice-Storage CHAP secret.
Alice가 연결 전반의 반사를 확인하지 않으면 연결 2에서 Alice의 응답을 통해 Rogue는 Alice-Storage CHAP 비밀을 모르더라도 연결 1에서 Storage를 가장할 수 있습니다.
Originators MUST NOT reuse the CHAP challenge sent by the Responder for the other direction of a bidirectional authentication.
발신자는 양방향 인증의 다른 방향에 대해 응답자가 보낸 CHAP 요청을 재사용해서는 안 됩니다.
Responders MUST check for this condition and close the iSCSI TCP connection if it occurs.
응답자는 이 조건을 확인하고 해당 조건이 발생할 경우 iSCSI TCP 연결을 닫아야 합니다.
The same CHAP secret SHOULD NOT be configured for authentication of multiple initiators or multiple targets, as this enables any of them to impersonate any other one of them, and compromising one of them enables the attacker to impersonate any of them.
여러 이니시에이터 또는 여러 타겟의 인증을 위해 동일한 CHAP 비밀을 구성해서는 안 됩니다. 이렇게 하면 둘 중 하나가 다른 하나를 가장할 수 있고, 그 중 하나를 손상시키면 공격자가 둘 중 하나를 가장할 수 있습니다.
It is recommended that iSCSI implementations check for use of identical CHAP secrets by different peers when this check is feasible, and take appropriate measures to warn users and/or administrators when this is detected.
확인이 가능한 경우 iSCSI 구현에서 서로 다른 피어가 동일한 CHAP 암호를 사용하는지 확인하고, 이것이 감지되면 사용자 및/또는 관리자에게 경고하는 적절한 조치를 취하는 것이 좋습니다.
When an iSCSI initiator or target authenticates itself to counterparts in multiple administrative domains, it SHOULD use a different CHAP secret for each administrative domain to avoid propagating security compromises across domains.
iSCSI 이니시에이터 또는 타겟이 여러 관리 도메인의 상대방에 대해 자신을 인증할 때 도메인 전체에 보안 손상이 전파되는 것을 방지하기 위해 각 관리 도메인에 대해 서로 다른 CHAP 비밀을 사용해야 합니다.
Within a single administrative domain:
단일 관리 도메인 내에서:
- A single CHAP secret MAY be used for authentication of an initiator to multiple targets.
- 단일 CHAP 비밀은 여러 타겟에 대한 이니시에이터를 인증하는 데 사용될 수 있습니다.
- A single CHAP secret MAY be used for an authentication of a target to multiple initiators when the initiators use an external server (e.g., RADIUS) to verify the target's CHAP responses and do not know the target's CHAP secret.
- 이니시에이터가 타겟의 CHAP 응답을 확인하기 위해 외부 서버 (예: RADIUS)를 사용하고 타겟의 CHAP 비밀을 모르는 경우 단일 CHAP 비밀은 여러 이니시에이터에 대한 타겟 인증에 사용될 수 있습니다.
If an external response verification server (e.g., RADIUS) is not used, employing a single CHAP secret for authentication of a target to multiple initiators requires that all such initiators know that target secret.
외부 응답 확인 서버 (예: RADIUS)가 사용되지 않는 경우 여러 이니시에이터에 대한 타겟 인증을 위해 단일 CHAP 암호를 사용하려면 모든 이니시에이터가 해당 타겟 암호를 알고 있어야 합니다.
Any of these initiators can impersonate the target to any other such initiator, and compromise of such an initiator enables an attacker to impersonate the target to all such initiators.
이러한 이니시에이터는 다른 이니시에이터에게 타겟을 가장할 수 있으며, 그러한 이니시에이터가 손상되면 공격자는 모든 이니시에이터에게 타겟을 가장할 수 있습니다.
Targets SHOULD use separate CHAP secrets for authentication to each initiator when such risks are of concern; in this situation it may be useful to configure a separate logical iSCSI target with its own iSCSI Node Name for each initiator or group of initiators among which such separation is desired.
타겟은 이러한 위험이 우려되는 경우 각 이니시에이터에 대한 인증을 위해 별도의 CHAP 비밀을 사용해야 합니다. 이러한 상황에서는 분리가 필요한 각 이니시에이터 또는 이니시에이터 그룹에 대해 고유한 iSCSI 노드 이름을 사용하여 별도의 논리적 iSCSI 타겟을 구성하는 것이 유용할 수 있습니다.