요약

  • RFC 2408은 ISAKMP에 안티클로깅 쿠키 쌍, 페이즈 2 메시지 ID, 교환 유형, 페이로드 체인을 위한 별개의 필드를 두었다. 각각은 서로 다른 범위의 상태를 유지했으며, 어느 것도 자격 증명이 아니었다.
  • 완전한 결과가 나오려면 여전히 강한 인증, 일치하는 로컬 정책, 수용된 제안, SA 설치, 패킷 사용, 그리고 독립적으로 관찰된 서비스 결과가 필요했다.CONNECTED나 Delete 메시지조차 이름이 암시하는 것보다 더 좁은 주장만을 담고 있었다.

첫 ISAKMP 패킷에는 개시자 쿠키가 담겨 있고, 응답자 쿠키와 메시지 ID가 나중에 채워질 자리에는 0이 들어 있었다. 호스트는 이것만으로 범위가 제한된 대화를 시작할 수 있었다. 그러나 누가 말했는지를 알 수는 없었다.

이 차이는 처음 8옥텟에 있었다. RFC 2408은 쿠키를 안티클로깅 토큰이라 불렀다. 즉, 서버가 비용이 큰 공개키 연산을 수행하기 전에 서비스 거부 공격의 비용을 높이기 위한 값싼 값이었다. 토큰을 발급한 호스트는 엔드포인트 정보, 로컬 비밀값, 시각을 사용해 자신의 토큰을 재생성하거나 검증할 수 있었다. 외부인이 호스트가 수용할 값을 만들어내는 것은 불가능해야 했다.

이런 성질들은 유용했다. 동시에 그것들은 의도적으로 신원보다 작은 범위만을 다루었다. 주소와 UDP 포트는 쿠키의 입력이 될 수 있지만, 그것으로 인증된 주체가 되는 것은 아니었다. 로컬 비밀 해시는 수신자가 토큰을 발급했다는 사실을 증명할 수 있으나, 송신자가 지속적인 이름·인증서·계정을 통제한다는 것은 증명하지 못했다. 시간에 따라 변하는 정보는 경로가 계속 안정적임을 보여주지 않고도 재사용을 줄일 수 있었다.

RFC 2408은 이 한계를 이례적으로 솔직하게 밝혔다. 서비스 거부 공격에 대한 절대적 보호는 불가능하다. 위조된 패킷 홍수에 대해 서버는 여전히 상태를 할당할 수 있으므로, 구현체는 쓰레기 상태 수집과 공격적인 메모리 관리가 필요했다. 그럴듯해 보이는 교환 표시가 자원 고갈 문제를 해결된 것으로 만들지는 않았다.

쿠키의 두 번째 역할은 이 첫 방어 뒤에 나왔다. ISAKMP는 개시자 쿠키와 응답자 쿠키 쌍으로 ISAKMP 보안 결합을 식별했다. 시작 시점에는 개시자만 하나를 제공했다. 응답이 두 개를 모두 제공했다. 페이즈 1이 끝난 뒤에는 이후의 통신이 쿠키 쌍을 함께 실었다. 이 쌍은 보호된 협상 맥락을 선택했다.

“맥락을 선택했다”는 것은 “상대를 식별했다”는 뜻이 아니다. RFC 2408은 별도로 강한 인증을 요구했다. 인증 없이는 어떤 주체의 식별 정보도 신뢰할 수 없다고 경고했다. 이 프레임워크는 다양한 인증 메커니즘과 키 교환을 지원하도록 의도적으로 설계되었다. 쿠키 필드는 그런 방법들이 자기 역할을 마치기 전에 이미 존재해 있었다.

이 순서는 감사 관점에서 중요하다. 패킷 추적은 여러 패킷에 걸친 안정적인 쿠키 쌍을 보여줄 수 있다. 수신자가 그 쌍을 인식했다는 사실도 보여줄 수 있다. 그러나 인증 기록과 자격 증명 판단 없이는, 구현체가 그 상태에 어느 주체를 결합했는지 확립할 수 없다. 상관관계는 귀속이 아니다.

메시지 ID는 또 하나의 경계를 그었다. RFC 2408은 이 4옥텟 값을 페이즈 2 동안의 프로토콜 상태에 할당했다. 개시자가 생성하며, 하나의 ISAKMP SA 아래에서 동시에 진행되는 페이즈 2 협상들은 서로 다른 값을 갖는 것이 기대되었다. 페이즈 1에서는 쿠키 쌍이 이미 ISAKMP SA를 식별하므로 이 값은 0이어야 했다.

이것은 중복된 일련번호가 아니었다. 하나의 보호된 관계가 여러 진행 중인 협상을 서로의 응답, 제안, 통지를 혼란 없이 운반할 수 있게 해 주었다. 쿠키는 부모 상태를 이름 짓고, 메시지 ID는 하나의 자식 협상을 이름 지으며, 제안 SPI는 협상 중인 보안 결합을 이름 지었다. 나중에 ESP나 AH 패킷은 자체 프로토콜 헤더의 SPI를 사용해 설치된 런타임 상태를 선택했다.

따라서 네 개의 식별자는 네 개의 질문에 각각 답했다. 어느 ISAKMP SA인가? 어느 페이즈 2 협상인가? 어느 제안된 프로토콜 SA인가? 어느 실행 중인 패킷 처리 SA인가? 이들을 “터널 ID” 하나로 뭉개면, 프로토콜이 만들어낸 정확히 그 구분들이 사라진다.

고정 헤더의 나머지 부분은 파싱 계약을 이루었다. 교환 유형이 문법을 고르고, Next Payload가 첫 페이로드를 가리키며, 모든 일반 페이로드 헤더가 다음 페이로드로 연결되었다. 버전, 플래그, 전체 길이가 해석을 제약했다. 수신자는 페이로드 체인을 순회하기 전에 정해진 순서대로 이 필드들을 검증했다.

이 체인에는 SA, 제안, 트랜스폼, 키 교환, 식별 정보, 인증서, 인증서 요청, 해시, 서명, 논스, 통지, 삭제, 벤더 식별자가 담길 수 있었다. 모듈식 설계 덕분에 서로 다른 교환이 공유 컴포넌트로 서로 다른 대화를 조립할 수 있었다. 동시에 검증을 국소적이고 점진적으로 만들었다. 쿠키 검사를 통과했다고 버전 검사를 통과하는 것은 아니었다. 버전 검사를 통과했다고 서명이 인증되는 것은 아니었다. 마지막 페이로드를 파싱했다고 SA가 설치되는 것도 아니었다.

RFC 2408의 오류 경로는 이러한 전환들의 소유권을 드러낸다. 유효하지 않은 쿠키, 페이로드 유형, 버전, 교환 유형, 플래그, 메시지 ID는 폐기를 유발했다. 이벤트 기록은 선택 사항이었다. Informational 통지를 보내는 것도 종종 선택 사항이었다. 응답은 로컬 보안 정책이 정했다. 표준은 오류를 명명하고, 호스트가 결과와 증거의 보존 여부를 결정했다.

그렇기 때문에INVALID-COOKIE통지가 담긴 패킷 캡처가 전체 이야기는 아니다. 그것은 어느 한 구현체가 검증 실패를 보고했다는 사실은 보여줄 수 있다. 그러나 어느 로컬 규칙이 발동했는지, 상대가 통지를 받았는지, 이벤트가 지속적인 로그에 들어갔는지, 자원 공격이 끝났는지는 증명하지 않는다. 통지는 한 계층에서 얻은 관찰일 뿐이다.

ISAKMP는 협상을 두 페이즈로 나누었다. 페이즈 1은 이후의 관리 활동을 보호할 수 있는 ISAKMP SA를 수립했다. 페이즈 2는 그 채널을 사용해 다른 프로토콜을 위한 SA를 수립했다. 초기 비용은 여러 이후 협상에 걸쳐 상쇄될 수 있었고, 오류나 삭제 메시지는 처음부터 다시 인증하지 않고 보호된 경로를 사용할 수 있었다.

두 페이즈는 서로 다른 주체를 인증할 수도 있었다. RFC 2408은 페이즈 1이 서버나 호스트를 인증하는 반면 페이즈 2는 사용자나 응용프로그램과 관련될 수 있다고 언급했다. 하나의 상대 이름을 모든 자식 SA에 붙이는 대시보드는 이 주체의 변화를 지워버릴 위험이 있었다. 쿠키 쌍은 부모 맥락의 위치를 알려줬을 뿐, 그 아래에서 어느 식별 정보를 정책이 승인해야 하는지를 결정하지 않았다.

제안 통제권도 여전히 로컬에 있었다. 개시자는 단일 선택만 제시해 통제를 조이거나, 선호 순서에 따라 여러 제안을 보낼 수 있었다. 대안을 제시한 뒤에는 응답자가 자신의 보안 정책에 따라 선택했다. 잘 형성된 제안은 선택지 집합이지 명령이 아니었다. 돌아온 선택은 협상된 결정이지, 커널이 그 결과 상태를 수용했다는 증거가 아니었다.

커밋 비트는 협상된 선택과 준비 완료 사이의 구분이 운영상 위험했기 때문에 존재했다. 어느 쪽이든 보호된 Informational 교환이CONNECTED를 전달할 때까지 상대에게 기다려 달라고 요청할 수 있었다. 그 메시지는 페이즈 2 메시지 ID를 재사용해 올바른 협상에 붙을 수 있었다. 이것은 동기화 격차를 좁혔다.

그러나 격차를 없애지는 않았다. RFC 2408은 마지막 메시지가 손실될 수 있음을 인정하고 복구 동작을 표준화하지 않았다. 기다리는 상대는 검증 가능한 보호된 트래픽에서 성공을 추론하거나, 마지막 협상 메시지를 재전송할 수 있었다. 구현체는 확신이 들 때까지 마지막 메시지를 보관할 수도 있었다. 따라서CONNECTED는 오류가 가능한 전송 과정에서의 한 영수증이지, 모든 하류 구성 요소가 준비되었다는 절대적 선언이 아니었다.

Delete도 마찬가지로 정밀한 의미를 지녔다. 송신자는 보호된 Informational 교환을 통해 자기 데이터베이스에서 명명된 SA를 제거했다는 사실을 알렸다. RFC 2408은 이것이 수신자에게 자기 사본을 삭제하라는 요청이 아니라 고지 사항임을 명시적으로 밝혔다. 응답자가 이를 확인 응답할 것으로 기대되지 않았다. 그다음에 어떤 일이 일어나는지는 로컬 정책이 정했다.

이 문구는 흔한 포렌식 오류를 막는다. Delete 페이로드를 본다고 해서 수신자가 그것을 처리했다거나, 로컬 정리가 성공했다는 증거는 되지 않는다. 보호 검증 후에도 그것은 송신자 측 상태에 대한 송신자의 진술을 기록할 뿐이다. 완전한 삭제 영수증에는 인증된 메시지, 수신자 판단, 로컬 데이터베이스 변경, 영향받은 셀렉터, 이후 기각된 트래픽, 그리고 발생한 복구 조치가 모두 필요하다.

같은 규율이 암호화 플래그에도 적용된다. 플래그가 설정되었다는 것은 헤더 뒤의 페이로드가 선택된 ISAKMP SA의 알고리즘으로 암호화되었다는 뜻이었다. 헤더는 여전히 상태 선택자였다. 플래그는 알고리즘의 적합성, 자격 증명의 유효성, 정책 승인, 응용프로그램 성공을 확립하지 않았다. 이미 선택된 상태 아래에서 메시지 영역이 어떤 처리를 받았는지를 서술한 것뿐이었다.

이렇게 RFC 2408의 아키텍처는 영수증의 사다리를 만들었다. 쿠키 발급과 검증은 자원 및 재사용 주장의 범위를 정했다. 쿠키 쌍은 ISAKMP SA를 연결하고, 메시지 ID는 페이즈 2 작업을 연결했다. 교환 유형과 Next Payload는 파싱을 이끌었다. 인증은 상대를 결합했다. DOI 의미론이 제안을 해석했다. 로컬 정책이 선택했다. 키 관리가 설치했다. 보안 프로토콜이 패킷을 처리했다. 응용프로그램이 결과를 경험했다—혹은 경험하지 못했다.

Lu Heng의 현실 계층 렌즈는 이 사다리를 보이게 한다. 헤더 안의 기호는 메시지 계층에 속한다. 파싱의 성공은 구현 계층에 속한다. 검증된 서명이나 MAC은 인증 맥락에 속한다. 정책 일치는 권한 체계에 속한다. 설치된 SA는 실행 상태에 속한다. 전달되고 유용한 작업은 서비스에 속한다. UI가 하나의 초록 배지를 쓴다는 이유만으로 한 계층이 다른 계층의 증명을 빌려올 수는 없다.

대행(agency) 문제도 똑같이 구체적이다. 프로토콜 레지스트리는 번호를 소유하고, 프레임워크 저자는 문법을 소유한다. 자격 증명 관리자는 신원 결합을 소유하고, 보안 팀은 정책을 소유한다. 데몬은 협상을, 커널은 패킷 상태를, 응용프로그램은 결과를 소유한다. 데몬이 “연결됨”을 보고하고 조직이 그것을 모든 후속 에이전트의 증거로 받아들이면, 가장 중대한 인계 지점에서 책임이 사라진다.

실행 코드 우선성이 처방을 제공한다. 쿠키 쌍과 메시지 ID를 그대로 보존하되, 그것들을 인증 결과, 자격 증명 지문, 정책 버전, 제안 선택, 커널 설치 영수증, 런타임 SPI, 셀렉터, 카운터, 패킷 판정, 응용프로그램 관찰과 결합하라. 원래 필드들은 자신이 담은 것 이상을 증명하라고 요구받지 않기에야말로 가치가 있는 것이다.

RFC 2408은 1998년 11월에 발표되었다. RFC 4306은 2005년 IKEv2를 정의하면서 분리된 RFC 2407, 2408, 2409 계열을 폐기했다. 2023년 IESG는 IKEv1 계열을 Historic으로 옮겼고, RFC 9395가 관련 레지스트리를 닫았다. RFC 7296은 이후 IKEv2 인터넷 표준이 되었다. 오래된 프레임워크는 역사이며, 오늘 날의 알고리즘 조언이 아니다.

그러나 그 역사적 교훈은 여전히 유효하다. 오늘날의 시스템도 여전히 상관관계 식별자를 신원과, 파서 성공을 승인과, 협상된 상태를 실행 결과와 혼동한다. RFC 2408은 그 실수를 저지르지 않았다. 별개의 필드에 별개의 역할을 할당했다. 쿠키는 교환을 식별했다. 상대를 식별하는 일은 여전히 인증이 맡아야 했다.

출처