인터넷 엔지니어링 태스크 포스 (IETF) D. Schinazi
요청 의견(Request for Comments): 9729 Google LLC
분류: 표준 트랙 D. Oliver
ISSN: 2070-1721 Guardian Project
J. Hoyland
Cloudflare Inc.
2025년 2월

은닉된 HTTP 인증 방식

초록

대부분의 HTTP 인증 방식은 인증되지 않은 클라이언트가 어떤 오리진이 인증을 요구하는 리소스를 제공하는지 탐지(probe)할 수 있다는 의미에서 탐지 가능(probeable)합니다. 오리진은 Unauthorized 상태 코드를 생성하지 않음으로써 인증을 요구한다는 사실을 숨길 수 있지만, 이는 비암호적 인증 방식에서만 작동합니다. 암호화 서명은 서명에 사용할 새로운 nonce가 필요하기 때문입니다. 이 문서 이전에는 오리진이 그러한 nonce를 노출하지 않고 공유할 방법이 존재하지 않았습니다. 본 문서는 새로운 비-프로브 가능한 암호화 인증 방식을 정의합니다.

이 메모의 상태

이 문서는 인터넷 표준 트랙 문서입니다.

이 문서는 인터넷 엔지니어링 태스크 포스(IETF)의 산물입니다. 이는 IETF 커뮤니티의 합의를 나타냅니다. 공개 검토를 거쳤으며 인터넷 엔지니어링 운영 그룹(IESG)에 의해 게시 승인을 받았습니다. 인터넷 표준에 관한 추가 정보는 RFC 7841의 섹션 2에서 확인할 수 있습니다.

이 문서의 현재 상태, 정정표(errata) 및 피드백 제출 방법에 대한 정보는 https://www.rfc-editor.org/info/rfc9729에서 확인할 수 있습니다.

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

1. 소개

HTTP 인증 방식(참조: Section 11 of [HTTP])은 오리진이 일부 리소스에 대해 인증된 요청만 접근을 허용하도록 할 수 있습니다. 이러한 방식은 보통 오리진이 클라이언트에게 인증 정보를 제공하도록 요구하는 챌린지를 포함하지만, 클라이언트가 사전 요청 없이 인증 정보를 보낼 수도 있습니다. 이는 오리진이 특정 서비스나 기능을 "알고 있는 자"에게만 제공하고, 다른 사용자에게는 그 기능의 존재를 알리지 않으려는 경우에 유용합니다. 이러한 설계는 키 배포를 위한 외부 메커니즘에 의존합니다. 예를 들어, 회사가 직원 자격 증명으로 웹사이트를 통해 원격 직원 액세스를 제공하거나 특정 직원에게만 제한된 특수 기능을 제공하면서 이러한 기능을 발견(또는 탐지)하기 어렵게 만들 수 있습니다. 또 다른 예로는 덜 명확한 커뮤니티의 구성원들이 보다 단기적인 키를 사용하여 지리적 또는 기능별로 제한된 리소스에 접근하는 경우가 있으며, 이는 키를 발급하는 주체가 시간적 또는 지리적으로 키의 사용을 조절할 수 있기 때문입니다.

디지털 서명 기반의 HTTP 인증 방식(예: [HOBA])은 이미 존재하지만, 이러한 방식은 서명 입력의 신선성을 보장하기 위해 오리진이 클라이언트에게 명시적으로 새 챌린지를 보내야 합니다. 이는 오리진이 인증되지 않은 클라이언트에 챌린지를 보내므로 오리진을 탐지 가능하게 만듭니다. 본 문서는 탐지 불가능한 서명 기반 인증 방식을 정의합니다.

1.1. 관례 및 정의

문서 내의 핵심 단어 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 및 "OPTIONAL"은 모두 대문자로 표기된 경우에 한해 BCP 14(참조: [RFC2119], [RFC8174])에 설명된 대로 해석됩니다.

이 문서는 Section 1.3 of [QUIC]의 표기법을 사용합니다.

문서의 다양한 예제에는 긴 줄이 포함되어 있어 [RFC8792]에 설명된 대로 접기가 가능합니다.

2. 은닉된 HTTP 인증 방식

본 문서는 "Concealed" HTTP 인증 방식을 정의합니다. 이 방식은 비대칭 암호화 방식을 사용합니다. 클라이언트는 key ID와 공개/개인 키 쌍을 보유하고, 오리진 서버는 권한 있는 key ID를 관련 공개 키에 매핑한 자료구조를 유지합니다.

클라이언트는 서명할 데이터를 생성하기 위해 TLS 키 자료 익스포터를 사용합니다(참조: 섹션 3). 그런 다음 Authorization(또는 Proxy-Authorization) 헤더 필드를 사용하여 서명을 전송합니다(참조: Section 11 of [HTTP]). 서명 및 추가 정보는 인증 매개변수를 통해 교환됩니다(참조: 섹션 4). 서버가 이를 수신하면, 서버는 자신의 알려진 키 데이터베이스 항목과 대조하여 서명 검증을 수행할 수 있습니다. 서버는 검증 결과를 사용하여 클라이언트에 대한 응답(예: 특정 리소스 접근 제한)에 영향을 줄 수 있습니다.

3. 클라이언트 처리

클라이언트가 요청에 대해 Concealed HTTP 인증 방식을 사용하려는 경우, TLS 키 자료 익스포터를 사용하여 다음 매개변수로 인증 증명을 계산해야 합니다:

  • label은 "EXPORTER-HTTP-Concealed-Authentication"으로 설정됩니다.

  • context는 섹션 3.1에 설명된 구조로 설정됩니다.

  • exporter 출력 길이는 48바이트로 설정됩니다(참조: 섹션 3.2).

참고로 TLS 1.3 키 자료 익스포터는 Section 7.5 of [TLS]에 정의되어 있고, TLS 1.2의 키 자료 익스포터는 [KEY-EXPORT]에 정의되어 있습니다.

3.1. 키 익스포터 컨텍스트

TLS 키 익스포터 컨텍스트는 그림 1에 설명되어 있으며, Section 1.3 of [QUIC]의 표기법을 사용합니다:

  Signature Algorithm (16),
  Key ID Length (i),
  Key ID (..),
  Public Key Length (i),
  Public Key (..),
  Scheme Length (i),
  Scheme (..),
  Host Length (i),
  Host (..),
  Port (16),
  Realm Length (i),
  Realm (..),

그림 1: 키 익스포터 컨텍스트 형식

키 익스포터 컨텍스트에는 다음 필드들이 포함됩니다:

Signature Algorithm:
이는 s 매개변수에 전송되는 서명 스킴입니다(참조: 섹션 4.4).
Key ID:
이는 k 매개변수에 전송되는 key ID입니다(참조: 섹션 4.1).
Public Key:
이는 서버가 클라이언트가 제공한 서명을 검증하기 위해 사용하는 공개 키입니다. 인코딩은 섹션 3.1.1에 설명되어 있습니다.
Scheme:
이 요청의 스킴으로, Section 3.1 of [URI]에서 정의된 URI의 스킴 부분 형식으로 인코딩됩니다.
Host:
이 요청의 호스트로, Section 3.2.2 of [URI]에서 정의된 URI의 호스트 부분 형식으로 인코딩됩니다.
Port:
이 요청의 포트이며 네트워크 바이트 오더로 인코딩됩니다. 포트는 URI에 포함되거나 사용 중인 스킴의 기본 포트일 수 있습니다(참조: Section 3.2.3 of [URI]).
Realm:
이는 realm 인증 매개변수에 전송되는 인증 영역입니다(참조: Section 11.5 of [HTTP]). realm 인증 매개변수가 존재하지 않으면, 이 필드는 비어 있어야 합니다. 본 문서는 오리진이 클라이언트에게 realm을 전달하는 수단을 정의하지 않습니다. 클라이언트가 특정 realm 사용으로 구성되지 않은 경우, 빈 realm을 사용해야 하며 realm 인증 매개변수를 전송해서는 안 됩니다.

Signature Algorithm 및 Port 필드는 네트워크 바이트 오더의 부호 없는 16비트 정수로 인코딩됩니다. Key ID, Public Key, Scheme, Host 및 Realm 필드는 길이-접두 문자열로 인코딩됩니다; 즉 이들 앞에는 바이트 길이를 나타내는 Length 필드가 옵니다. 이 길이 필드들은 Section 16 of [QUIC]의 가변 길이 정수 인코딩을 사용하여 인코딩되며, 가능한 최소 바이트 수로 인코딩되어야 합니다.

3.1.1. 공개 키 인코딩

TLS 키 익스포터 컨텍스트의 "Public Key" 필드(위 참조)와 a 매개변수(참조: 섹션 4.2)는 동일한 공개 키를 담습니다. 공개 키의 인코딩은 사용 중인 서명 알고리즘에 따라 다음과 같이 결정됩니다:

RSASSA-PSS 알고리즘:
공개 키는 RSAPublicKey 구조체([PKCS1])이며 DER([X.690])로 인코딩됩니다. BER 인코딩 중 DER이 아닌 것은 거부되어야 합니다.
ECDSA 알고리즘:
공개 키는 Section 4.2.8.2 of [TLS]에 정의된 UncompressedPointRepresentation 구조이며, SignatureScheme이 지정한 곡선을 사용합니다.
EdDSA 알고리즘:
공개 키는 [EdDSA]에 정의된 바이트 문자열 인코딩입니다.

본 문서는 다른 알고리즘에 대한 공개 키 인코딩을 정의하지 않습니다. Concealed HTTP 인증 방식에서 사용 가능한 SignatureScheme이 되려면 해당 공개 키 인코딩이 해당 알고리즘 문서에서 정의되어야 합니다.

3.2. 키 익스포터 출력

키 익스포터 출력은 48바이트 길이입니다. 이 중 처음 32바이트는 서명의 입력의 일부이고, 다음 16바이트는 서명과 함께 전송됩니다. 이는 수신자가 익스포터가 올바른 값을 생성했는지 확인할 수 있게 해줍니다. 이는 그림 2에 설명되어 있으며, Section 1.3 of [QUIC]의 표기법을 사용합니다:

  Signature Input (256),
  Verification (128),

그림 2: 키 익스포터 출력 형식

키 익스포터 출력은 다음 필드들을 포함합니다:

Signature Input:
이는 클라이언트가 선택한 비대칭 개인 키로 서명하는 데이터의 일부입니다(참조: 섹션 3.3).
Verification:
검증 값은 v 매개변수를 통해 서버로 전송됩니다(참조: 섹션 4.5).

3.3. 서명 계산

Signature Input이 키 익스포터 출력에서 추출되면(참조: 섹션 3.2), 서명 전에 정적 데이터가 접두되어 서명됩니다. 서명은 다음을 연결한 데이터에 대해 계산됩니다:

  • 옥텟 32(0x20)를 64번 반복한 문자열

  • 컨텍스트 문자열 "HTTP Concealed Authentication"

  • 구분자로 사용되는 단일 0 바이트

  • 키 익스포터 출력에서 추출된 Signature Input(참조: 섹션 3.2)

예를 들어, Signature Input의 32바이트가 모두 01로 설정된 경우 서명이 적용되는 내용(16진수 형식)은 다음과 같습니다:

2020202020202020202020202020202020202020202020202020202020202020
2020202020202020202020202020202020202020202020202020202020202020
48545450205369676E61747572652041757468656E7469636174696F6E
00
0101010101010101010101010101010101010101010101010101010101010101

그림 3: 서명이 적용되는 예제 내용

이 정적 접두의 목적은 인증 비대칭 키가 실수로 다른 프로토콜에서 재사용되는 경우에 발생할 수 있는 문제를 완화하는 것입니다(이는 금지되어 있음에도 불구하고; 자세한 내용은 섹션 8 참조). 이 구성은 TLS 1.3의 CertificateVerify 메시지(Section 4.4.3 of [TLS])의 구성과 유사합니다.

그 결과 생성된 서명은 p 매개변수를 통해 서버로 전송됩니다(참조: 섹션 4.3).

4. 인증 매개변수

본 규격은 다음 인증 매개변수들을 정의합니다.

아래의 모든 바이트 시퀀스는 base64url(참조: Section 5 of [BASE64])로 인코딩되며, 따옴표 및 패딩 없이 표기됩니다. 즉, 이러한 바이트-시퀀스 인증 매개변수 값들은 ASCII 문자 중 영문자, 숫자, 대시(-), 밑줄(_) 이외의 문자를 포함해서는 안 됩니다.

아래 정수는 마이너스 기호 및 선행 0 없이 인코딩됩니다. 즉, 이 정수 인증 매개변수 값은 숫자 이외의 문자를 포함해서는 안 되며, 전체 값이 "0"인 경우를 제외하고 선행 0으로 시작해서는 안 됩니다.

다음은 [ABNF] 표기법을 사용한 문법입니다:

concealed-byte-sequence-param-value = *( ALPHA / DIGIT / "-" / "_" )
concealed-integer-param-value =  %x31-39 1*4( DIGIT ) / "0"

그림 4: 인증 매개변수 값 ABNF

4.1. k 매개변수

필수(REQUIRED)인 "k"(key ID) 매개변수는 클라이언트가 인증에 사용하려는 키를 식별하는 바이트 시퀀스입니다. 백엔드는 이를 사용하여 서버 측의 알려진 키 데이터베이스 항목을 가리킵니다(참조: 섹션 6.3).

4.2. a 매개변수

필수(REQUIRED)인 "a"(공개 키) 매개변수는 서버가 클라이언트가 제공한 서명을 검증하는 데 사용하는 공개 키를 지정하는 바이트 시퀀스입니다. 이는 키 혼동 문제를 방지합니다(참조: [SEEMS-LEGIT]). 공개 키의 인코딩은 섹션 3.1.1에 설명되어 있습니다.

4.3. p 매개변수

필수(REQUIRED)인 "p"(proof) 매개변수는 클라이언트가 자신의 key ID와 일치하는 자격 증명을 소유하고 있음을 증명하기 위해 제공하는 바이트 시퀀스입니다.

4.4. s 매개변수

필수(REQUIRED)인 "s"(signature scheme) 매개변수는 p 매개변수에 전송된 증명을 계산하는 데 사용된 서명 스킴을 지정하는 정수입니다. 이 값은 0에서 65535 사이의 정수이며 IANA의 "TLS SignatureScheme" 레지스트리(<https://www.iana.org/assignments/tls-parameters>)에서 가져옵니다.

4.5. v 매개변수

필수(REQUIRED)인 "v"(verification) 매개변수는 클라이언트가 키 익스포터 출력을 보유하고 있음을 증명하기 위해 제공하는 바이트 시퀀스입니다(자세한 내용은 섹션 3.2 참조). 이는 특정 키가 여러 입력에 대해 유효한 서명을 생성할 수 있는 일부 서명 스킴과 관련된 문제를 방지합니다(참조: [SEEMS-LEGIT]).

5. 예제

예를 들면, key ID가 "basement"이고 서명 알고리즘이 Ed25519인 클라이언트([ED25519]) 는 다음과 같은 헤더 필드를 생성할 수 있습니다:

NOTE: '\' 줄 바꿈은 RFC 8792에 따름

Authorization: Concealed \
  k=YmFzZW1lbnQ, \
  a=VGhpcyBpcyBh-HB1YmxpYyBrZXkgaW4gdXNl_GhlcmU, \
  s=2055, \
  v=dmVyaWZpY2F0aW9u_zE2Qg, \
  p=QzpcV2luZG93c_xTeXN0ZW0zMlxkcml2ZXJz-ENyb3dkU\
    3RyaWtlXEMtMDAwMDAwMDAyOTEtMD-wMC0w_DAwLnN5cw

그림 5: 예제 헤더 필드

6. 서버 처리

본 절에서는 서버의 역할을 둘로 나눕니다:

  • “프론트엔드(frontend)”는 클라이언트가 생성한 TLS 또는 QUIC 연결을 종료하는 HTTP 서버에서 동작합니다.

  • “백엔드(backend)”는 허용된 키 식별자 및 공개 키의 데이터베이스에 접근할 수 있는 HTTP 서버에서 동작합니다.

대부분의 배포에서는 프론트엔드와 백엔드 역할이 단일 HTTP 오리진 서버(참조: Section 3.6 of [HTTP])에 구현될 것으로 예상됩니다. 그러나 이 역할들은 프론트엔드를 HTTP 게이트웨이(참조: Section 3.7 of [HTTP])로, 백엔드를 HTTP 오리진 서버로 분리하여 구성할 수 있습니다.

6.1. 프론트엔드 처리

프론트엔드가 Concealed HTTP 인증 방식을 검사하도록 구성된 경우, Authorization(또는 Proxy-Authorization) 헤더 필드를 파싱합니다. 인증 방식이 "Concealed"로 설정되어 있으면, 프론트엔드는 섹션 4에 정의된 대로 모든 필수 인증 매개변수가 존재하고 올바르게 파싱될 수 있는지 반드시 검증해야 합니다. 어떤 매개변수가 누락되었거나 파싱에 실패하면, 프론트엔드는 Authorization(또는 Proxy-Authorization) 헤더 필드 전체를 무시해야 합니다.

프론트엔드는 그런 다음 이들 인증 매개변수의 데이터를 사용하여 섹션 3.2에 정의된 대로 키 익스포터 출력을 계산합니다. 프론트엔드는 그 다음 헤더 필드와 키 익스포터 출력을 백엔드와 공유합니다.

6.2. 프론트엔드와 백엔드 간 통신

프론트엔드와 백엔드 역할이 같은 머신에 구현된 경우, 이는 단순한 함수 호출로 처리할 수 있습니다.

역할이 두 개의 분리된 HTTP 서버에 나뉘는 경우, 백엔드는 클라이언트와 프론트엔드 간의 TLS 연결에서 TLS 키 익스포터에 직접 접근할 수 없으므로 프론트엔드가 명시적으로 이를 전송해야 합니다. 본 문서는 이를 위해 "Concealed-Auth-Export" 요청 헤더 필드를 정의합니다. Concealed-Auth-Export 헤더 필드의 값은 48바이트 키 익스포터 출력(참조: 섹션 3.2)을 포함하는 Structured Field Byte Sequence(참조: Section 3.3.5 of [STRUCTURED-FIELDS])이며, 매개변수는 없습니다. 구조화된 필드 바이트 시퀀스는 URL 안전이 아닌 base64 변형을 사용하여 인코딩된다는 점에 유의하십시오. 예를 들면: 

NOTE: '\' 줄 바꿈은 RFC 8792에 따름

Concealed-Auth-Export: :VGhpc+BleGFtcGxlIFRMU/BleHBvcn\
  Rlc+BvdXRwdXQ/aXMgNDggYnl0ZXMgI/+h:

그림 6: Concealed-Auth-Export 헤더 필드 예

프론트엔드는 원본의 수정되지 않은 Authorization(또는 Proxy-Authorization) 헤더 필드와 새로 추가된 Concealed-Auth-Export 헤더 필드를 포함하여 HTTP 요청을 백엔드로 전달해야 합니다.

키 익스포터 출력의 보안이 올바름에 의해 좌우되므로, 백엔드는 프론트엔드가 이를 진실되게 보냈다고 신뢰해야 합니다. 이러한 신뢰 관계는 프론트엔드가 이미 요청에 응답하기 위해 TLS 인증서 개인 키에 접근할 필요가 있기 때문에 일반적입니다. Concealed-Auth-Export 헤더 필드를 파싱하는 HTTP 서버는 발신자를 신뢰한다고 이미 확립한 경우가 아니면 이를 무시해야 합니다. 마찬가지로, Concealed-Auth-Export 헤더 필드를 전송하는 프론트엔드는 클라이언트로부터 받은 어떤 Concealed-Auth-Export 헤더 필드도 전달하지 않도록 보장해야 합니다.

6.3. 백엔드 처리

백엔드가 Authorization(또는 Proxy-Authorization) 헤더 필드와 키 익스포터 출력을 수신하면, 자신의 공개 키 데이터베이스에서 key ID를 조회합니다. 백엔드는 다음 검증들을 반드시 수행해야 합니다:

  • 섹션 4에 정의된 대로 모든 필수 인증 매개변수가 존재하고 올바르게 파싱되는지 검증

  • key ID가 백엔드의 데이터베이스에 존재하며 해당 공개 키에 매핑되는지 확인

  • 데이터베이스의 공개 키가 Authorization(또는 Proxy-Authorization) 헤더 필드의 공개 키와 동일한지 검증

  • Authorization(또는 Proxy-Authorization) 헤더 필드의 verification 필드가 키 익스포터 출력에서 추출한 것과 일치하는지 검증

  • 섹션 3.3에 정의된 대로 암호학적 서명을 검증

이들 검증이 모두 성공하면, 백엔드는 요청이 적절히 인증되었다고 간주하고 적절히 응답할 수 있습니다(백엔드는 요청을 다른 HTTP 서버로 전달할 수도 있습니다).

위 검증들 중 어느 하나라도 실패하면, 백엔드는 Authorization(또는 Proxy-Authorization) 헤더 필드가 없었던 것처럼 처리해야 합니다.

6.4. 비-프로브 가능 서버 처리

존재 여부를 탐지할 수 없는 리소스를 도입하려는 서버는 인증되지 않은 클라이언트에게 그 리소스에 관한 어떠한 정보도 노출하지 않도록 해야 합니다. 특히, 이러한 서버는 인증 실패에 대해 존재하지 않는 리소스에 사용했을 동일한 응답을 반드시 사용해야 합니다. 예를 들어 이는 401(Unauthorized) 대신 404(Not Found) 상태 코드를 사용하는 것을 의미할 수 있습니다.

위에서 설명한 인증 검증은 시간이 걸릴 수 있으며, 공격자는 알려진 존재하지 않는 리소스에 대한 요청의 타이밍과 잠재적으로 인증된 리소스에 대한 요청의 타이밍을 비교하여 이 메커니즘의 사용을 감지할 수 있습니다. 서버는 인증 검증의 타이밍이 관찰되지 않도록 일부 존재하지 않는 리소스에 대한 응답을 약간 지연시켜 이러한 관찰 가능성을 완화할 수 있습니다. 다만 이 지연이 자체적으로 이 메커니즘의 사용 여부를 노출하지 않도록 신중하게 고려해야 합니다.

비-프로브 가능 리소스는 또한 인증되지 않은 사용자에게 발견 가능하지 않아야 합니다. 예를 들어 서버 운영자가 인증된 리소스를 인증되지 않은 사용자에게 존재하지 않는 것처럼 숨기려면, 인증되지 않은 페이지에 그 리소스로의 링크가 없도록 하고, 인증되지 않은 사용자가 해당 리소스를 발견할 수 있는 기타 외부 채널이 없도록 보장해야 합니다.

7. TLS 사용 요구사항

이 인증 방식은 TLS를 사용하는 HTTP 용도로만 정의됩니다([TLS] 포함). 여기에는 일반적으로 HTTP/2([HTTP/2]) 또는 전송 프로토콜로 TLS를 사용하는 HTTP/3([HTTP/3]) 용도의 HTTP over TLS 사용이 포함됩니다([QUIC-TLS]).

TLS 키 익스포터가 인증에 대해 안전한 것은 TLS 세션에 고유하게 바인딩되어 있을 때만이므로(참조: [RFC7627]), Concealed 인증 방식은 다음 중 하나의 속성을 요구합니다:

  • 사용 중인 TLS 버전이 1.3 이상일 것([TLS]).

  • 사용 중인 TLS 버전이 1.2이고 extended master secret extension([RFC7627])이 협상되었을 것.

클라이언트는 위의 두 속성 중 하나를 만족하지 않는 연결에서 Concealed HTTP 인증 방식을 사용해서는 안 됩니다. 서버가 위의 어떤 속성도 만족하지 않는 연결에서 이 인증 방식을 사용하는 요청을 수신하면, 서버는 해당 요청을 인증이 없는 것처럼 처리해야 합니다.

8. 보안 고려사항

Concealed HTTP 인증 방식은 서버가 클라이언트에게 nonce를 전송할 필요 없이 신선성을 보장하면서 클라이언트가 오리진 서버에 인증할 수 있게 합니다. 이는 서버가 일부 리소스에 대해 인증을 지원하거나 기대한다는 사실을 노출하지 않고도 인증된 클라이언트를 수용할 수 있도록 해줍니다. 또한 클라이언트가 평문 TLS Client Hello 확장으로 인해 인증 존재를 관찰자에게 유출하지 않도록 합니다.

위에서 설명한 신선성은 TLS 키 익스포터에 의해 제공되므로 기본 TLS 연결만큼 오래될 수 있습니다. 서버는 GOAWAY 프레임(참조: Section 5.2 of [HTTP/3])과 같은 메커니즘을 사용하여 클라이언트가 새 연결을 생성하도록 강제함으로써 더 나은 신선성을 요구할 수 있습니다.

이 문서에서 설명하는 인증 증명은 개별 HTTP 요청에 바인딩되지 않습니다; 동일한 연결에서 여러 요청에 대해 인증 증명이 사용되면 모두 동일하게 됩니다. 이는 전송 시 압축을 개선하지만, 서로 다른 보안 컨텍스트를 단일 HTTP 연결에서 다중화하는 클라이언트 구현체는 해당 컨텍스트들이 서로의 헤더 필드를 읽을 수 없도록 보장해야 합니다. 그렇지 않으면 한 컨텍스트가 다른 컨텍스트의 Authorization 헤더 필드를 재생할 수 있습니다. 현대 웹 브라우저는 이 제약을 충족합니다. 만약 공격자가 브라우저를 침해하여 다른 컨텍스트의 메모리에 접근할 수 있게 된다면, 공격자는 해당 키에도 접근할 수 있게 되어 요청에 바인딩하는 것이 실제로 큰 이득을 제공하지 못할 수 있습니다.

Concealed HTTP 인증 방식에 사용되는 인증 비대칭 키는 다른 프로토콜에서 재사용되어서는 안 됩니다. 비록 서명 데이터에 정적 접두를 추가하여 이러한 문제를 완화하려고 시도하지만(참조: 섹션 3.3), 키 재사용은 인증의 보안 보장을 약화시킬 수 있습니다.

이 방식을 제공하는 오리진은 동일한 키를 사용하는 요청들을 연계(link)할 수 있습니다. 그러나 사용된 키가 개별 오리진에 특화되어 있다면, 요청은 오리진 간에 연계되지 않습니다.

9. IANA 고려사항

9.1. HTTP 인증 방식 레지스트리

IANA는 <https://www.iana.org/assignments/http-authschemes>에 유지되는 "HTTP Authentication Schemes" 레지스트리에 다음 항목을 등록했습니다:

Authentication Scheme Name:
Concealed
Reference:
RFC 9729
Notes:
없음

9.2. TLS 키 자료 익스포터 레이블

IANA는 <https://www.iana.org/assignments/tls-parameters>에 유지되는 "TLS Exporter Labels" 레지스트리에 다음 항목을 등록했습니다:

Value:
EXPORTER-HTTP-Concealed-Authentication
DTLS-OK:
N
Recommended:
Y
Reference:
RFC 9729

9.3. HTTP 필드 이름

IANA는 <https://www.iana.org/assignments/http-fields>에 유지되는 "Hypertext Transfer Protocol (HTTP) Field Name Registry"에 다음 항목을 등록했습니다:

Field Name:
Concealed-Auth-Export
Status:
permanent
Structured Type:
Item
Reference:
RFC 9729
Comments:
없음

10. 참조

10.1. 규범적 참조

[ABNF]
... (참조 목록은 원문 그대로 유지) ...

10.2. 정보성 참조

[ED25519]
... (참조 목록은 원문 그대로 유지) ...

감사의 글

저자들은 IETF 커뮤니티의 많은 구성원들에게 감사를 표합니다. 특히 David Benjamin, Reese Enghardt, Nick Harper, Dennis Jackson, Ilari Liusvaara, François Michel, Lucas Pardue, Justin Richer, Ben Schwartz, Martin Thomson, Chris A. Wood에게 리뷰와 기여에 대해 감사드립니다. 본 문서에 설명된 메커니즘은 원래 MASQUE의 첫 번째 반복의 일부였습니다([MASQUE-ORIGINAL]).

저자 연락처

David Schinazi
Google LLC
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
EMail: dschinazi.ietf@gmail.com
David M. Oliver
Guardian Project
EMail: david@guardianproject.info
URI: https://guardianproject.info
Jonathan Hoyland
Cloudflare Inc.
EMail: jonathan.hoyland@gmail.com