요약

  • RFC 2403과 RFC 2404는 전체 출력 길이와 요구되는 키 길이가 서로 달랐음에도, 계산된 HMAC의 처음 96비트를 ESP 또는 AH에 넣도록 했습니다.
  • 이후의 ESP/AH 가이드라인은 두 알고리즘을 분리했습니다. RFC 8221은 HMAC-MD5-96을 MUST NOT으로, HMAC-SHA1-96을 MUST-로 분류했습니다. 공유된 태그 길이가 공유된 보안 판단을 보장하지는 못했습니다.

하나의 필드, 두 가지 구성

1998년 11월, RFC 2403과 RFC 2404는 IPsec의 ESP(Encapsulating Security Payload)와 AH(Authentication Header)를 위한 키 기반 인증 변환을 규정했습니다. 하나는 HMAC을 MD5와 결합했고, 다른 하나는 HMAC을 SHA-1과 결합했습니다. 두 변환 모두 비밀 키가 통신 당사자들에게만 제한될 때 데이터 출처 인증과 무결성을 제공하도록 설계되었습니다. 어느 쪽도 그 자체로 기밀성을 제공하지 않았습니다.

패킷에 담기는 숫자는 같아 보였습니다. 96비트였습니다. RFC 2403의 HMAC-MD5 전체 결과는 128비트이고, RFC 2404의 HMAC-SHA-1 전체 결과는 160비트입니다. 어느 변환이든 송신자는 처음 96비트를 인증자 필드에 저장하고, 수신자는 전체 HMAC을 계산한 뒤 그 처음 96비트를 비교합니다. 96비트라는 선택은 AH의 기본 인증자 길이와 일치했고, 서로 다른 두 구성에 공통의 와이어 형식 크기를 부여했습니다. 그러나 이것이 어느 쪽의 전체 다이제스트를 96비트 해시로 바꾼 것은 아니었습니다.

키 규칙도 달랐습니다. RFC 2403은 128비트 HMAC 키를 요구하고, RFC 2404는 160비트를 요구합니다. 따라서 같은 필드 길이가 서로 다른 전체 출력 길이와 고정된 키 길이와 공존했습니다. 협상된 변환 식별자와 올바른 키 처리는 여전히 중요했습니다. 눈에 보이는 태그 비트 수만으로는 보안 메커니즘 전체를 설명할 수 없었습니다.

충돌 저항성이 HMAC 질문의 전부는 아니다

1998년 문서들은 키가 없는 해시의 충돌을 키 기반 HMAC의 즉각적 파쇄와 동일시하지 않았습니다. RFC 2403은 HMAC이 MD5 기반 서명에 비해 강한 충돌 저항성에 덜 의존한다고 밝혔고, 당시 HMAC-MD5-96에 대한 실용적인 공격은 보고되지 않았다고 기술했습니다. RFC 2404는 HMAC-SHA-1-96에 대해 시기적으로 평행한 평가를 제시했습니다. 이는 미래 사용을 보장하는 진술이 아니라 당시 기준의 분석이었습니다.

구현 가이드라인은 태그 길이를 결정 변수로 만들지 않은 채 평가가 어떻게 바뀌었는지 보여줍니다. 2005년 RFC 4305는 HMAC-SHA1-96을 MUST로, HMAC-MD5-96을 MAY로 분류했습니다. 2007년 RFC 4835는 이 구분을 유지하면서 당시 알려진 충돌 취약점은 HMAC과 결합된 어느 해시에도 영향을 주지 않아야 한다고 언급했습니다. 2014년 RFC 7321은 HMAC-MD5에 대한 이론적 결과를 인정하면서도 실질적 취약점은 없어 보이며 기존 프로토콜에서 제거하는 일이 시급하지 않다고 보았고, SHA-1 충돌 취약점에도 불구하고 HMAC-SHA-1을 여전히 안전한 것으로 간주했습니다.

2017년에 발표된 RFC 8221은 ESP와 AH 구현 요구사항에 대해 더 날카로운 선을 그었습니다. HMAC-MD5-96은 MUST NOT이 되었고, HMAC-SHA1-96은 MUST에서 MUST-로 바뀌었습니다. 이 문서는 금지 근거로 MD5의 알려진 충돌 취약점을 인용했으며, SHA-1의 등급 하향은 업계 전반의 사용 폐기 추세에 귀속시켰습니다. 후자는 96비트 필드가 바뀌었거나 RFC 2404가 갑자기 다른 태그를 규정했다는 주장이 아니었습니다.

상태 표는 트래픽 기록이 아니다

이후 RFC 9395가 RFC 8221을 갱신하면서 IKEv2 변환 레지스트리를 변경했고, 그중에는AUTH_HMAC_MD5_96이라는 이름의DEPRECATED항목도 있었습니다. 이 레지스트리는 RFC 8221의 ESP/AH 구현 표와 같은 것이 아닙니다. 겉보기에 같은 이름이 인접한 IPsec 맥락을 넘나들기 때문에, 레지스트리 라벨은 반드시 해당 프로토콜과 문서 범위를 함께 읽어야 합니다.

이 문서들은 프로토콜 매개변수와 시점이 특정된 구현 권고를 기록합니다. 배치된 장비를 집계하거나, 마지막으로 협상된 HMAC-MD5 보안 연결을 식별하거나, 보편적인 퇴역 날짜를 정하지 않습니다. 운영자에게 실질적인 기록은 선택된 프로토콜, 변환 식별자, 피어의 능력, 설치된 보안 연결, 관측된 트래픽을 구분해야 합니다. 96비트 태그는 그 근거 중 하나일 뿐입니다.

출처