요약

  • NNTP의480응답은 현재 명령이 연결의 현재 신원 상태에서 사용할 수 없다는 뜻이었으며, 나중에 그 명령을 실행하겠다는 약속이 아니었다.
  • AUTHINFO가 성공한 뒤 클라이언트는 새로 제공되는 기능(capabilities)을 확인하고 원래 명령을 다시 발행해야 했다.
  • 인증은 주체(principal)를 확립했을 뿐 보편적 권한을 부여하지 않는다. 재시도한 요청은 로컬 권한 부여 정책에 따라 여전히502를 받을 수 있었다.

요청이 두 번 나타난 이유

이를 드러내는 트랜스크립트는 몇 줄에 불과하다:

C: GROUP local.research
S: 480 Permission denied... 인증 성공...
C: GROUP local.research
S: 211 Group selected

반복된GROUP은 불필요한 절차가 아니었다. 두 요청 사이에서 서버는 이 연결에 대해 새로운 정보를 얻었다. 서버는 첫 번째 명령을 별도의 대기 공간에 보관하지 않았고, 유효한 자격 증명을 직전에 실패한 무엇이든 실행할 권한으로 해석하지도 않았다. 첫 번째 요청은480으로 끝났고, 두 번째 요청은 신원 상태가 바뀐 뒤에 시작되었다.

이 구분은 놓치기 쉽다. 인간 인터페이스는 흔히 이 연속 과정을 하나의 동작으로 만들기 때문이다. 보호된 자원을 클릭하고, 로그인하고, 자원에 도착한다. NNTP의 전송 프로토콜은 이 세 가지 별개의 행위를 그대로 노출했다. 클라이언트가 요청하고, 서버가 현재 조건에서 거부하고, 클라이언트가 신원을 확립한 뒤 다시 물을지 스스로 선택한다.

실행된 관행은 재시도를 명시적으로 만들었다

RFC 2980은 원래 프로토콜 주변에 축적된 일반적인 NNTP 확장들을 기록했다. 기존 구현 기반의AUTHINFO USER와AUTHINFO PASS명령에 대한 설명은 특히 직접적이다. 권한 부여가 필요하면 서버가480을 반환한다. 클라이언트가 사용자 이름을 제공하면 비밀번호를 위한381을 받을 수 있고, 조합이 수락되면281을 얻는다. 그 다음 단계는 서버 측의 계속 처리가 아니었다. 클라이언트는480을 받았던 명령을 재시도해야 하며, 서버는 그 새 시도를 정상적으로 처리한다.

이 문구는 의도의 소유권을 지켰다. 자격 증명은 "이 연결은 누구를 가리키는가?"라는 질문에 답했다. "클라이언트가 여전히 이전 작업을 원하는가?"라는 질문에는 답하지 않았다. 사용자는 인증 방식을 확인한 뒤 요청을 포기할 수도 있고, 클라이언트는 보호된 작업이 더 이상 관련 없음을 발견할 수도 있으며, 신원이 확립되는 동안 연결이 광고하는 기능이 바뀔 수도 있다. 재발행만이 현재 의도를 관찰 가능하게 만든다.

구식 메커니즘에는 심각한 약점이 있었다. RFC 2980은 모든 인증 정보가 평문으로 전달된다고 명시했다. 재시도 경계가 비밀을 안전하게 만들어 주지는 않았다. 다만 거부된 자원 명령을 자격 증명 교환과 분리해 놓았을 뿐이다. 자격 증명을 보호하려면 별도의 계층이 필요했다.

형식적 인증이 권한 부여를 흡수하지는 않았다

RFC 4643은 이후 USER/PASS를 표준화하고, 구식 SIMPLE 및 GENERIC 변형을 폐기 예정으로 지정했으며, NNTP용 SASL 프로파일을 정의했다. 이 문서는 거버넌스 경계로 시작한다. AUTHINFO는 사용자를 인증하며, 권한 부여는 사이트 정책의 영역에 남는다. 서버는 인증된 주체가 무엇을 할 수 있는지를 로컬 구성에 따라 판단한다.

이 분리 때문에480은 정확하면서도 제한된 의미를 갖는다. 클라이언트는 명령이나 자원을 사용하기 전에 인증 및/또는 권한 부여를 받아야 한다. 인증은 그 기능을 이용 가능하게 만들 수 있는데, 이것이 이 조건이 복구 가능한 이유다. 그러나 성공을 보장하지는 않는다. RFC 4643은 이 상태를502와 대비시킨다.502는 인증 이후에도 자원이 계속 이용 불가능하다는 것을 말할 수 있다.

이 차이는 흔한 근거 오류를 막는다. 성공한281은 서버가 이 세션에 대한 인증 교환을 수락했다는 것만 증명한다. 모든 제한된 그룹의 멤버십, 게시 권한, 피어 전송 명령 사용 권한, 어떤 기사의 저자인지, 이미 다른 곳에 저장된 콘텐츠에 대한 권한을 증명하지는 않는다.

기능 정보는 세션 안의 한 시점에 귀속되었다

AUTHINFO를 시도하기 전에, 적합한 클라이언트는CAPABILITIES를 요청해야 한다. 반환된 인증 형식과 SASL 메커니즘은 연결의 현재 상태에서 이용 가능한 것들을 기술한다. TLS가 확립된 후, 사용자가 인증한 후, 서버가 모드를 변경한 후에는 달라질 수 있다.

RFC 4643은 인증 후의 변화를 관찰 가능하게 만든다. 인증이 성공하면 서버는AUTHINFO광고를 중단해야 하고, 또 다른 AUTHINFO 시도는502로 거부해야 하며, 다른 광고된 기능을 바꿀 수 있다. 제한된 명령이나 뉴스그룹은 그 시점에만 보이게 될 수 있다. 따라서 클라이언트는 무엇을 재시도할지 결정하기 전에 새로운 기능 뷰가 필요하다.

비교를 위해 하나의 항목은 남겨진다. 서버는 인증 후에도 동일한 SASL 메커니즘 목록을 계속 광고한다. 이를 통해 클라이언트는 활성화된 다운협상 시도의 증거를 탐지할 수 있다. 이 목록은 두 번 인증하라는 초대가 아니라, 이전 협상을 대조·검증할 수 있는 안정적인 관찰 값이다.

결국 기능 탐색은 정적 제품 사양서도, 서버의 영구 속성도 아니었다. 한 연결이 한 단계에서 말하는 진술이었다. 이전 명령을 자동으로 재생하는 것은 클라이언트가 관찰한 적 없는 기능 표면을 기준으로 그 명령을 평가하는 위험을 낳았을 것이다.

인증 자체에도 상태 기계가 있었다

AUTHINFO는 서로 교환 가능한 자격 증명의 모음이 아니었다. 클라이언트는480이후에 시작하거나, 그 기능이 광고되어 있을 때 선제적으로 시작할 수 있었지만, 첫 인증 단계 이후로는38x응답이 계속을 초청할 때만 진행할 수 있었다. 다른 어떤 응답도 교환을 종료했다. 서버는 AUTHINFO 자체에480으로 답할 수 없었는데, 그렇게 되면 인증으로는 결코 충족할 수 없는 인증 요구가 만들어지기 때문이다.

구식381응답은 특히 일러준다. 일반적인 NNTP 의미에서 "같은 명령에 더 많은 데이터를 보내 계속하라"는 뜻이 아니다. 클라이언트에게 별개의AUTHINFO PASS명령을 보내라고 지시한다. RFC 4643은 이 역사적 순서를 유지하면서도, 하위 호환성이 위험을 강요하지 않는 한 강력한 암호화 계층 없이 USER/PASS를 노출해서는 안 된다고 경고했다.

성공 이후 세션에서 두 번째 인증 시도는 금지되었다. 신원 전환은 일방향 경계로 설계되었다. 소프트웨어가 다른 신원을 원한다면, 진행 중인 작업 아래의 주체를 조용히 교체하는 대신 새 연결이 필요했다.

프라이버시는 별개의 복구 가능 조건이었다

NNTP는 또 다른 문제에483을 배정했다. 연결에 적절한 프라이버시 보호가 필요하다는 것이다.RFC 4642가 이 전환을 위한 STARTTLS를 정의했다. TLS 협상 이후에는 응용 상태를 재구축하고 기능을 다시 질의해야 했다. 평문 USER/PASS 같은 메커니즘은 보호된 채널 안에서만 나타날 수 있었고, 다른 메커니즘들은 사라질 수 있었다.

이 순서는 하나의 "로그인" 개념이 왜 불충분한지 보여준다. TLS는 링크를 보호한다. AUTHINFO는 NNTP 세션에 신원을 확립한다. 사이트 정책은 특정 자원을 승인한다.GROUP을 다시 발행하는 것은 현재 의도를 표현한다. 이 단계 중 어느 것도 다음 단계의 권한을 자동으로 제공하지 않는다.

이는 보호의 한계도 규정한다. TLS는 뉴스 기사에 서명하지 않고, 저자를 확립하지 않으며, 이후 모든 중계 홉을 보호하지 않는다. AUTHINFO는 전송 계층 자격 증명을 콘텐츠 신원으로 바꾸지 않는다. 재시도된 명령은 서버의 현재 정책을 따르는 평범한 NNTP 요청으로 남는다.

거부는 근거이지 연기된 작업이 아니었다

RFC 3977은 간결한 예를 제공한다. 클라이언트가 보호된 그룹을 요청하고,480을 받고, 인증 확장을 완료한 뒤 그룹 명령을 다시 발행한다. 이것이 이 설계의 운영적 핵심이다. 응답은 첫 시도가 이전 상태에서는 요청된 기능을 얻지 못했다는 근거다.

관측 가능성을 위해 이 사건들은 별개로 남아야 한다. 운영자는 원래 명령, 그480, 제공된 인증 메커니즘, 보호 또는 비보호 채널 상태, 인증 결과, 인증 후 기능 집합, 명시적 재시도, 최종 자원 판단을 각각 볼 수 있어야 한다. 이들을 하나의 "로그인 성공" 로그 항목으로 합치면 루프, 의도치 않은 재생, 과도하게 넓은 권한 부여를 진단하는 데 필요한 근거가 파괴된다.

재시도는 문법적으로 동일할 수 있지만 맥락은 동일하지 않다. 더 늦게, 다른 주체 아래에서, 어쩌면 다른 확장 집합과 함께 도착한다. 성공할 수도, 영구적으로 실패할 수도, 다른 이유로 일시적으로 실패할 수도 있고, 클라이언트가 마음을 바꿔 생략될 수도 있다.

등록은 권한들을 분리해 두었다

IANA NNTP 매개변수 레지스트리는AUTHINFO,SASL,STARTTLS를 각기 별도의 정의 RFC를 가진 서로 다른 기능으로 등록한다. 이 공통 어휘 덕분에 구현체는 이용 가능한 전환들을 하나로 뭉개지 않고 기술할 수 있다.

등록은 계정 권리를 증명하지 않는다. 특정 서버가 지금 그 메커니즘을 제공하는지, 어떤 주체가 어떤 그룹을 읽을 수 있는지, 어떤 배포가 여전히 USER/PASS를 허용하는지에 대해서는 아무것도 말하지 않는다. 현재 연결의 기능 응답과 최종 명령 응답이 여전히 관련 근거다.

이 건축적 교훈은 NNTP보다 넓다. 시스템이 작업을 거부한 뒤 더 강한 신원을 요구할 때마다, 재생의 소유권이 누구에게 있는지 결정해야 한다. 재생을 클라이언트에 두면 갱신된 의도가 명시적으로 드러나고, 클라이언트가 변화된 조건을 관찰할 수 있다. 재생을 서버에 두면 자격 증명의 성공이 오래된 작업을 실행하는 보이지 않는 권한으로 변질될 수 있다.

NNTP는 첫 번째 모델을 택했다. 사용자는 알려진 존재가 될 수 있으면서도, 버려진 명령은 살아나지 않았다.

출처