요약

  • RFC 1472는 PPP 인증 프로토콜 선호도와 식별자/비밀값 쌍을 관리 테이블에 담았고, 링크 범위·방향·프로토콜·상태를 명시했습니다.
  • valid로 표시된 행은 사용 가능한 구성이었습니다. 인증은 그 이후에 PAP 또는 CHAP 교환, 인증자의 결과, 그리고 별도로 열리는 네트워크 계층을 필요로 했습니다.

PPP 보안 MIB의 이상한 점은 비밀값을 담고 있다는 사실이 아니라, 그 존재가 잘못된 질문에 답하도록 허용하지 않은 것이었습니다.

1993년 6월에 발표된RFC 1472는 점대점 프로토콜(PPP) 링크에서 사용되는 보안 프로토콜의 관리 대상 정의를 담았습니다. 이 문서는 동반 MIB 계열에 속했습니다.RFC 1471은 링크 제어 프로토콜 관리를 다루었고, RFC 1472는 인증 구성을 자체적인 선택적 보안 그룹으로 분리했습니다.

이 분리는 서로 다른 세 가지 제어 지점을 드러냈습니다. 관리자가 구성하려는 의도, 에이전트가 현재 보유한 것, 그리고 두 PPP 종단이 나중에 링크에서 실제로 수행한 것입니다. MIB는 앞의 두 가지를 검사 가능하게 만들었습니다. 세 번째는 만들어내지 않았습니다.

하나의 테이블이 시도할 것을 선택했다

구성 테이블은 행을 링크와 선호도로 색인했습니다. 프로토콜 필드는 시도할 인증 프로토콜을 지명했습니다. 선호도 숫자가 낮을수록 먼저 시도되었고, 링크 값이 0이면 명시적 항목이 없는 링크의 기본값으로 작동했습니다.

각 단어에는 경계가 있었습니다. “선호도”는 성공 확률이나 보안 강도가 아니라 순서를 뜻했습니다. “프로토콜”은 이미 관찰된 교환이 아니라 시도할 메커니즘의 이름이었습니다. “기본값”은 구성의 공백을 채웠을 뿐, 모든 링크가 해당 행을 물려받는다는 것, 링크별 행이 이를 가리지 않는다는 것, 피어가 그 선택을 지원한다는 것을 증명하지 않았습니다.

상태 필드는 이 점을 더 날카롭게 했습니다. 행은valid또는invalid일 수 있었습니다. invalid로 설정하면 그 행이 더 이상 현재 구성이 아니게 되었지만, 삭제 여부는 구현에 따라 달랐습니다. 관리 스테이션은 여전히 존재하지만 더 이상 사용되지 않는 행도 받아들일 준비가 되어 있어야 했고, 상태를 확인해야만 해석할 수 있었습니다.

따라서 존재가 곧 현재성은 아니었습니다. 테이블 자체가 그렇게 말했습니다.

두 번째 테이블은 사람이 아니라 쌍을 저장했다

비밀값 테이블은 링크당 하나 이상의 식별자/비밀값 쌍을 담았습니다. 색인이 여러 쌍을 구분했습니다. RFC 1472는 그중 선택은 로컬 구현에 맡긴다고 명시했습니다.

방향이 중요했습니다.local-to-remote는 로컬 PPP 개체가 원격 개체에 자신을 인증할 때 이 쌍을 사용할 수 있음을 뜻했습니다.remote-to-local은 로컬 개체가 원격 피어가 이 쌍을 사용할 것으로 기대함을 뜻했습니다. 같아 보이는 행도 방향이 바뀌면 운영상 의미가 달라졌습니다.

프로토콜도 중요했습니다. PAP의 경우 식별자 필드에는 Peer-ID가, 비밀값에는 암호가 들어갈 수 있었습니다. CHAP-MD5의 경우 식별자에는 CHAP Name이, 비밀값에는 응답 계산에 사용되는 재료가 들어갈 수 있었습니다. RFC 1472는 두 필드를 의도적으로 프로토콜에 따라 의미가 달라지는 옥텟 문자열로 서술했습니다.

식별자 문자열은 사람도, 계정 권한도, 회선 위의 누구인지에 대한 증거도 아니었습니다. 비밀값은 특정 시점의 보유를 증명하지 않았습니다.valid상태는 여러 쌍 중 어떤 것이 선택되었는지, 피어가 기대한 값을 제시했는지, 인증자가 이를 수락했는지 말해주지 않았습니다.

이것이 핵심적인 역사적 경계입니다. 행은 가능한 사건에 대한 입력이었습니다.

사건은 다른 프로토콜에 있었다

당대의RFC 1334가 빠져 있던 PAP와 CHAP의 동작을 정의했습니다. PAP는 링크 설정 후 Peer-ID/암호 쌍을 보내고 Authenticate-Ack 또는 Authenticate-Nak를 기다렸습니다. 이후의RFC 1994는 CHAP를 챌린지, 계산된 응답, 인증자의 비교, 확인 또는 실패로 규정했고, 이후 추가 챌린지도 가능했습니다.

이 메시지들이 MIB 행에는 담길 수 없는 증거를 만들어냈습니다. 감사에는 어떤 링크가 존재했는지, 어떤 인증 프로토콜이 협상되었는지, 어떤 요청이나 챌린지가 어느 응답에 대응하는지, 인증자가 어떤 자격 증명 버전을 사용했는지, 그리고 어떤 결과를 냈는지 알아야 했습니다.

그 결과조차 또 다른 경계에서 멈췄습니다.RFC 1661은 PPP 단계를 순서대로 유지했습니다. 데이터 링크를 설정·검증하고, 선택적으로 피어를 인증한 뒤, 네트워크 제어 프로토콜(NCP)로 네트워크 계층 프로토콜을 구성합니다. NCP가 열린 후에야 그 네트워크 계층의 데이터그램이 흐를 수 있었습니다.

구성된 자격 증명은 인증을 증명하지 않았습니다. 인증은 IP 구성을 증명하지 않았습니다. IP 구성은 원격 경로, 패킷 수신 또는 응용 결과를 증명하지 않았습니다.

관리 경로 자체가 민감했다

RFC 1472는 보안 그룹의 제어가 위험했기 때문에 이를 선택적으로 만들었습니다. 이 그룹은 피어 식별자, 비밀값, 그리고 인증 동작을 선택하는 변수를 노출했습니다. 서브트리를 읽을 수 있는 침입자는 민감한 자료를 얻을 수 있었고, 변경할 수 있는 침입자는 보안 동작을 비활성화하거나 전환할 수 있었습니다.

RFC는 SNMPv2 개인정보 보호(privacy) 없이 그룹을 구현하지 말 것을 강하게 권고했습니다. 보호된 MIB 뷰를 두거나 서브트리 접근을 막는 방법도 제시했습니다. 변수를 읽기 전용으로 만들면 쓰기 권한은 줄었지만 읽기 위험은 남았고, 본문은 이를 명시적으로 지적했습니다.

이 지침은 보호된 관리 세션을 PPP 인증 결과로 바꾸지 않았습니다. 구성을 조회하거나 변경하는 관리 경로를 보호했을 뿐입니다. 데이터 평면의 피어는 여전히 자신의 교환을 수행해야 했습니다.

따라서 이 아키텍처에는 유용한 비대칭이 있었습니다. 관리 추상화가 강력해질수록 그 접근은 더 엄격하게 경계로 묶여야 했습니다. 자격 증명을 중앙 집중화하면 관리가 단순해지지만, 잘못된 기본값, 낡은 행, 노출된 뷰 또는 무단 쓰기의 결과도 함께 집중됩니다.

상태 단어에는 그 주위에 장부가 필요했다

링크를 재구성하려는 운영자는 “비밀값이 유효했는가?”로 시작해서는 안 됩니다. 이 질문은 너무 많은 영수증을 압축합니다.

유용한 기록 체계는 관리자의 요청 변경, 에이전트가 반영한 행, 링크 범위와 기본값 상속 여부, 프로토콜 선호도, 쌍 색인·방향·상태, 보호된 읽기 검증, LCP에서 협상된 인증 프로토콜, PAP 요청 또는 CHAP 챌린지/응답, 인증자의 결정, NCP 상태, 그리고 이후 트래픽 관찰을 기록합니다.

각 전환에는 행위자와 시각이 필요합니다. 보존된 invalid 행은 런타임이 선택하지 않았다면 무해한 역사입니다. 선택된 적 없는 valid 행은 실패한 인증이 아니라 구성 재고입니다. 알 수 없는 자격 증명 버전에 묶인 성공적인 인증은 귀속 공백입니다. 인증은 되었지만 IPCP가 열리지 않는 링크는 인증 실패가 아닙니다.

RFC 1472의 오래가는 가치는 관리 어휘가 운영 증명을 흉내 내지 못하도록 거부한 데 있습니다. MIB는 시스템이 무엇을 시도할 준비가 되어 있는지 말할 수 있었습니다. 무슨 일이 일어났는지는 회선이 답해야 했습니다.

출처