요약

  • 고전 RADIUS는 1옥텟 식별자를 전역적으로 고유한 트랜잭션 이름으로 만들지 않았다. 클라이언트는 이를 대기 중인 요청과 대조한 뒤, 해당 요청의 16옥텟 요청 인증자와 홉의 공유 비밀로 계산된 응답 인증자를 검증했다.
  • 같은 서버로의 내용 없는 재시도는 식별자, 요청 인증자, 발신 포트를 유지했다. RFC 5080은 서버가 그 중복을 인식해 인증을 반복하지 않고 캐시된 응답을 재전송할 것을 요구했으며, 변경된 속성 대신 새 요청을 시작했다.

대기열이 잊히기 전에 먼저 순환하는 이름 공간

RADIUS 패킷 헤더는 자기 역할에 비해 거의 너무 작아 보인다. Code 다음에 8비트 식별자가 온다. 값은 많아야 256개뿐인데, 네트워크 액세스 서버는 수많은 동시 로그인을 처리하고 손실된 데이터그램을 재시도하며 대체 서버를 consult하고 여러 차례의 챌린지와 응답을 수행할 수 있다.

표준은 카운터가 절대 순환하지 않으리라 가정하는 방식으로 이 문제를 풀지 않았다. 그 대신 이 바이트에 지역적이고 일시적인 의미를 부여했다.RFC 2865는 식별자가 요청과 응답의 대조를 돕는다고 말한다. 클라이언트는 이전 요청이 아직 대기 중인 동안 같은 발신 주소와 UDP 포트에 대해 식별자를 재사용해서는 안 된다.RFC 5080은 최근 최소 사용(LRU) 방식의 할당을 권고하며, 작은 이름 공간이 허용하는 한도 내에서 재사용을 최대한 멀리 벌려 둔다.

이것이 첫 번째 경계다. 식별자 37은 세계, 아니 심지어 한 대의 기계에 대해 영구히 "인증 트랜잭션 37"을 뜻하지 않는다. 그것은 특정 교환 맥락에서 현재 대기 중인 37의 사용을 의미한다. 유효한 응답이 도착하거나 요청이 시간 초과되면, 그 번호는 다른 의미로 되돌아올 수 있다.

이러한 경제성은 첫 RADIUS RFC인 1997년 1월의RFC 2058, 그 4월 대체 문서인RFC 2138, 그리고 RFC 2865가 된 2000년 6월 개정판까지 일관되게 존재했다. 작은 식별자는 설계의 전부가 아니었다.

16개의 예측 불가능한 옥텟이 질문을 완성했다

Access-Request는 16옥텟 요청 인증자를 담는다. RFC 2865는 새 식별자가 사용될 때마다 이 값이 바뀌어야 한다고 요구하며, 공유 비밀의 수명 동안 예측 불가능하고 고유해야 한다고 말한다. 이 성질들은 단순히 용량을 늘리는 것 이상을 한다. 같은 비밀로 요청 값이 반복되면 포획된 응답이 다시 유용해질 수 있고, 미래의 값이 예측 가능하면 공격자가 실제 교환이 일어나기 전에 거짓 응답을 준비할 수 있다.

응답은 1바이트 식별자를 복사하지만 16바이트를 단순히 되돌려 보내지는 않는다. Access-Accept, Access-Reject, Access-Challenge에 대해 서버는 응답의 Code, 식별자, 길이, 속성과 원래 요청의 요청 인증자, 그리고 클라이언트와 공유하는 비밀을 대상으로 응답 인증자를 계산한다.

수신 시 클라이언트는 먼저 식별자로 대기 중인 Access-Request 후보를 찾는다. 그다음 응답 인증자를 바로 그 요청에 대하여 검증한다. 올바른 8비트를 갖고 있지만 더 이른 요청 인증자에서 파생된 늦게 도착한 패킷은 검증에 실패한다. 조용히 폐기된다.

역할 분담은 우아하다. 저렴한 필드가 조회 범위를 좁히고, 더 큰 예측 불가능한 값이 응답을 특정 질문에 묶으며, 공유 비밀이 홉 인증을 제공하고, 대기 상태가 시간을 공급한다. 어느 하나만으로 전체 의미를 떠받치는 조각은 없다.

같은 요청은 인식 가능한 채로 같아야 했다

RADIUS가 UDP를 사용한 것은 액세스 판단이 특이한 기한을 지녔기 때문이다. 사용자는 수 초를 견딜 수 있지만, 몇 분 뒤에야 오래된 데이터를 전달하는 전송 계층은 쓸모가 없다. 그래서 클라이언트는 전송 계층 위에 사본을 보관하고 자체 타이머를 돌리며, 재시도하거나 대체 서버를 선택할 수 있었다.

이 자유는 의미론적 선택을 만들었다. 다음 데이터그램은 같은 판단을 위한 또 하나의 전달 시도인가, 아니면 새 판단을 받아야 할 변경된 요청인가?

RFC 2865는 단호한 선을 그었다. 네트워크 액세스 서버가 같은 서버에 변경 없이 속성을 재전송할 때는 요청 인증자, 식별자, 발신 포트를 유지해야 한다. 그중 하나라도 바꾸면 서버는 더 이상 연속성을 인식하지 못할 수 있다. 속성을 하나라도 바꾸면 클라이언트는 새 요청 인증자와 새 식별자를 사용해야 한다.

따라서 변경 없는 재전송은 두 번째 패킷이라는 이유만으로 두 번째 로그인 시도가 아니다. 그것은 전달을 다시 구하는 같은 요청이다. 반대로 타임스탬프를 추가하거나, 비밀번호 응답을 교체하거나, 요구된 서비스를 수정하는 것은 "더 신선한 세부 사항을 얹은 같은 패킷"이 아니다. 사용자명과 사람의 의도가 그대로 보이더라도 그것은 새 질문이다.

중복 응답은 중복 판단보다 안전했다

초기 사양은 중복 검출을 암시했지만 현장 경험은 모호성의 결과를 드러냈다. RFC 5080은 서버 동작을 명시했다. RADIUS 서버는 중복 Access-Request를 검출하고 자신이 만든 Access-Accept, Access-Reject 또는 Access-Challenge를 캐시해야 한다.

중복이 서버가 이미 응답한 뒤 도착하면, 서버는 요청을 다시 처리하지 않고 원래 응답을 재전송한다. 원래 요청이 아직 처리 중일 때 도착하면, 중복은 조용히 폐기된다. 서버는 병렬 인증을 시작하지 않고 잠정 판단을 만들어 내지도 않는다.

이 구분은 운영상 중요하다. 백엔드는 카운터를 올리고, 로그인을 기록하고, 일회용 값을 소비하거나 값비싼 작업을 촉발할 수 있다. 같은 요청을 다시 처리하면 한 번의 시도로 두 가지 효과가 생길 수 있다. 캐시된 응답을 재전송하면 패킷 손실일 가능성을 수습하면서 하나의 판단을 유지한다.

RFC 5080은 캐시에 복합 키를 준다. 발신 주소, 발신 포트, RADIUS 식별자, 수신 소켓, 요청 인증자다. 항목은 보통 5~30초만 살아 있다. 처음 네 요소는 일치하지만 요청 인증자가 다른 요청은 기존 캐시 항목을 무효화한다. 보이는 식별자가 권한을 얻은 것은, 다른 좌표들이 우연히 맞아떨어졌기 때문이 아니었다.

변경된 내용은 이전 응답의 지위를 무효화했다

클라이언트가 요청을 보내고 기다린 뒤 속성을 하나 바꾸어 다시 보냈다고 하자. 첫 서버는 아직 계산 중일 수 있다. 그 서버의 나중 응답은 이전 패킷에 대해서는 완벽하게 진짜일 수 있다. 그럼에도 그것은 더 이상 현재 요청에 대한 응답이 아니다.

클라이언트는 이전 시도에 대한 응답을 폐기하고 현재 요청에 대한 응답을 최종적인 것으로 다루어야 한다. 두 서버나 두 시점이 서로 달리 말하더라도 마찬가지다. 암호학적 유효성은 필요하지만 충분하지 않다. 질문이 아직 대기 중이어야 한다.

Access-Challenge는 더 긴 대화에서 같은 규칙을 보여준다. 유효한 챌린지는 State를 실어 또 한 번의 사용자 응답을 요구할 수 있다. 네트워크 액세스 서버는 그러면 새 식별자와 새 요청 인증자로 새 Access-Request를 보내고, 요구대로 State를 되돌려 보내며, 새 응답을 포함시킨다. State는 세션의 여러 라운드를 이어 준다. 그러나 라운드들을 하나의 트랜잭션으로 접어 버리지는 않는다.

이 분리는 미묘한 범주 오류를 막는다. "같은 사용자"는 응용 수준의 판단이다. "같은 RADIUS 요청"은 정확한 속성과 정확한 트랜잭션 재료를 갖는 회선 수준의 신원이다. 프로토콜은 안전하게 하나를 다른 것으로 대체할 수 없다.

첫 유효 응답이 대기 중인 청구를 종결했다

재시도와 대체 서버는 하나보다 많은 응답을 만들어 낼 수 있다. RFC 5080은 클라이언트가 대기 중인 요청에 대해 응답 인증자가 유효한 첫 응답을 처리한다고 말한다. 이후 응답은 요청을 받아 줄 대기 중인 요청이 더 이상 없으므로 요청되지 않은 것으로 취급되어 조용히 폐기된다.

이는 모든 서버가 같은 정책을 고르리라는 보장은 아니다. 주 서버는 거부하고 대체 서버는 수용할 수도 있다. 사용자 저장소, 구성, 정책의 일관성을 유지하는 것은 여전히 운영자의 책임이다. 트랜잭션 규칙이 막는 것은, 클라이언트에서 이미 끝난 판단을 늦게 도착한 패킷이 다시 여는 일뿐이다.

Access-Accept가 불가능한 것을 명령하지도 않는다. RFC 2865는 반환된 서비스를 제공할 수 없으면 네트워크 액세스 서버가 그 결과를 거부로 다룬다고 말한다. 유효한 응답은 패킷을 인증하고 요청에 묶어 준다. 그러나 수신 시스템이 갖고 있지 않은 모뎀 모드, VLAN, 경로나 다른 능력을 만들어 낼 수는 없다.

프록시는 증명을 끝내고 다시 만들었다

RADIUS는 자주 프록시를 거친다. 응답 인증자의 홉 지역적 성격은 거기서 더이상 오해의 여지 없이 드러난다. 전달 서버는 자신과 원격 서버가 공유하는 비밀로 원격 서버의 응답을 검증하고, 자신이 추가한 Proxy-State를 제거하고, 이전 클라이언트가 기대하는 식별자를 복원한 뒤, 그 이전 홉용 비밀로 새 응답 인증자를 계산한다.

따라서 네트워크 액세스 서버는 홈 서버로부터의 하나의 종단 간 서명을 갖고 있는 것이 아니다. 자신이 비밀을 공유하는 피어로부터의 증명을 갖고 있는 것이다. Proxy-State는 응답이 사슬을 되짚어 오도록 돕고, 그것을 만들지 않은 시스템에는 불투명하지만, 액세스 권한은 아니다.

Identifier=37, Accept만 저장하는 감사 기록은 사건을 해석하는 데 필요한 증거를 파괴한다. 쓸모 있는 기록에는 홉, 클라이언트 주소와 포트, 수신 소켓, 대기 구간, 요청 인증자의 보호된 지문, 프록시 맥락, 중복 캐시 조치, 적용된 로컬 서비스 효과가 필요하다. 비밀과 자격 증명을 담은 속성은 평범한 로그에 들어가서는 안 된다.

재시도가 스스로의 서비스 거부로 동조할 수 있었다

재시도 메커니즘은 집단적 위험도 만들었다. RFC 5080은 혼잡성 백오프 없이 1초 이하의 고정 타임아웃을 쓰는 클라이언트들을 기술한다. 정전 뒤 수천 대의 액세스 장치가 함께 깨어나 함께 보내고 함께 재시도하여, 사용자가 돌아오는 바로 그 시점에 인증 서비스를 압도할 수 있다.

그것이 권고하는 타이머는 재전송마다 늘어나고 지터를 포함하며 최대 지연, 최대 시도, 최대 지속 시간 한도를 지킨다. 이 무작위성은 탈동조화를 위한 것이며 암호학적 강도를 요구하지 않는다. 요청 인증자의 예측 불가능성은 다른 목적을 지니며 보안 기준에 맞게 생성되어야 한다. 두 값을 모두 "무작위"라고 부른다고 서로 바꿔 쓸 수 있는 것은 아니다.

과부하 정책은 이미 진행 중인 대화를 우대할 수도 있다. 서버는 유효한 State를 지닌 요청을 우선하고, 프록시는 새 요청을 더 받아들이기 전에 홈 서버의 응답을 처리할 수 있다. 이것은 완료를 보호하고 재시도 압력을 줄인다. 그러나 영향을 받은 사용자에게 더 큰 액세스 권리를 주지는 않는다.

TLS는 결국 경계를 옮겼을 뿐, 역사를 바꾸지 않았다

RFC 6614는 2012년 RADIUS를 TCP 위의 TLS 안에 넣었지만, 역사적인 패킷 수준 MD5 메커니즘을 유지하고 그 계산에 고정 비밀radsec을 사용했다. 전송 계층이 연결을 보호하는 동안 낡은 헤더 규칙은 그 안에서 계속되었다.

RFC 9765는 2025년 이 절충을 다시 검토했다. 두 피어가 ALPN으로 TLS 1.3 이상 위에서 RADIUS/1.1을 협상하면, 공유 비밀과 MD5 패킷 메커니즘은 사라진다. 기존 인증자 공간은 16옥텟의 불투명한 토큰이 되고, 토큰이 요청/응답 상관을 담당하며, 낡은 식별자 바이트는 예약 영역이 된다.

이 변화는 BTW가 이미 다루는 다른 역사로의 경계다. 그것이 평범한 RADIUS/UDP를 다시 쓰는 것도, 하나의 업그레이드된 홉이 프록시 사슬의 모든 홉을 바꾸는 것도 아니다. 여기서의 관련성은 더 좁다. 전송 계층이 진정성과 기밀성을 소유하게 된 뒤에도, 요청 상관에는 여전히 충분히 크고 맥락에 묶인 트랜잭션 값이 필요하다는 점이다.

이 패킷이 결코 증명하지 못한 것

고전 응답 인증자는 역사적 메커니즘이지 현대 암호학 권고가 아니다. 그것이 오늘날 MD5를 안전하게 만들지 않는다. 속성에 실린 PAP, CHAP, EAP나 다른 방법과 독립적으로 사람을 식별하지도 않는다. 서버 정책이 현명했다거나, 회계가 확정되었다거나, 프록시가 진실을 말했다거나, 수용 뒤에 서비스 트래픽이 흘렀다는 것을 증명하지도 않는다.

RFC 기록이 확립하는 것은 설계와 그 정정이지, 현재 배포 점유율이나 제품 적합성이 아니다. 그 기록의 내구성 있는 교훈은 증거의 세분성에 관한 것이다. 짧은 이름은 범위, 수명, 뒷받침하는 맥락이 명시적일 때 안전할 수 있다. 대시보드가 그 이름을 보존하면서 이름을 의미 있게 만든 모든 것을 버릴 때 위험해진다.