RFC 3118: DHCP 인증은 로컬에 머물렀다

요약

RFC 3118의 지연 인증은 하나의 관리 도메인 안에서 DHCP 클라이언트와 서버 사이에 대역 외 방식으로 배포된 공유 비밀에 의존했다.
로컬 정책이 허용한다면 클라이언트는 여전히 인증되지 않은 제안을 수락할 수 있었다. RFC는 인증되지 않은 메시지를 거부하는 구성 가능한 기본값을 권고했다.

이 옵션은 보편적인 신원을 만들지 않았다

DHCP는 보통 호스트가 네트워크에 접속해 주소와 기타 구성을 받을 수 있게 하는 프로토콜로 기억된다. 그 편의는 동시에 신뢰 문제를 낳았다. 비인가 서버나 실수로 켜진 서버는 클라이언트에 잘못된 게이트웨이, 네임서버 또는 주소를 제안할 수 있다. 서버 입장에서는 권한을 가장하거나 주소 풀을 고갈시키려는 클라이언트에 직면할 수 있다. 2001년 6월에 발표된 RFC 3118은 프로토콜을 재설계하지 않으면서 DHCP 메시지의 발신지와 내용을 인증하려는 목표를 세웠다.

옵션 90은 메커니즘을 와이어상에서 명시적으로 만들었다. 프로토콜 선택자, 알고리즘, 재생 탐지 방법, 재생 값, 인증 정보가 그것이다. 형태는 하나의 옵션처럼 보였지만 서로 다른 질문들을 다루었다. 어떤 절차가 사용되고 있는가? 오래된 메시지를 어떻게 식별할 것인가? 어떤 비밀과 메시지 인증자가 패킷을 상대와 연결하는가?

RFC 3118은 단순한 구성 토큰과 지연 인증을 구분했다. 토큰 모드는 약한 수준의 개체 인증만 제공할 수 있었고 메시지 인증은 제공하지 않았다. RFC는 이를 실수로 시작된 DHCP 서버에 대한 초보적인 보호로 묘사했다. 더 강한 지연 절차는 HMAC-MD5와 공유 비밀을 사용했다. 본 기사는 이 역사적 선택을 보고하는 것이지 새 설계를 위한 권고가 아니다.

인증은 탐색(discover)보다 앞서 시작되었다

지연 인증에서 클라이언트는 DHCPDISCOVER에서 인증을 요청했다. 서버는 비밀을 선택하고 DHCPOFFER에서 인증 정보를 돌려보냈다. 클라이언트는 제안을 선택하고 해당 비밀을 사용해 DHCPREQUEST를 보냈으며, 이후의 인증된 확인(ACK)은 검증을 통과해야 했다. 교환에는 재생 탐지가 수반되므로, 유효한 인증자를 이전 패킷에서 단순히 복사해 새 것처럼 다룰 수 없었다.

이 절차는 첫 패킷 이전에 관계를 요구했다. RFC 3118에 따르면 클라이언트는 대역 외 메커니즘을 통해 키를 받아야 한다. 서버는 권한 있는 클라이언트들의 키를 알고 있거나 안전하게 획득해야 했다. 단일 비밀이 널리 공유된다면, 그 비밀을 얻은 누구나 다른 보유자를 사칭할 수 있었고, 개별 클라이언트의 신원이 중요한 경우 RFC는 고유한 키를 요구했다. 따라서 와이어상의 교환은 DHCP 자체가 정의하지 않는 배포 시스템에 의존했다.

이 경계는 의도된 것이었다. RFC 3118은 지연 인증이 관리 도메인 간 로밍을 다루지 않는다고 명시했다. 비밀을 별도로 교환하는 것이 실현 가능한 도메인 내 사용에 초점을 맞췄고, 클라이언트가 여러 도메인에 접속할 때는 이 접근이 확장성이 떨어질 수 있다고 경고했다. MAC은 메시지가 구성된 키와 일치함을 확인할 수 있었지만, 글로벌 신원이나 로밍 계약, 어느 네트워크든 사용할 권리를 만들어 낼 수는 없었다.

릴레이와 로컬 수락은 신뢰 모델의 일부로 남았다

DHCP 릴레이는giaddr과hops를 변경할 수 있고 릴레이 에이전트 정보를 추가할 수 있다. RFC 3118은 이러한 필드들이 메시지 인증 계산에서 어떻게 다루어지는지를 규정해, 정당한 릴레이 처리가 검증을 무효화하지 않도록 했다. 이는 중개자를 통과하는 정의된 경로를 보존한 것이며, 모든 릴레이를 신뢰할 수 있는 신원 권위로 만든 것은 아니다.

가장 시사적인 점은, 인증이 없을 때 클라이언트가 하나의 보편적 결과로 강제되지 않았다는 것이다. 유효한 인증을 담은 제안이 없다면, 로컬 클라이언트 정책은 인증되지 않은 제안을 허용할 수 있었다. RFC는 클라이언트가 그런 메시지를 거부하도록 구성 가능해야 한다고 요구했고, 기본값으로 거부해야 한다고 말했다. 클라이언트가 수락한다면, 사용자에게 알리고 해당 사건을 기록하도록 권고했다. 따라서 보안은 옵션의 MAC뿐 아니라, 폴백할지 여부를 선택하는 정책 안에도 일부 존재했다.

이것이 중요한 이유는, 눈에 보이는 인증 옵션이 수락된 모든 구성이 인증되었다는 보장으로 오해될 수 있기 때문이다. RFC 3118은 그러한 추론을 경고했다. 표준은 메커니즘과 신중한 기본값을 규정했고, 로컬 신뢰 선택의 책임은 관리자와 클라이언트 구현에 남겨 두었다.

역사적 기록은 옵션 90이 얼마나 널리 구현되고 구성되었는지 보여 주지 않으며, 측정된 공격 감소를 문서화하지도 않는다. 표준은 가능한 동작을 정의한다. 배포와 결과는 별도의 증거를 필요로 한다. RFC 3118의 오래 남는 설계상 포인트는 더 좁다. DHCP 인증은 누가 비밀을 배포했는지, 어떤 릴레이와 서버가 범위 안에 있는지, 클라이언트가 서명되지 않은 대안을 수락하는지에 따라 경계 지어진 로컬 신뢰 조치로 남았다는 것이다.