Chapter 13. Digest Authentication
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
✏️ 원문 번역
Nonce Selection
The contents of the nonce are opaque and implementation-dependent. However, the quality of performance, security, and convenience depends on a smart choice.
-
nonce의 내용은 불투명하고 구현에 따라 달라집니다.
-
하지만 성능, 보안, 편의성을 고려하여 현명하게 선택할 필요가 있습니다.
RFC 2617 suggests this hypothetical nonce formulation:
BASE64(time-stamp H(time-stamp ":" ETag ":" private-key))where time-stamp is a server-generated time or other nonrepeating value, ETag is the value of the HTTP ETag header associated with the requested entity, and private-key is data known only to the server.
-
RFC 2617에서는 다음과 같은 가상의 논스 공식을 제공합니다.
BASE64(time-stamp H(time-stamp ":" ETag ":" private-key)) -
타임스탬프는 서버가 생성한 시간이나 그 밖의 반복적이지 않은 값을 의미합니다.
-
ETag는 요청받은 엔티티와 연관된 HTTP의 ETag 헤더 값입니다.
-
private-key는 서버만이 알고 있는 키 값을 나타냅니다.
With a nonce of this form, a server will recalculate the hash portion after receiving the client authentication header and reject the request if it does not match the nonce from that header or if the time-stamp value is not recent enough. In this way, the server can limit the duration of the nonce’s validity.
-
이러한 형태의 nonce를 통해 서버는 클라이언트 인증 헤더를 받고 난 뒤 해시값을 다시 계산합니다.
-
nonce가 일치하지 않거나 최신 타임스탬프 값이 아닌 경우 요청을 거절할 수 있습니다.
-
즉 서버가 nonce의 유효 기간을 제한할 수 있습니다.
The inclusion of the ETag prevents a replay request for an updated version of the resource. (Note that including the IP address of the client in the nonce would appear to offer the server the ability to limit the reuse of the nonce to the same client that originally got it. However, that would break proxy farms, in which requests from a single user often go through different proxies. Also, IP address spoofing is not that hard.)
-
ETag는 업데이트된 버전의 리소스에 대한 리플레이 요청을 방지합니다.
-
nonce에 클라이언트의 IP 주소를 포함하는 것은 동일한 클라이언트에 대한 서버의 nonce 재사용 기술을 제한하도록 하는 것처럼 보일 수 있습니다.
-
하지만 단일 사용자의 요청이 여러 프록시를 거치는 프록시 팜이 깨질 수 있습니다.
-
또한 IP 주소를 스푸핑하는 것은 그리 어려운 일도 아닙니다.
An implementation might choose not to accept a previously used nonce or digest, to protect against replay attacks. Or, an implementation might choose to use one-time nonces or digests for POST or PUT requests and time-stamps for GET requests.
-
리플레이 공격에 대응하기 위해 이전에 사용한 nonce나 digest를 허용할지 말지는 구현하는 사람 마음입니다.
-
POST나 PUT 요청에 대한 일회성 nonce나 digest와 GET 요청에 대한 타임스탬프 사용 여부도 결정할 수 있습니다.
Refer to “Security Considerations” for practical security considerations that affect nonce selection.
- nonce 선택에 영향을 미치는 실용적인 보안적 고려사항은 "Security Considerations"를 참고하기 바랍니다.
Symmetric Authentication
RFC 2617 extends digest authentication to allow the client to authenticate the server. It does this by providing a client nonce value, to which the server generates a correct response digest based on correct knowledge of the shared secret information. The server then returns this digest to the client in the Authorization-Info header.
-
RFC 2617은 클라이언트가 서버를 인증할 수 있도록 Digest Authentication을 확장하였습니다.
-
클라이언트의 nonce 값을 제공하여 서버가 공유된 기밀 정보를 토대로 올바른 응답 digest를 생성하는 방식으로 이루어집니다.
-
서버는 Authorization-Info 헤더에 해당 digest를 실어 클라이언트로 반환합니다.
This symmetric authentication is standard as of RFC 2617. It is optional for backward compatibility with the older RFC 2069 standard, but, because it provides important security enhancements, all modern clients and servers are strongly recommended to implement all of RFC 2617’s features. In particular, symmetric authentication is required to be performed whenever a qop directive is present and required not to be performed when the qop directive is missing.
-
Symmetric Authentication은 RFC 2617 표준입니다.
-
구버전인 RFC 2069 표준과의 하위 호환은 선택적이지만 보안 측면에서 상당히 개선되었기 때문에 오늘날의 클라이언트와 서버는 RFC 2617의 기능을 모두 구현하기를 강력히 권장하고 있습니다.
-
특히 Symmeteric Authentication은 qop 지시문이 존재할 때만 수행되어야 합니다.
The response digest is calculated like the request digest, except that the message body information(A2) is different, because there is no method in a response, and the message entity data is different. The methods of computation of A2 for request and response digests are compared in Tables 13-6 and 13-7.
-
응답 digest는 메시지 본문 정보(A2)가 다르다는 점을 제외하면 요청 digest와 동일한 방식으로 연산됩니다.
-
메시지 본문이 다른 까닭은 응답에 메서드가 없기 때문입니다.
-
요청과 응답 digest에서 A2를 연산하는 방식은 Table 13-6과 13-7에서 비교하고 있습니다.
The cnonce value and nc value must be the ones for the client request to which this message is the response. The response auth, cnonce, and nonce count directives must be present if qop=“auth” or qop=“auth-int” is specified.
-
cnonce 값과 nc 값은 해당 메시지를 응답으로 받은 클라이언트 요청에 대한 것이어야 합니다.
-
qop="auth"혹은qop="auth-int"가 지정된 경우에는 반드시 응답의 auth, cnonce, nonce count 지시문이 나타나야 합니다.
✏️ 요약
RFC 2617 Nonce Formulation
BASE64(time-stamp H(time-stamp ":" ETag ":" private-key))- time-stamp : 서버가 생성한 시간, 또는 반복적이지 않은 그 밖의 값
- ETag : 요청 엔티티와 연관된 HTTP의 ETag 헤더 값 -> 수정된 리소스에 대한 리플레이 요청 방지
- private-key : 서버만 알고 있는 비밀 키
- 서버는 헤더로부터 받은 nonce 값이 일치하지 않거나 최신 time-stamp 값이 아닌 경우 요청을 거절할 수 있음
- nonce에 IP 주소를 넣는 것은 권장되지 않음
Symmetric Authentication
: 클라이언트가 서버를 인증하는 것
- 클라이언트의 nonce 값 제공 -> 서버가 올바른 digest 생성
- 서버가 Authorization-Info에 digest를 실어 클라이언트로 전달
- 응답 digest는 메시지 본문(A2)을 제외하고 요청 digest와 동일
:uri-directive-value> :uri-directive-value>:H(<response-entity-body>) - qop 지시문이 존재할 때만 사용
✏️ 감상
읽으면서도 헷갈리는 cnonce
자꾸 cnonce, cnonce 하는데 이게 도대체 무엇이고 왜 nonce와 분리해서 설명하는 건지 사실 감이 잘 안 왔다.
이 책의 앞 부분에서는 cnonce를 클라이언트와 서버간 안전한 통신을 위해 사용하는 값으로 정의하고 있다. 재전송이 발생하게 되면 동일한 cnonce 값이 서버에 전달되기 때문에 서버가 재전송 여부를 식별할 수 있다는 것이다. 즉, 서버 측에서 전송하는 nonce는 비밀번호를 예측할 수 없게 덧붙이는 salt 값이고 cnonce는 리플레이 공격을 방지하기 위해 사용되는 값이다. 물론 서버가 전송하는 nonce 값도 리플레이를 방지하는 데 사용되긴 하지만, Preemtive Authentication이 필요한 환경에서는 제한적일 수 있다.
또한 cnonce는 클라이언트가 서버로 인증을 요청할 때 각 요청마다 새로운 인증값을 생성할 수 있게 한다는 점에서 중요하다. 특히 클라이언트가 request/challenge 과정을 거치지 않고 Authentication을 선제적으로 발행하기 위해서는 서버 측에서 횟수나 시간을 제한하여 nonce를 재사용해야 하는 경우가 있다.
만약 cnonce 값이 없다면, 해당 요청이 정상적인 것인지 동일한 nonce에 대해 공격자가 리플레이 공격을 가하는 것인지 알 수 없다. 반면 cnonce 값은 클라이언트가 요청을 전송할 때마다 새롭게 생성되므로 리플레이 요청을 구별할 수 있다.
때문에 qop가 지정된 경우에는 cnonce를 집어넣어서 Symmetric Authentication을 수행하는 것이 좋다.
