요약

  • RFC 3079는 마스터 값을 더 이어지는 도출 과정의 입력으로만 사용했다. 역할과 방향 레이블이 붙은 별도 분기가 일시적 송신·수신 키를 만들어냈고, 그 키들이 서로 다른 RC4 컨텍스트를 초기화했다.
  • 정확한 계산은 하나의 유한한 사실만 확립했다: 특정 입력이 특정 바이트를 만들었다는 것. 이 계산이 양쪽 피어가 동일한 첫 인증을 선택했는지, 송신이 수신에 올바르게 대응하는지, 동일한 MPPE 모드를 협상했는지, 비밀값을 안전하게 운반했는지, 암호 상태를 동기화했는지, 애플리케이션 데이터가 전달되었는지를 증명하지는 못했다.

스스로 패킷을 갖지 않는 마스터 값

RFC 3079에서 가장 유용한 문장은 부정문이다. 마스터 세션 키는 데이터를 암호화하거나 복호화하는 데 절대 사용되지 않는다. 이 키는 일시적 세션 키를 도출하는 데만 존재한다.

그 규칙은 최고 자격 증명처럼 들리는 것을 중간 객체로 바꾸어 놓았다. MS-CHAP-2에서는 비밀번호 계보와 NT-Response가 먼저 16옥텟 마스터 값을 만들었다. 두 번째 함수가 두 가지 사실에 따라 분기를 선택했다: 원하는 키가 송신용인지, 그리고 로컬 엔드포인트가 서버인지. 세 번째 단계가 일시적 키를 만들었다. 그다음에야 구현이 송신 또는 수신 RC4 테이블을 초기화했다.

이 구분은 의미적 장식이 아니라 운영상의 구분이었다. 시스템이 "마스터 키 도출됨"만 기록했다면, 어떤 분기를 선택했는지, 어느 방향이 결과를 받았는지, 결과가 트래픽 컨텍스트에 들어갔는지는 보여주지 않은 것이다. 로컬에서 올바른 마스터 값이 잘못된 역할 레이블을 타고 흐를 수 있다. 길이가 같은 두 일시적 값이 서로 다른 세션에 속할 수 있다. 바이트열이 공개된 테스트 벡터와 일치하면서 실제 호출이 잘못된 인증 이벤트를 사용할 수 있다.

따라서 RFC 3079는 알고리즘 내부의 보관 계보(documented chain of custody)를 문서화했다. 그 사슬은 자격 증명 증거에서 시작해, 레이블이 붙은 도출 경계를 넘어, 방향별 일시적 자료를 만들고, 암호 컨텍스트에서 끝났다. 각 고리는 편리한 단어 "키"가 암시하는 것보다 더 좁은 의미를 갖는다.

세 가지 자격 증명 계열이 그 출처를 지우지 않았다

2001년 3월에 Informational RFC로 발표된 RFC 3079는 서드파티 구현자에게 Microsoft 제품과의 상호운용성을 위한 공개 참조를 제공하는 것을 목표로 했다. 이 문서는 MPPE 협상, 패킷 암호화, 세션 내 재키잉을 정의하지 않았다; 그 메커니즘은 RFC 3078이 담당했다. 발표 자체가 이 메모를 인터넷 표준으로 만들거나, 어떤 제품이 모든 분기를 올바르게 구현했다는 증명도 아니었다.

이 문서는 세 가지 상류 계열을 기술했다. MS-CHAP-1은 LAN Manager 비밀번호 해시로부터 40비트 및 56비트 자료를, 128비트 분기는 Windows NT 비밀번호 해시에 인증자 챌린지를 더해 도출했다. MS-CHAP-2는 Windows NT 비밀번호 계보와 그 NT-Response를 세 가지 강도 모두에 사용했다. EAP-TLS는 내보낸 TLS 키잉 자료에서 시작했다.

이 경로들은 MPPE 트래픽 키로 수렴했지만 서로 교환 가능한 증거가 되지는 않았다. 모니터는 어떤 인증 계열이 돌았는지, 어느 피어가 자격 증명을 공급했는지, 어떤 챌린지나 응답이 사용되었는지, 세션이 어떤 자격 증명 이벤트를 첫 것으로 다루었는지 알아야 했다. "8바이트 설치됨"은 40비트 모드나 56비트 모드 어느 쪽이든 가리킬 수 있고; "16바이트 설치됨"은 서로 다른 자격 증명 역사에서 온 128비트 자료를 가리킬 수 있다.

RFC 2759는 MS-CHAP-2의 피어 챌린지, 인증자 챌린지, 사용자명 기반 챌린지 해시, NT-Response, 인증자 응답을 정의했다. RFC 2433은 이전 MS-CHAP 절차를 제공했다. RFC 2716은 PPP 안의 EAP-TLS를 기술했다. 이 문서들은 상류 입력을 확립할 수 있다. 그러나 그 어느 것 하나만으로 CCP가 이후 열렸는지, 사용자 데이터가 의도한 MPPE 상태 아래 링크를 건넜는지는 보여주지 않는다.

첫 인증이 세션 식별의 일부가 되었다

MS-CHAP에서 도출되는 키에 대해 RFC 3079는 놀랄 만큼 구체적인 계보 규칙을 선택했다. 양방향의 초기 키는 호출을 시작한 피어의 자격 증명에서 나왔다. 챌린지가 개입되는 경우, 도출은 첫 인증의 챌린지 또는 챌린지들로부터 이루어졌다. 이 규칙은 단방향 인증과 쌍방 인증 모두, 그리고 멀티링크 번들의 각 링크에도 동일하게 적용되었다.

"첫 인증"이라는 표현은 독립된 하위 시스템들로 조립된 구현에서 쉽게 잃어버린다. 인증 서비스는 가장 최근의 성공한 교환만 보관할 수 있다. 멀티링크 컨트롤러는 각 링크를 씨앗 삼은 자격 증명 이벤트를 보존하지 않은 채 링크들을 병합할 수 있다. 페일오버 노드는 사용자가 인증했다는 사실은 알지만 어떤 챌린지/응답 쌍이 활성 도출 세대에 속하는지는 모를 수 있다.

RFC 3079는 이 분산 문제를 해결하지 않았다. 멀티섀시 멀티링크 경우에서 RFC는 참여하는 모든 기기에서 올바른 키가 생성되도록 하는 책임을 명시적으로 구현에 두었다. 공식은 시스템이 올바른 역사를 공급한 뒤에야 결정론적으로 동작한다. 사용자명과 성공 플래그를 복제하는 것으로는 부족하다.

바로 여기서 언뜻 수학처럼 보이는 사양이 운영 이야기가 된다. 실제 세션 식별자는 단순한 PPP 핸들이 아니었다. 그것은 선택된 자격 증명 이벤트, 엔드포인트 역할, 링크 멤버십, 도출 세대를 포함했다. 그 좌표들이 없으면 동일한 코드가 결정론적으로 잘못된 답을 만들어낸다.

방향은 로컬 레이블이 아니라 관계였다

MS-CHAP-2의GetAsymmetricStartKey는 고정된 레이블로 마스터 값을 방향별 분기로 쪼갰다. 선택되는 레이블은IsSend와IsServer에 따라 바뀌었다. 서버에서 송신 분기는 클라이언트가 수신에 쓰던 레이블을 사용했고; 나머지 레이블은 서버 수신을 클라이언트 송신과 짝지었다.

RFC 3079는 EAP-TLS 논의에서 이 불변식을 다시 명시했다: 한쪽의 송신 키는 다른 쪽의 수신 키다. "송신"은 엔드포인트에 대한 상대에서만 의미를 가진다. 한 기기의send_key를 피어의 이름도send_key인 필드에 복사해 넣은 구성 내보내기는 단어를 보존하면서 관계를 뒤집는다.

그렇기 때문에 두 개의 한쪽면 성공 기록은 동작하는 쌍을 증명하지 못한다. 각 엔드포인트는 기대한 길이의 키를 도출·설치했다고 보고할 수 있다. 양쪽 보고가 모두 참이면서 트래픽은 실패할 수 있다 — 한 엔드포인트가 클라이언트 역할을 두 번 선택했거나, 수신·송신 컨텍스트를 바꿔 끼웠거나, 결과를 번들 안의 다른 링크에 연결했기 때문이다.

올바른 접수 영수증은 양쪽 관점을 결합한다: 엔드포인트 식별, 클라이언트/서버 역할, 로컬 방향, 피어 방향, 자격 증명 세대 지문, 일시적 키 지문. 그 영수증은 비밀값 자체를 노출하지 않으면서 송신 A가 수신 B와 같고 송신 B가 수신 A와 같음을 증명해야 한다.

강도는 도출 이후에 변형되었다

40비트, 56비트, 128비트 분기는 세 레이블이 붙은 같은 버퍼가 아니었다. 40비트와 56비트 모드는 8옥텟 일시적 값을, 128비트 모드는 16옥텟 값을 사용했다. 40비트 모드에서는 처음 세 옥텟이 고정 상수로 덮어 쓰였고, 56비트 모드에서는 첫 옥텟이 덮어 쓰였다. 유효 강도는 앞선 도출 단계 이후에 의도적으로 낮추어졌다.

EAP-TLS는 또 다른 인터페이스 규칙을 더했다. 대상 길이보다 짧은 비대칭 마스터 값은 왼쪽에 패딩해야 했고, 긴 값은 잘라내야 했다. 따라서 평범해 보이는 대상 길이가 서로 다른 원래 길이와 정규화 경로를 숨길 수 있었다.

RFC 3079는 구현자가 산술을 시험할 수 있도록 완전한 샘플 값을 제공했다. 그 벡터들은 동작 코드 보조 도구로서 유용했지만, 선택된 입력에 대한 적합성만 증명했다. 그 벡터들은 실제 사용자의 비밀번호를 인증하지도, EAP-TLS 자료의 운반을 검증하지도, 양쪽이 40비트가 아닌 128비트를 협상했음을 보여주지도, 초기화된 테이블이 패킷을 실제로 처리했음을 증명하지도 않았다.

보안 섹션은 모드 이름을 충분한 증거로 다루는 비용을 드러냈다. MS-CHAP-1에서 초기 40비트 키는 동일한 피어 자격 증명 아래 세션 간에 동일했다. RFC는 40비트 RC4의 약함과 이 반복성을 모두 이유로 가능하면 그 분기를 피하라고 조언했다. 비밀번호에서 도출되는 모드 전반은 보안이 비밀번호 품질을 물려받았고, EAP-TLS에서는 TLS 보안과 내보낸 비밀값의 처리를 물려받았다.

역사적 충실성은 그 경고들을 당시 시점에 유지할 것을 요구한다. 이 글은 RC4, LAN Manager 해시, 고전 MS-CHAP을 권하지 않는다. 이 글은 사양 자체가 자신의 도출이 증명할 수 있는 범위를 어떻게 한정했는지를 설명한다.

도출 경계는 암호화 서비스가 시작되기 전에 끝났다

RFC 3078은 MPPE 패킷이 전송되기 전에 PPP가 네트워크 계층 프로토콜 단계에 도달하고 CCP가 Opened 상태에 도달하도록 요구했다. 그럼에도 당사자들은 강도와 상태 모드를 협상하고, 일치하는 컨텍스트를 초기화하고, 그것들을 올바르게 진행하고, 손실에서 복구해야 했다. RFC 2548은 또 하나의 인접 문제를 다루었다: 이미 만들어진 송신·수신 키를 RADIUS를 통해 운반하는 것이며, 여기서 프록시는 보호된 속성을 복호화했다가 재암호화하면서 관리자(custodian)가 될 수 있었다.

이후의, 그리고 인접한 전이들은 RFC 3079에 압축할 수 없다. 인증 성공이 마스터 값이 PPP 인증자에 도달했다는 뜻은 아니었다. 키 자료의 접수가 그것이 올바른 링크에 배정되었다는 뜻은 아니었다. 올바른 방향 대응이 CCP가 MPPE를 선택했다는 뜻은 아니었다. Opened 상태의 CCP가 암호 상태가 동기화를 유지했다는 뜻은 아니었다. 패킷 복호화가 애플리케이션이 그것을 받아들였다는 뜻은 아니었다.

이것은 낡은 상호운용성 메모에 적용된 Lu Heng의 현실 계층 규율이다. 마스터, 송신, 수신, 인증됨, 128비트 같은 상징적 이름은 계층 사이의 변환을 숨길 수 있다. 실행 코드가 중요한 이유는 오직 실행만이 그것들을 연결하기 때문이지만, 실행 코드 또한 어떤 전이가 실제로 일어났는지 보여줄 만큼 정밀한 영수증을 필요로 한다.

RFC 3079의 역사적 기여는 공식을 공개한 것만이 아니었다. 그것은 상호운용성이 출처(provenance)에 의존한다는 사실을 드러냈다. 마스터 키는 트래픽 키가 아니었다. 방향은 한 박스에 국소적인 문자열이 아니었다. 성공한 도출은 필요한 영수증이지 서비스 전체가 아니었다.

출처