요약

  • RFC 2085는 64비트 재전송 방지(Replay Prevention) 필드를 보안 연계(SA)별로 선택 사항으로 만들었습니다: SPI가 해당 필드가 존재하거나 존재하지 않는 상태 번들을 선택했습니다.
  • 카운터는 1에서 시작해 한 키 아래에서 순환(wrap)할 수 없었으며, 각 수신자가 유한한 순서 지연(out-of-order) 윈도우를 선택하되 수용된 값은 최대 한 번만 인정하도록 했습니다.
  • 유효한 HMAC과 처음 보는 카운터 값은 공유 SA 하에서 패킷의 수용 가능성을 확립했습니다. 그러나 어느 멀티캐스트 발신자가 그 패킷을 만들었는지, 전역 시간순서, 전달, 인가 또는 애플리케이션 효과를 확립하지는 않았습니다.

1997년 2월, IP 패킷은 완전히 유효한 키 기반 인증자를 지니면서도 회선에서 복사된 오래된 패킷일 수 있었습니다. 패킷도 인증 데이터도 변경되지 않았으므로 암호학적 값은 계속 일치했습니다. RFC 2085는 이 문제에 대한 좁은 해법을 추가했습니다: 인증 대상 재료에 카운터를 넣고, 수신자가 이미 수용한 값은 거부할 만큼의 이전 이력을 기억하도록 하는 것입니다.

이 해법은 “재전송 방지”라는 말이 주는 인상보다 좁았습니다. 인터넷에 하나의 시계를, 모든 패킷에 하나의 영구 신원을 부여하지 않았습니다. RFC 2085가 서술한 것은 하나의 보안 연계(Security Association) 아래에서, 한 수신자가, 하나의 시퀀스 공간에 대해 내리는 판단이었습니다.

SPI가 카운터의 존재 여부를 선택했다

RFC 2085는 이전의 IP 인증 헤더(Authentication Header)를 위한 HMAC-MD5 변환을 정의했습니다. 패킷 다이어그램은 SPI와 인증 데이터 사이에 선택 사항인 64비트 재전송 방지 필드를 배치했습니다.RFC 자체는 SPI가 이 옵션의 포함 여부를 결정한다고 밝혔습니다. 재전송 방지를 사용하지 않을 때는 인증 데이터가 SPI 바로 뒤에 이어졌습니다.

이 세부 사항이 중요한 이유는 SPI가 단순히 패킷에 인쇄된 라벨이 아니었기 때문입니다.1995년 AH 사양에서 수신자는 SPI를 사용해 단방향 보안 연계와 그 처리 매개변수, 즉 알고리즘, 모드, 키 및 관련 상태를 찾았습니다. RFC 2085는 그 선택된 계약에 필드의 존재 여부와 재전송 동작을 추가했습니다.

카운터는 1에서 시작해 위로 증가했습니다. 공유 비밀 키가 64비트 값이 순환할 만큼 오래 유지될 수 없었으며, 하나의 키 아래에서 2^64개를 초과하는 패킷은 금지되었습니다. 필드가 존재하면 HMAC 계산에 포함되었습니다. 공유 키가 없는 쪽이 복사된 카운터를 새 값으로 바꾸면 인증자가 무효화되었습니다.

그러나 인증과 신선도는 여전히 별개의 두 검사였습니다. HMAC 바인딩은 패킷 재료와 재전송 값을 공유 비밀에 묶었습니다. 인증된 값이 수용할 만큼 충분히 새로운지는 수신자의 이력이 결정했습니다.

“증가”해도 순서가 바뀐 패킷의 여지는 남았다

네트워크는 패킷이 전송 순서대로 도착한다고 보장하지 않습니다. 따라서 RFC 2085는 구현이 순서가 바뀐 트래픽을 수용하도록 허용했습니다. 허용하는 순서 지연 패킷 수를 구현 세부 사항으로 남겨둔 것은 의도적이었습니다.

불변 조건은 알고리즘보다 엄격했습니다. 수신자가 윈도우를 지원한다면, 수용되는 모든 순서 지연 값은 이전에 도착한 적 없는 값이어야 했습니다. 최대 인증 카운터보다 낮은 값이라도 윈도우 안에 있고 “본 적 있음” 상태가 비어 있다면 여전히 정당했습니다. 윈도우 뒤쪽의 값은 수용하기엔 너무 오래된 것이었습니다. 윈도우 안의 중복은 재전송이었습니다. 윈도우 앞선 값은 인증 후 수신자의 경계선을 전진시킬 수 있었습니다.

나중에RFC 6479는 이 익숙한 구조를 명시적으로 “범위(range)와 본 비트(seen bits)”로 설명했습니다. 또한 왜 이 윈도우가 로컬 운영 정책인지도 밝혔습니다. 재정렬 깊이가 커질수록 더 큰 윈도우가 필요할 수 있으며, 병렬 암호 처리에서는 특히 그렇습니다. 수용 리스크를 부담하는 수신자가 메모리와 허용치를 선택합니다. 패킷이 서로 다른 순서로 도착하고 윈도우가 같을 필요가 없으므로, 두 수신자는 동일한 발신자를 다르게 관찰할 수 있습니다.

따라서 시퀀스 값은 전역 타임스탬프가 아니었습니다. 간격이 손실을 증명하지 않았고, 늦은 패킷이 공격을 증명하지 않았으며, 한 수신자의 수용이 다른 수신자의 수용을 증명하지 않았습니다. 영구적인 수령 증거는 더 좁았습니다: 이 SA와 이 수신자 상태에서, 이 인증된 숫자는 이전에 수용된 적이 없다는 사실이었습니다.

공유 멀티캐스트는 윈도우가 필요로 하는 계보를 지웠다

가장 날카로운 경계는 RFC 2085의 멀티캐스트 규칙에 나타났습니다. 여러 발신자가 하나의 멀티캐스트 목적지를 향해 동일한 IPsec SA를 공유하면, 문서는 재전송 방지를 활성화해서는 안 된다고 밝혔습니다. 재전송 방지가 필요하다면 각 발신자에게 자체 SA를 부여해야 했습니다.

문제는 멀티캐스트가 HMAC을 무력화한 것이 아니었습니다. 공유 비밀을 가진 모든 이는 여전히 유효한 인증 값을 만들 수 있었습니다. 문제는 시퀀스 소유권이었습니다. 하나의 수신자 윈도우에는 각 값이 한 자리를 차지하는 하나의 일관된 공간이 필요합니다. 각각 1에서 시작하는 독립 발신자들은 즉시 충돌합니다. 개별적으로는 건강한 카운터들이 합산된 흐름에서는 반복될 수 있습니다. 조정자가 서로 겹치지 않는 값을 배정할 수도 있지만, RFC 2085는 그런 다중 발신자 시퀀서를 명시하지 않았습니다.

발신자들을 별개의 SA로 분리하면 사라진 계보가 복원되었습니다. SPI와 연관 조회 상태가 각 패킷을 올바른 카운터 이력으로 안내했습니다. 재전송 방지를 비활성화하는 선택은 반대의 진실을 인정한 것입니다: 공유 인증 관계는 남을 수 있지만, 프로토콜은 더 이상 최초 사용을 판정한다고 주장하지 않았습니다.

이후의RFC 4302 AH 사양은 이 경계를 더 넓은 형태로 유지했습니다. 수신자가 이를 활용하지 않더라도 시퀀스 번호 필드를 필수로 만들고, 논리적 64비트 확장 시퀀스 번호를 지원하며, 표준이 다중 발신자 SA에 대한 안티-리플레이 메커니즘을 제공하지 않는다고 명시했습니다. 이후 규칙들이 계보 문제를 밝혀주지만, 이를 RFC 2085의 와이어 포맷으로 소급 적용해서는 안 됩니다. RFC 2085는 선택 사항인 64비트 필드를 그대로 전송했습니다.

공유 MAC은 고유한 화자가 아니라 멤버십을 인증했다

RFC 1826은 트래픽을 인증할 수 있는 대칭 키 보유자가 또 다른 정당 참가자로부터 온 것처럼 보이는 트래픽을 위조할 수도 있다고 경고했습니다. 이것이 RFC 2085의 핵심 신원 한계입니다. 성공한 HMAC은 공유 비밀의 보유와 커버된 패킷의 무결성을 보였습니다. 공유 그룹의 어느 구성원이 키를 사용했는지는 밝히지 않았습니다.

재전송 카운터는 그 암호 검사 이후 수용을 좁혔습니다. 그룹 비밀을 개인 서명으로 격상시키지 않았습니다. 기밀성도 제공하지 않았습니다. AH는 명시적으로 페이로드나 트래픽 패턴을 숨기지 않았습니다. 패킷은 SA 하에서 정당하고 수신자에게 신선하면서도, 애플리케이션의 인가를 받지 못했거나, 목적지 프로세스에서 무시되었거나, 이후 폐기되었거나, 주장된 비즈니스 결과를 낼 수 없을 수 있었습니다.

운영 증거 사슬은 이 사실들을 분리해 유지해야 합니다: SA 조회; 옵션 존재 여부; 카운터 값; 윈도우 위치; 이전 관찰 상태; HMAC 결과; 패킷 수용; 상위 계층 수령; 인가; 확정된 효과. 사슬의 한 고리를 건너뛰면, 로컬 안티-리플레이 판단이 결코 아니었던 보편적 진실처럼 보이게 됩니다.

역사적 교훈은 순서가 증명할 수 있는 것의 한계다

RFC 2085의 설계는 절약적이었습니다. SA가 재전송 상태를 선택하도록 하고, 수신자에게 재정렬 허용치의 재량을 주며, 엄격한 일회성 수용 불변 조건을 요구했습니다. 동시에 자신의 실패 사례도 공개했습니다. 여러 발신자가 하나의 연계를 공유하면, 단일 카운터 이력은 발신자 계보를 보존할 수 없었습니다.

그 솔직함은 여전히 가치가 있습니다. 시퀀스 번호는 소유자, 범위, 재설정 경계가 명확할 때 강력합니다. 그 사실이 없으면 “단조 증가”는 여러 로컬 카운터를 서술하면서 합쳐진 흐름은 반복될 수 있습니다. “인증됨”은 키를 공유하는 집합 중 한 구성원을 뜻할 수 있습니다. “한 번 수용됨”은 하나의 서비스 전체가 아니라 한 수신자에서 한 번을 뜻할 수 있습니다.

카운터는 발신자의 이름을 밝히지 않았습니다. 그것은 한 수신자의 수용 이력 안의 한 자리를 밝혔을 뿐입니다.

출처