요약

  • RFC 2412의 세 메시지 OAKLEY 예제에서는 서명을 검증하고 KEYID를 인증됨으로 표시하는 동안에도 Diffie–Hellman 공유 값이 여전히uncomputed(미계산)로 표시될 수 있었습니다.
  • 따라서 이 RFC는 통신의 증명과 키 계산을 구분했습니다. 어느 하나만으로도 올바른 키 바인딩, 양측 보안 연결 설치, 보호된 트래픽 또는 애플리케이션 결과를 증명하지 못했습니다.

RFC 2412에는authenticated(인증됨)라는 단어에서 상당한 안도감을 걷어내는 문장이 있습니다.

Aggressive 모드 OAKLEY 예제에서 양 당사자는 식별자, nonce, 알고리즘 선택, Diffie–Hellman 반쪽 키를 교환합니다. 각 당사자는 관련 트랜스크립트에 서명합니다. 서명은 "통신의 증명", 즉 기록으로 남겨 나중에 제3자에게 제시할 수 있는 것이 될 수 있습니다. 세 개의 메시지로 교환을 완료할 수 있습니다.

그런 다음 이 RFC는, 그룹 지수가 암시하는 키 자료는 교환 완료에 필요하지 않다고 말합니다.

구현체는 자신의 비밀 지수와 피어의 공개 지수를 보존하고, 키 자료를uncomputed로 표시한 뒤 나중에 공유 값을 계산할 수 있습니다. 처리 개요에서 개시자는 마지막 응답을 보낸 후까지(g^y)^x계산을 미룰 수 있습니다. 응답자의 서명을 검증하고, 선택된 상태를 저장하고, KEYID를 인증됨으로 표시합니다. 응답자는 최종 서명을 검증한 뒤 키를 인증됨으로 표시하며,계산해야(should)g^xy를 계산해 KEYID에 연관시킵니다.

교환은 인증 경계를 넘었습니다. 공유 비밀은 아직 계산 경계를 넘지 않았을 수 있습니다.

이것은 구현 속에 숨겨진 모순이 아니었습니다. 프로토콜이 기술한 타이밍 선택이었습니다. OAKLEY는 식별자와 광고된 지수들의 바인딩을 인증했을 뿐, 인증 자체가 결과로 나온 Diffie–Hellman 값으로 암호화를 수행하도록 요구하지 않았습니다. RFC 2412는 예제보다 앞서 일반 규칙을 명시합니다. 양 당사자는 인증 전에 공유 지수를 계산할 필요가 없습니다.

이 구분은 조각들을 정확히 이름 붙이기 전까지는 학문적인 것처럼 들릴 수 있습니다.

쿠키들이 KEYID, 즉 키 자료의 재사용 가능한 이름을 이룹니다. 이 RFC는 그 쿠키들에 주소 검증과 안티-클로깅이라는 두 번째, 더 약한 역할을 부여합니다. KEYID가 이름 짓는 비밀 자료는sKEYID이며, 예제에서는 nonce,g^xy, 쿠키로부터 파생됩니다. 따라서 이름은 그것이 이름 짓는 자료가 계산되기 전에 존재할 수 있습니다. 인증된 이름은 그 계산보다 먼저 존재할 수 있습니다. 서명된 트랜스크립트는 두 식별자가 특정 교환에 참여했음을 증명하되, 어느 쪽 엔드포인트도 이미 사용 가능한 트래픽 보호 상태를 설치했음을 증명하지 않습니다.

이름과 증거와 자료는 서로 다른 계층을 차지합니다.

이것이 중요한 이유는 운영 시스템이 상태를 압축하려 하기 때문입니다. 관리 화면에는 논문이 아니라 초록불이 들어갈 자리가 있습니다. 로그는 authenticated, established, ready 같은 동사 하나를 원합니다. 애플리케이션은 보내도 되는지 알고 싶어 합니다. 구현체가 가장 이르게 참이 되는 단어를 골라 최종 진실로 제시하면, 로컬 최적화를 원격 약속으로 바꿔버립니다.

OAKLEY의 지연은 완전히 합리적일 수 있었습니다. 모듈러 지수 연산은 비쌌으며, 특히 1990년대 후반에 그랬습니다. 마지막 메시지의 중요 경로에서 이를 빼면 체감 핸드셰이크 지연을 줄일 수 있었습니다. 피어는 여전히 동일한 서명된 필드를 받았습니다. 와이어 트랜스크립트 어디에도 계산이 최종 전송 직전에 일어났는지 직후에 일어났는지는 드러나지 않았습니다.

그러나 절약된 작업은 절약된 의무가 되었습니다. 구현체는 올바른 비밀 지수, 피어의 공개 값, 선택된 그룹, 양쪽 쿠키, 양쪽 nonce, 식별자, 선택된 알고리즘을 보존해야 했습니다. 받은 값을 검증하고, 지수 연산을 수행하고, 올바른 자료를 파생하여 올바른 KEYID에 바인딩해야 했습니다. 프로세스가 죽거나, 상태가 만료되거나, 핸들이 재사용되거나, 상위 계층이 "authenticated"를 "ready"로 오해하면, 트랜스크립트는 완벽하게 해석 가능한 채 남고 사용 가능한 비밀은 결코 나타나지 않을 수 있었습니다.

이것이 바로 좋은 감사 추적이 서명된 메시지를 계산 영수증의 대용품으로 사용할 수 없는 이유입니다.

트랜스크립트 영수증은 기대한 서명이 기대한 필드 위에서 검증되었음을 말합니다. 인증 상태 영수증은 로컬 소프트웨어가 이름 붙은 교환을 승격시켰음을 말합니다. 검증 영수증은 피어의 그룹 원소가 적용되는 프로토콜 세대가 요구하는 검사를 통과했음을 말합니다. 계산 영수증은 공유 값과 파생 자료가 실제로 계산되었음을 말합니다. 바인딩 영수증은 그 바이트들을 의도한 피어 식별자, 알고리즘, KEYID와 연결합니다. 설치 영수증은 올바른 런타임 보안 연결이 그것들을 받았음을 보여줍니다. 패킷 영수증은 보호된 트래픽이 수용되었음을 보여줍니다. 결과 영수증은 보안 기계장치가 지원하기 위해 만들어진 서비스에 귀속됩니다.

각 영수증은 다음 영수증이 여전히 미지인 상태에서 참일 수 있습니다.

응답자 측 서술은 이 경계를 특히 선명하게 만듭니다. 유효한 최종 서명 이후에 키를 인증됨으로 표시하고, "계산해야(should compute)"g^xy를 계산해 KEYID에 연관시킵니다. 이 순서를 양측이 동일한 상태를 설치했다는 주장으로 부풀려서는 안 됩니다. RFC 2412는 운영 텔레메트리 스키마, 크래시 복구 기록 또는 양측 설치 확인을 기술하지 않습니다. 또한 어떤 제품이 지연 계산을 사용했는지, 얼마나 자주 사용했는지, 실제 장애가 발생했는지는 보고하지 않습니다. 역사는 권한과 상태 순서에 있으며, 발명된 배포 이야기 속에 있지 않습니다.

이후의 계산이 안전한지는 그 입력에도 의존했습니다. RFC 2412는 구현체가 특정 퇴화 모듈러 지수 값을 제공하거나 수용하지 말도록 권고했고, nonce, 쿠키, 지수에 대한 강한 무작위성을 요구했습니다. 공표된 정오표는 안전 소수와 소피 제르맹 소수에 관한 용어를 바로잡지만, 지연 계산 메커니즘 자체는 바꾸지 않습니다.

이후의 표준들은 검증 경계를 더 명시적으로 만들었습니다. RFC 6989는 IKEv2의 Diffie–Hellman 공개 키 검증을 다루며 작은 부분군을 가진 그룹을 포함하고, 무효한 Key Exchange 페이로드는 IKE SA 생성에 사용하지 말고 거부하도록 요구했습니다. 이 문서는 OAKLEY 또는 IKEv1 구현체가 무엇을 검사했는지 소급해서 증명하지 않습니다. 대신 증거의 순서를 강화합니다. 값을 받았다는 것은 그것으로부터 파생할 권한이 아니며, 파싱 성공은 검증 성공이 아닙니다.

OAKLEY의 아이디어는 고립되지 않았습니다. RFC 2409는 ISAKMP와 OAKLEY 자료를 IKEv1으로 합쳤습니다. 그 Aggressive Mode 역시 마지막 페이로드가 보호되지 않은 채 남아 지수 연산을 교환 완료까지 미룰 수 있게 했습니다. 그럼에도 그 키 스케줄은 실제 Diffie–Hellman 공유 값에 의존했습니다. 교환이 비싼 계산이 끝나기 전에 와이어를 떠날 수 있어도, 결과 보호는 완료 라벨로부터 제조될 수 없습니다.

이후의 IKEv2 계열은 기계장치를 재편했습니다. RFC 4306, RFC 5996, 그 다음 RFC 7296이 이전 설계의 세대들을 대체했습니다. RFC 7296은 nonce와 임시 Diffie–Hellman 공유 비밀로부터SKEYSEED를 파생한 뒤, 파생·인증·암호화를 위한 서로 다른 키로 확장합니다. 또한 자체적으로 유용한 상태 구분을 보존합니다. 인증은 IKE SA를 수립할 수 있지만 Child SA 또는 구성 요청은 여전히 실패할 수 있습니다.

이것은 RFC 2412와 동일한 상태 기계가 아니며, 그렇게 제시되어서도 안 됩니다. 프로토콜 진화가 보안 제어 상태와 그것이 가능하게 하는 이후 상태를 계속 분리해왔다는 증거입니다. 인증은 한 계층에서 완성될 수 있으며, 그 아래 데이터 경로는 여전히 부재할 수 있습니다.

문서의 역사 역시 공표를 배포로 전환하는 것에 대한 경고입니다. RFC 2412는 Informational이었습니다. 상태 고지는 인터넷 표준을 명시하지 않는다고 말했습니다. RFC 2409는 표준 트랙이었고, IKEv2는 이후 IKEv1을 폐기했으며, 알고리즘 요구사항이 바뀌었고, RFC 9395가 결국 IKEv1과 여러 구식 알고리즘을 폐지했습니다. 그러나 그 문서적 행위들 어느 것도 소급해서 모든 기기에 들어가 코드를 지우지는 않았습니다. 현재의 지침과 역사적 행동은 서로 다른 사실입니다. 인증된 트랜스크립트와 계산된 비밀이 서로 다른 사실인 것처럼.

바로 이 지점에서 Lu Heng의 Running-Code Primacy가 유용한 분석적 규율을 제공합니다. 페이지 위의—또는 대시보드 속의—상태 단어는 기계 안에서 검사 가능한 상태 전이를 대신할 수 없습니다. 현실 계층은 기관이 가장 편리한 것을 고르는 경쟁하는 이야기가 아닙니다. 그것들은 의존적인 사실들입니다. 트랜스크립트가 존재합니다. 서명이 검증됩니다. 공개 값이 검사를 통과합니다. 비밀이 계산됩니다. 키가 바인딩됩니다. SA가 설치됩니다. 패킷이 통과합니다. 애플리케이션이 성공합니다.

Minimum Initial Specification은 그 논증의 건설적인 절반을 공급합니다. 독립 구현체들에게는 공통의 트랜스크립트, 공통의 파생 규칙, 와이어 위 값들의 공통 의미가 필요했습니다. 최종 전송 전에 어느 CPU 명령을 실행해야 하는지 정확히 지시하는 보편적 스케줄러까지는 반드시 필요하지 않았습니다. RFC 2412는 공유된 프로토콜을 유지하면서 로컬 타이밍 결정을 허용했습니다.

그러나 로컬 자유가 책임을 지우지는 않습니다. 지연을 선택한 구현자는 인증된 상태와 계산된 자료 사이의 숨은 구간을 지배합니다. 따라서 그 구현자는 그 구간을 정확히 노출하고, 입력을 안전하게 보존하고, 더 강한 의미를 더 약한 영수증에 빌려주지 않으면서 복구하거나 실패할 의무를 집니다. 장애를 떠안는 애플리케이션은 초록색 "authenticated" 배지에서 그 사실들을 추론하도록 내버려져서는 안 됩니다.

OAKLEY의uncomputed상태가 남기는 지속적 교훈은 인증이 공허했다는 것이 아닙니다. 서명은 중요한 무언가를 증명했습니다. 이름 붙은 당사자들을 특정 교환에 바인딩했습니다. 교훈은, 강한 증거가 다른 사건을 증명하도록 요구받을 때 위험해진다는 것입니다.

교환은 인증되었습니다. 공유 비밀은 여전히 계산되어야 했습니다. 보안 연결은 여전히 바인딩되고 설치되어야 했습니다. 패킷은 여전히 통과해야 했습니다. 서비스는 여전히 작동해야 했습니다.

프로토콜의 역사는 그 모든 동사들을 하나하나 보존할 때 비로소 유용해집니다.

출처