요약

  • 상호 모드에서 클라이언트는 서버의 챌린지와 자신이 방금 선택한 값을 서명했습니다. 서버의 최종 서명은 이 두 값을 모두 커버하면서 세 번째 값을 추가했는데, 클라이언트는 이미 서버의 초기 챌린지를 알고 있었기 때문입니다.
  • 이 세 번째 값은 서버의 응답을 새로운 무작위 입력에 묶어 주었습니다. 그러나 이것이 메커니즘을 보안 채널로 바꾸지는 않습니다. RFC 3163은 무결성이나 기밀성을 제공하지 않으며, 능동적 공격이 여전히 가능하다고 명시합니다.

겉보기에만 중복된 구조

프로토콜은 같은 검증을 반복하는 것처럼 보입니다. 서버가 무작위 챌린지를 보내고, 클라이언트가 그 챌린지를 포함한 트랜스크립트에 서명하며, 이어서 서버가 그 챌린지를 포함한 트랜스크립트에 다시 서명합니다. 서버의 최종 토큰에 세 번째 값이 왜 필요한 것일까요?

RFC 3163, «ISO/IEC 9798-3 Authentication SASL Mechanism»의 답은 결정 순서에 있습니다. 핵심은 메시지 수가 아니라 각 측이 상대방의 챌린지를 언제 알게 되고 자신의 값을 언제 선택하는가입니다. 이 순서가 서명이 교환에 대해 증명할 수 있는 범위를 결정합니다.

2001년 8월에 Experimental RFC로 발표된 이 문서는 두 계열의 메커니즘을 정의합니다.9798-U-<algorithm>은 클라이언트를 서버에 대해 인증합니다.9798-M-<algorithm>은 상호 인증을 추가합니다. 클라이언트가 서버의 챌린지에 서명하고, 그다음 서버가 클라이언트의 챌린지에 서명합니다. 두 가지 모두 공개키 서명과 X.509 인증서에 기반하며, 기술된 과정에는 인증서 체인 검증이 포함됩니다.

누가 무엇을 언제 알았는가?

두 모드에서 서버는 먼저 무작위 값R_B를 생성합니다. 클라이언트는 그다음R_A를 선택합니다. 클라이언트의TokenAB는 인증서 요소들과R_A및R_B에 대한 서명을 담고, 서버 식별자를 포함할 수도 있습니다. 서버는 서명, 챌린지 일치 여부, 존재한다면 식별자를 검증합니다.

단방향 모드에서는 이 클라이언트 토큰만으로 기술된 교환이 충분합니다. 상호 모드는 서버의 응답을 추가합니다.TokenBA2는 서버 인증서와R_A,R_B, 그리고 새로운 값R_C에 대한 서명을 담습니다. 클라이언트는 인증서와 서명을 검증한 뒤, 앞선 두 값이 이전 단계와 일치하는지와 선택적인 클라이언트 식별자가 일관되는지 확인합니다.

7장이R_C의 역할을 설명합니다. 클라이언트가 서명하는 데이터에R_A를 포함하면, 서버가 메커니즘 시작 전에 데이터를 미리 골라 그 서명을 얻는 일을 막습니다. 그러나 역방향 추론은 대칭이 아닙니다. 클라이언트는R_A를 선택할 때 이미R_B를 알고 있었습니다. 서버의 서명은 클라이언트가 트랜스크립트를 검증할 수 있도록R_B를 포함해야 하지만, 그 값 하나만으로는 서버에게 같은 보호를 제공하지 않습니다. 따라서 RFC 3163은 서버가 서명한TokenBA2에R_C를 추가합니다.

이는 RFC가 제시한 정확한 근거이며, 모든 릴레이·리플레이·능동적 공격자에 대한 일반적 증명이 아닙니다. 무작위 값은 암호학적으로 강한 생성기에서 나와야 합니다. 예측 가능한 값은 메커니즘을 취약하게 만듭니다. 세 번째 값은 사양이 기술한 시간적 비대칭을 다룰 뿐, 트랜스크립트가 커버하지 않는 모든 속성을 다루지는 않습니다.

인증이 세션을 보호하지는 않는다

한계는 명시적입니다. RFC 3163은 이 메커니즘이 인증만 제공한다고 명시합니다. 이후 메시지의 무결성도 내용의 기밀성도 보장하지 않습니다. 보안 고려사항 절은 수동적 도청에만 대응하며, 세션 하이재킹을 포함한 능동적 공격이 여전히 가능하다고 명시합니다. IESG 노트는 더 나아가, 이 메커니즘은 무결성을 보장하지 않으면서 PKI의 복잡성을 감당하는 반면 TLS는 무결성 보장과 함께 그 효과를 제공할 수 있다고 말합니다.

인증서가 이 계층들을 하나로 합치지는 않습니다.authID는 인증서 서명자와 다른 경우 접근 제어에 사용되는 신원을 가리킬 수 있습니다. 체인의 수용, 메커니즘에 의한 인증, 신원 일치, 애플리케이션의 권한 부여 결정은 서로 다른 단계입니다. 유효한 서명은 어떤 키 아래의 데이터가 커버되었음을 증명할 뿐, 그것만으로 애플리케이션이 무엇을 허용해야 하는지 말해 주지 않습니다.

RFC의 IMAP 예제는 상호 교환을 보여 주지 않습니다. 이 예제는9798-U모드를 보여 주며, Base64 인코딩과+접두어가 SASL 메커니즘이 아니라 IMAP 프로필에 속한다고 명시합니다. 이 교육용 예제는 배포나 상호 운용성을 증명하지 않습니다.

Lu Heng의 Note 20은 여기서 분석의 렌즈로 작용합니다. 프로토콜의 관찰 가능한 검증과 신원 또는 권위에 대한 더 넓은 주장을 구분하는 것입니다. 챌린지 값과 서명은 트랜스크립트에 속합니다. 채널 보호와 애플리케이션 권한은 다른 통제에 속합니다. 이러한 해석은 RFC 3163의 저자들에게 귀속되지 않습니다.

출처

  1. RFC 3163 — ISO/IEC 9798-3 Authentication SASL Mechanism
  2. RFC 3163에 대한 RFC 편집기 공지
  3. RFC 2222 — Simple Authentication and Security Layer
  4. RFC 4422 — Simple Authentication and Security Layer (SASL)
  5. RFC 2459 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile
  6. RFC 5280 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile
  7. RFC 2630 — Cryptographic Message Syntax
  8. RFC 8017 — PKCS #1: RSA Cryptography Specifications
  9. RFC 2060 — Internet Message Access Protocol, Version 4rev1
  10. RFC 2195 — IMAP/POP AUTHorize Extension for Simple Challenge/Response
  11. IANA SASL 메커니즘 레지스트리
  12. NIST FIPS PUB 196 — 주체 Authentication Using Public Key Cryptography
  13. Lu Heng, Note 20 — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile