요약

  • RFC 7616은nc를 클라이언트가 해당 요청에 담긴 논스로 전송했다고 주장하는 요청 수로 정의하며, 대응되는 상태를 보존하는 서버는 재사용을 탐지할 수 있다.
  • 다이제스트 계산은 그 카운트를 자격 증명에서 파생된 재료와 선택된 HTTP 요소에 묶는다. 그러나 이는 카운트를 전역 요청 ID, 인가 부여 또는 애플리케이션 실행 기록으로 바꾸지 않는다.
  • 결과가 수반되는 작업을 수행하는 시스템은 별도의 작업 식별자와 영속 결과 조회를 필요로 한다. 새로운 유효한 다이제스트 교환은 재시도를 인증할 수 있지만, 이전 시도가 아무 효과가 없었음을 증명하지는 않는다.

00000001이 주는 안심감의 정체

운영 콘솔은 순서 있는 숫자에 끌린다. 증가하는 값은 순서를 약속하는 듯 보이고, 순서는 다시 이력을 약속하는 듯 보인다. HTTP 다이제스트에서 이 유사성은 특히 설득력 있는데, 그 값이 인증 계산 안에 들어 있기 때문이다. 클라이언트는00000001에서 시작해 논스 카운트를 증가시키고, 서버 논스와 자신의 클라이언트 논스 옆에 그 값을 보낸다. 같은 카운트가 다시 나타나면 서버는 재전송을 인식할 수 있다—두 값을 비교하는 데 필요한 상태를 보존하고 있었다면.

그것은 실제 보안 가치다. 동시에 범위가 한정된 진술이기도 하다.

RFC 7616은nc를 클라이언트가 해당 논스로 전송한 요청 수, 현재 요청을 포함해, 세고 있다고 규정한다. 이 정의는 서버가 그 요청들을 수락했다거나, 모두 하나의 프로세스에 도달했거나, 애플리케이션이 같은 순서로 상태를 변경했다고 말하지 않는다. 또한 그 카운트를 그 논스 밖에서 고유하게 만들지도 않는다. 서버는 논스를 교체할 수 있고, 다른 클라이언트는 자신만의 카운트를 시작할 수 있으며, 다른 보호 공간은 무관한 챌린지를 사용할 수 있다. 눈에 보이는 순서가 재시작되는 이유는 비즈니스 이력이 지워져서가 아니라 프로토콜 맥락이 바뀌었기 때문이다.

따라서 이 필드는 재전송 질문에 답한다: 이 카운트가 인증자가 이 논스를 지닌 교환과 결합한 상태 안에서 이미 나타난 적이 있는가? 거래 질문에는 답하지 않는다: 그 이후에 어떤 영속 작업이, 있다면, 수행되었는가?

상대편을 필요로 하는 카운터

이 카운트는 서버가 자신의 사본을 보관할 수 있기 때문에만 의미를 지닌다. RFC 7616은 재전송 탐지를 그 보관된 상태와 명시적으로 연결한다. 다이제스트 계산에서 떼어낸 클라이언트 제공nc는 스스로 인증되는 증거가 아니며, 로그 속 여덟 자릿수 값만으로 서버의 논스 정책을 재구성할 수 없다.

그 정책은 의도적으로 구현 의존적이다. 서버는 불투명한 논스를 만들어 시간, 클라이언트, 자원, 사용 횟수 또는 다른 조건으로 그 범위를 제한할 수 있다. 일회용 논스를 발급하고 그 논스가 소진되었음을 기억해 두 번째 사용을 거부할 수도 있다. 이는 강력한 즉시 재전송 저항성을 제공하지만 상태 비용이 들고 파이프라인된 요청을 방해한다. 더 오래 사는 논스를nc와 결합하면 여러 인증된 요청이 하나의 챌린지를 공유하도록 하면서 재전송 방어의 상당 부분을 유지한다.

이 트레이드오프가 그 숫자를 보편적 원장으로 승격할 수 없는 이유를 설명한다. 규격을 준수하는 두 서비스는 논스 수명과 보관 상태에 서로 다른 경계를 둘 수 있다. 클러스터는 재전송 상태를 어떻게 공유하거나 분할할지 결정해야 한다. 리셋, 페일오버 또는 논스 교체는 인증자가 기억하는 것을 바꿀 수 있으며, 그렇다고 애플리케이션 데이터베이스에 대해 아무 말도 하지 않는다. 프로토콜은 필드와 검사를 제공하고, 배포가 그 상태의 관리 책임을 제공한다.

다이제스트가 실제로 묶는 것

quality-of-protection가 활성화되면 응답 값은 비밀번호에서 파생된 재료, 서버 논스,nc, 클라이언트 논스, 선택된 qop 토큰, A2의 해시로부터 계산된다.qop=auth의 경우 A2는 HTTP 메서드와 요청 URI로 구성된다.qop=auth-int의 경우 엔티티 본문의 해시가 추가된다. 그 결과는 스킴의 보호 공간 내에서 비밀 재료에 대한 지식을 증명하면서, 선택된 재전송 및 변조 시도가 탐지 가능하도록 만든다.

이 경계는 두 번 중요하다. 첫째, 대부분의 HTTP 헤더 필드는auth-int아래에서도 다루어지지 않는다; RFC 7616은 중간자가 이들을 변조할 수 있다고 경고한다. 둘째, 인증은 애플리케이션 인가가 아니다. 올바른 다이제스트는 클레임자가 설정된 비밀을 안다는 것을 입증할 수 있지만, 그 클레임자가 자금을 이체하거나 키를 교체하거나 레코드를 삭제할 수 있는지는 결정하지 않는다. 이런 결정은 애플리케이션 정책과 현재 상태에 달려 있다.

Rifaat Shekh-Yusef는 그 IETF 합의 업데이트의 명명된 편집자이자 공동 저자 집단의 일원이지, 그 안의 모든 메커니즘의 발명자가 아니다. RFC 2617에 이미 논스 카운트가 있었다. RFC 7616은 그 설계를 보존하면서 SHA-256과 SHA-512/256을 추가하고, qop 사용을 현재 요구 사항의 일부로 만들었으며, 사용자명 해싱을 지원하고 보안 분석을 정교화했다. 더 강한 다이제스트 알고리즘은 지정된 인증 계산을 개선한다. 그러나 그 RFC는 알고리즘 민첩성이 인간이 기억하기 쉬운 비밀번호를 사전 공격에서 구해주지는 않는다고 똑같이 명확하다.

응답은 영수증 없이 인증할 수 있다

다이제스트에는 응답 측 메커니즘도 있다.Authentication-Info는rspauth를 담을 수 있고, 응답은 그것이 대응하는 클라이언트 논스와 논스 카운트를 반복한다. 이는 상호 인증을 지원한다: 서버는 사용자 비밀에 대한 지식을 입증할 수 있고,auth-int는 제한된 응답 무결성을 제공할 수 있다.

그럼에도 이것은 애플리케이션 영수증이 아니다. 되돌려진nc는 인증 응답을 요청과 연관시킨다. 그것은 결제 식별자, 작업 식별자, 커밋 시퀀스, 롤백 상태 또는 조회 가능한 결과를 정의하지 않는다. 서버는 요청을 큐에 넘기기 전에 인증할 수 있다. 작업자는 HTTP 응답이 사라진 뒤 커밋할 수 있다. 그러면 클라이언트는 새로운 챌린지-응답 교환을 열어 유효한 재시도를 보낼 수 있다. 두 다이제스트 교환이 모두 올바른 가운데 비즈니스 동작은 두 번 일어날 수 있다.

이것은 논스 카운트의 결함이 아니다. 그것은 주변 자동화의 범주 오류이다. 자격 증명의 재전송과 효과의 반복은 겹치지만, 같은 제어 표면이 아니다.

하나의 녹색불 대신 다섯 개의 기록

결과가 수반되는 서비스는 최소한 다섯 가지 사실을 분리할 수 있어야 한다. 인증 성공 여부; 재전송 정책이 논스 맥락을 수용했는지; 애플리케이션 인가가 동작을 허용했는지; 그 동작이 어떤 영속 작업 식별자를 지니는지; 그리고 어떤 사후조건이 커밋되었는지. 일부 시스템은 응답 전달 기록도 필요로 한다. 완료된 작업과 관측된 응답은 어긋날 수 있기 때문이다.

애플리케이션 수준의 멱등성 키는 재시도를 하나의 의도된 작업에 묶는 한 방법이다. 그 식별자로 잠긴 결과 엔드포인트는 또 다른 방법이다. 어느 쪽이든 클라이언트가 타임아웃 뒤에 새로운 인증 성공에서 추측하는 대신 무슨 일이 있었는지 물을 수 있게 해준다. RFC 7616은 어느 쪽도 정의하지 않으므로, 이는nc의 창의적 해석이 아니라 서비스 설계, 영속성, 운영 거버넌스에 속한다.

그러므로 훈련된 독해는 너그럽고 엄격하다. 논스 카운트가 제공할 수 있는 재전송 증거로 사용하라. 그 카운트에 의미를 부여하는 서버 상태를 보호하라. 제한된 무결성 경계가 맞는 곳에서auth-int를 사용하고, 다이제스트는 기밀성을 제공하지 않으므로 HTTPS를 사용하라. 그리고 거기서 멈추라. 인증 카운터가 한 번도 관측하지 않은 애플리케이션 상태에 대해 증언하게 하지 마라.

출처