---

Chapter 13. Digest Authentication

(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)

---

✏️ 원문 번역

---

Quality of Protection Enhancements

The qop field may be present in all three digest headers: WWW-Authenticate, Authorization, and Authentication-Info.

• qop 필드는 WWW-Authenticate, Authorization, Authentication-Info의 세 가지 digest 헤더에 모두 존재할 수 있습니다.

The qop field lets clients and servers negotiate for different types and qualities of protection. For example, some transactions may want to sanity check the integrity of message bodies, even if that slows down transmission significantly.

• qop 필드는 클라이언트와 서버가 서로 다른 보호 유형과 품질을 협상할 수 있게 합니다.

• 일부 트랜잭션은 속도가 현저히 느려지더라도 메시지 본문의 무결성을 확인하고 싶을 수 있습니다.

The server first exports a comma-separated list of qop options in the WWW-Authenticate header. The client then selects one of the options that it supports and that meets its needs and passes it back to the server in its Authorization qop field.

• 먼저 서버는 WWW-Authenticate 헤더에 콤마로 구분된 qop 옵션 목록을 추가합니다.

• 클라이언트는 서버가 지원하며 요구사항을 만족시키는 옵션 중 하나를 선택하여 Authorization qop 필드에 집어넣어 서버로 전달합니다.

Use of qop is optional, but only for backward compatibility with the older RFC 2069 specification. The qop option should be supported by all modern digest implementations.

• RFC 2069 명세와의 하위 호환을 위해 qop의 사용은 선택적입니다.

• qop 옵션은 모든 현대적인 digest 구현에 지원되어야 합니다.

RFC 2617 defines two initial quality of protection values: “auth,” indicating authentication, and “auth-int,” indicating authentication with message integrity protection. Other qop options are expected in the future.

• RFC 2617은 인증을 나타내는 "auth"와 무결성 검사를 포함한 인증을 나타내는 "auth-int" 두 가지를 보호 값의 초기 품질로 정의합니다.

• 다른 qop 옵션은 향후에 추가될 예정입니다.

---

Message Integrity Protection

If integrity protection is applied (qop=“auth-int”), H (the entity body) is the hash of the entity body, not the message body. It is computed before any transfer encoding is applied by the sender and after it has been removed by the recipient. Note that this includes multipart boundaries and embedded headers in each part of any multipart content type.

• 무결성 보호(qop="auth-int")가 적용되는 경우 H(엔티티 본문)가 메시지 본문이 아닌 엔티티 본문을 해싱합니다.

• 이것은 송신자가 전송 인코딩을 적용하기 전과 수신자가 인코딩을 제거한 후에 연산됩니다.

• 무결성 보호는 멀티파트 콘텐츠 유형의 각 부분에 있는 경계와 임베디드 헤더를 포함합니다.

---

Digest Authentication Headers

Both the basic and digest authentication protocols contain an authorization challenge, carried by the WWW-Authenticate header, and an authorization response, carried by the Authorization header. Digest authentication adds an optional Authorization-Info header, which is sent after successful authentication, to complete a three-phase handshake and pass along the next nonce to use. The basic and digest authentication headers are shown in Table 13-8.

• Basic 및 Digest Authentication 프로토콜은 모두 WWW-Authenticate 헤더를 통해 전달되는 인증 챌린지와 Authorization 헤더로 전달되는 인증 응답을 포함하고 있습니다.

• Digest Authentication은 인증을 성공적으로 마친 후 전송하는 Authorization-Info 헤더를 추가하여 3단계의 handshake를 완료하고 다음에 사용할 nonce를 미리 전달합니다.

• Basic Authentication 헤더와 Digest Authentication 헤더는 Table 13-8에서 나타난 것과 같습니다.

The digest authentication headers are quite a bit more complicated. They are described in detail in Appendix F.

• Digest Authentication 헤더는 조금 더 복잡합니다.

• 자세한 사항은 Appendix F에서 확인할 수 있습니다.

---

Partial Considerations

There are several things you need to consider when working with digest authentication. This section discusses some of these issues.

• Digest Authentication을 사용할 때는 몇 가지 추가로 고려해야 할 사항이 있습니다.

• 이번 섹션에서는 해당 주제에 대해 논의해봅시다.

Multiple Challenges

A server can issue multiple challenges for a resource. For example, if a server does not know the capabilities of a client, it may provide both basic and digest authentication challenges. When faced with multiple challenges, the client must choose to answer with the strongest authentication mechanism that it supports.

• 서버는 하나의 리소스에 대해 여러 개의 챌린지를 발행할 수 있습니다.

• 예를 들어 서버가 클라이언트의 수용력을 알지 못한다면 Basic Authentication과 Digest Authentication Challenge를 둘 다 제공할 수 있습니다.

• 여러 개의 챌린지가 반환되었을 때 클라이언트는 서버가 지원하는 가장 강력한 인증 매커니즘을 선택해야 합니다.

User agents must take special care in parsing the WWW-Authenticate or Proxy-Authenticate header field value if it contains more than one challenge or if more than one WWW-Authenticate header field is provided, as a challenge may itself contain a comma-separated list of authentication parameters. Note that many browsers recognize only basic authentication and require that it be the first authentication mechanism presented.

• 하나 이상의 챌린지를 포함하고 있거나 하나 이상의 WWW-Authenticate 헤더 필드가 제공된 경우 사용자 에이전트는 WWW-Authenticate나 Proxy-Authenticate 헤더 필드 값을 파싱하는 데 주의를 기울여야 합니다.

• 챌린지가 콤마로 구분된 인증 파라미터 목록을 포함할 수 있기 때문입니다.

• 많은 브라우저가 Basic Authentication만을 인식하므로 Basic Authentication 매커니즘이 가장 첫 번째로 제시되어야 한다는 점에 주의합니다.

There are obvious “weakest link” security concerns when providing a spectrum of authentication options. Servers should include basic authentication only if it is minimally acceptable, and administrators should caution users about the dangers of sharing the same password across systems when different levels of security are being employed.

• 인증 옵션 스펙트럼이 주어졌을 때 "가장 약한 연결"에 대한 보안 우려가 분명히 존재합니다.

• 서버는 최소한으로 허용되는 경우에만 Basic Authentication을 포함해야 하며, 관리자는 사용자가 서로 다른 보안 수준을 가진 시스템과 동일한 비밀번호를 공유하지 않도록 경고해야 합니다.

Error Handling

In digest authentication, if a directive or its value is improper, or if a required directive is missing, the proper response is 400 Bad Request.

• Digest Authentication에서 지시어가 부적절하거나 요청된 지시어가 누락된 경우 400 Bad Request 응답을 반환하는 것이 적절합니다.

If a request’s digest does not match, a login failure should be logged. Repeated failures from a client may indicate an attacker attempting to guess passwords.

• 요청 digest가 일치하지 않는다면 로그인 실패 로그가 기록되어야 합니다.

• 클라이언트의 반복적인 실패는 공격자가 비밀번호를 유추하려고 시도 중임을 나타낼 수 있습니다.

The authenticating server must assure that the resource designated by the “uri” directive is the same as the resource specified in the request line; if they are different, the server should return a 400 Bad Request error. (As this may be a symptom of an attack, server designers may want to consider logging such errors.) Duplicating information from the request URL in this field deals with the possibility that an intermediate proxy may alter the client’s request line. This altered (but, presumably, semantically equivalent) request would not result in the same digest as that calculated by the client.

• 인증 서버는 "uri" 지시어로 지정된 리소스가 요청 라인에 명시된 리소스와 일치하도록 보장해야 합니다.

• 만약 두 리소스가 같지 않다면 서버는 400 Bad Request 오류를 반환해야 합니다. (공격 신호일 수 있기 때문에 서버 설계자들은 이러한 오류에 대해 로깅하는 것을 적극 고려할 수 있습니다.)

• 해당 필드에 있는 요청 URL로부터 정보를 복제하는 것은 중간 프록시가 클라이언트의 요청 라인을 대체할 가능성을 나타냅니다.

• 의미적으로는 동일하지만 프록시에 의해 대체된 요청은 클라이언트에 의해 연산된 digest와 동일한 결과를 갖지 않을 것입니다.

Protection Spaces

The realm value, in combination with the canonical root URL of the server being accessed, defines the protection space.

• 접근할 서버의 root URL과 결합된 realm 값은 보호 영역을 정의합니다.

Realms allow the protected resources on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization data-base. The realm value is a string, generally assigned by the origin server, which may have additional semantics specific to the authentication scheme. Note that there may be multiple challenges with the same authorization scheme but different realms.

• realm을 사용하면 서버의 보호된 리소스를 고유한 인증 기법과 and/or 권한 부여 데이터베이스를 가진 보호 영역 집합으로 분할할 수 있게 합니다.

• 일반적으로 realm의 값은 서버가 할당한 문자열입니다.

• 인증 기법을 구체화하기 위해 추가적인 의미가 덧붙을 수도 있습니다.

The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the same credentials may be reused for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference. Unless otherwise defined by the authentication scheme, a single protection space cannot extend outside the scope of its server.

• 보호 영역은 신원 인증이 자동으로 적용될 수 있는 도메인을 결정합니다.

• 과거의 요청이 인가되었다면 동일한 보호 영역 내에 있는 모든 다른 요청에 대해 동일한 신원 인증이 재사용될 수 있습니다.

• 인증 기법, 파라미터, and/or 사용자 속성을 토대로 결정된 일정 기간에 한하여 가능합니다.

• 인증 기법에서 달리 정의하지 않는 한 하나의 보호 영역은 서버의 스코프 바깥으로 확장될 수 없습니다.

The specific calculation of protection space depends on the authentication mechanism:

• In basic authentication, clients assume that all paths at or below the request URI are within the same protection space as the current challenge. A client can preemptively authorize for resources in this space without waiting for another challenge from the server.

• In digest authentication, the challenge’s WWW-Authenticate: domain field more precisely defines the protection space. The domain field is a quoted, space-separated list of URIs. All the URIs in the domain list, and all URIs logically beneath these prefixes, are assumed to be in the same protection space. If the domain field is missing or empty, all URIs on the challenging server are in the protection space.

• 보호 영역의 특수 연산은 인증 매커니즘에 따라 다릅니다.

• Basic Authentication에서 클라이언트는 요청 URI에 있는 모든 경로가 동일한 보호 영역 내에 있다고 가정합니다. 이 영역 내에서는 서버로부터 다른 Challenge를 기다릴 필요 없이 리소스에 대해 선제적으로 권한을 부여할 수 있습니다.

• Digest Authentication에서 Challenge의 WWW-Authenticate: domain 필드는 보호 영역을 보다 명확하게 정의합니다. domain 필드는 공백으로 구분된 quoted URI의 목록입니다. domain 목록의 모든 URI와 이를 접두사로 갖는 모든 URI는 동일한 보호 영역이라 가정합니다. domain 필드가 누락되었거나 비어있다면 인증 중인 서버의 모든 URI가 보호 영역 내에 있다고 간주합니다.

Rewriting URIs

Proxies may rewrite URIs in ways that change the URI syntax but not the actual resource being described. For example:

• Hostnames may be normalized or replaced with IP addresses.

• Embedded characters may be replaced with “%” escape forms.

• Additional attributes of a type that doesn’t affect the resource fetched from the particular origin server may be appended or inserted into the URI.

• 프록시는 URI의 문법을 수정하지만 실제로 나타내는 리소스는 달라지지 않도록 URI를 재작성할 수 있습니다.

• 호스트명은 표준화되거나 IP 주소로 대체될 수 있습니다.

• 임베딩된 문자들이 "%" 탈출 문자 형태로 대체될 수 있습니다.

• 특정 원본 서버로부터 불러온 리소스에 영향을 주지 않는 추가적인 타입 속성이 URI에 추가 혹은 삽입될 수 있습니다.

Because URIs can be changed by proxies, and because digest authentication sanity checks the integrity of the URI value, the digest authentication will break if any of these changes are made. See “The Message-Related Data (A2)” for more information.

• Digest Authentication은 URI의 무결성을 확인하지만 URI가 프록시에 의해 변경될 수 있습니다.

• 따라서 Digest Authentication은 URI에 변화가 발생했을 때 깨질 것입니다.

• "The Message-Related Data(A2)"에서 자세한 내용을 확인하기 바랍니다.

Caches

When a shared cache receives a request containing an Authorization header and a response from relaying that request, it must not return that response as a reply to any other request, unless one of two Cache-Control directives was present in the response:

• If the original response included the “must-revalidate” Cache-Control directive, the cache may use the entity of that response in replying to a subsequent request. However, it must first revalidate it with the origin server, using the request headers from the new request, so the origin server can authenticate the new request.

• If the original response included the “public” Cache-Control directive, the response entity may be returned in reply to any subsequent request.

• 공유된 캐시가 Authorization 헤더를 포함하는 요청을 받아 중계하는 응답을 수신하는 경우, 응답에 두 개의 Cache-Control 지시어 중 하나가 없는 한 요청에 대한 응답으로 해당 응답을 반환하지 않아야 합니다.

• 원본 응답이 "must-revalidate" Cache-Control 지시어를 포함하고 있다면 캐시는 후속 요청에 대한 응답으로 해당 응답의 엔티티를 사용할 수 있습니다. 하지만 새로운 요청으로부터 얻은 요청 헤더를 사용하여 원본 서버와의 재검증이 이루어져야 합니다. 원본 서버가 새로운 요청을 인증할 수 있게 하기 위함입니다.

• 원본 응답이 "public" Cache-Control 지시어를 포함하고 있다면 후속 요청에 대한 응답으로 해당 응답의 엔티티가 반환될 것입니다.

---

✏️ 요약

---

Quality of Protection

: RFC 2617에서 제공하는 보호 품질 옵션 (RFC 2069와의 호환을 위해 선택적으로 사용되는 필드)

• qop : 일반 인증 (무결성 검사 포함 X)
• qop-auth : 엔티티 본문을 해싱하여 무결성 검사를 수행하는 인증

---

Partial Considerations

[1] Multiple Challenges

: 서버가 하나의 리소스에 대해 여러 종류의 챌린지를 발행할 수 있다

• (ex) 서버가 Basic Authentication과 Digest Authentication Challenge를 둘 다 제공할 수 있다
• 클라이언트는 서버가 지원하는 가장 강력한 인증 매커니즘을 선택해야 한다
• 서버는 Basic Authentication을 최소한으로 포함해야 한다

[2] Error Handling

: Digest Authentication 과정에서 적절한 에러 처리가 필요하다

• 지시어가 부적절한 경우 : 400 Bad Request
• digest가 일치하지 않는 경우 : 로그인 실패 로그 기록
• "uri" 지시어로 지정된 리소스가 요청 라인에 명시된 리소스와 일치하지 않는 경우 : 400 Bad Request + 로그 기록

[3] Protection Spaces

: 리소스별로 고유한 인증 기법 및 and/or 권한 부여를 통해 보호 영역 집합으로 분할할 수 있다

• realm : 보호 영역을 나타내는 문자열 (서버가 할당)
• credential이 자동으로 적용될 수 있는(별도의 Challenge 없이 재사용할 수 있는) 도메인 결정
• WWW-Authenticate: domain 필드로 보호 영역 정의 -> domain 목록의 URI를 접두사로 갖는 모든 URI를 동일 보호 영역으로 간주, domain 필드가 없는 경우 서버의 모든 URI가 보호 영역 내에 있다고 간주

[4] Rewriting URIs

: 프록시가 URI를 재작성함으로 인해 digest에 불일치가 발생할 수 있다

• 프록시가 호스트명을 표준화하거나 IP 주소로 대체할 수 있으며 "%" 탈출 문자 형태를 사용할 수 있음
• 프록시에 의해 URI가 변경된 경우 Digest Authentication 중 URI 무결성 체크에서 문제 발생 가능

[5] Caches

: 프록시는 Authorization 헤더를 포함하는 요청에 대해 응답을 중계할 때, 응답에 Cache-Control 지시어 두 개 중 하나가 없으면 해당 응답을 캐시에서 반환하지 않아야 함

• must-revalidate : 원본 서버와 재검증을 통해 후속 요청에 대한 응답 반환 -> 새로운 인증 수행
• public : 후속 요청에 대해 인증 여부와 관계없이 캐시된 응답 반환