요약

  • RFC 3652는 전달과 재조립에 사용되는 고정 20옥텟 메시지 엔벨로프를 24옥텟 헤더와 연산별 본문으로부터 분리했습니다. 메시지 자격 증명(Message Credential)의 디지털 서명은 엔벨로프를 보호하지 않았지만, 헤더와 본문은 보호했습니다.
  • 자격 증명은 개시자의 서명 또는 미리 확립된 세션 키에 기반한 MAC을 담을 수 있었습니다. 이 경계는 프로토콜의 무결성 범위를 설명하는 것이며, 문서화된 악용 사례, 구현 실패 또는 하위 계층 보호가 불가능하다는 주장이 아닙니다.

하나의 메시지, 서로 다른 신뢰 표면

2003년 핸들 시스템(Handle System) 프로토콜 사양은 단순한 조회 이상을 설명해야 했습니다. 클라이언트는 책임 핸들 서버를 찾아 핸들의 확인 또는 관리를 요청하고, 응답을 해석해야 했습니다. 또한 프로토콜은 데이터를 같은 방식으로 제시하지 않는 전송 계층 위에서 큰 메시지를 운반해야 했습니다. RFC 3652 v2.1은 이러한 관심사를 네 개의 인접한 조각, 즉 엔벨로프, 헤더, 본문, 자격 증명에 배치했습니다.RFC 3652

엔벨로프는 항상 존재하며 정확히 20옥텟이었습니다. RFC는 이를 애플리케이션 데이터가 아닌 전달 래퍼라고 부릅니다. 그 필드에는 프로토콜 버전과 메시지 플래그, 세션 식별자, 요청 식별자, 시퀀스 번호, 메시지 길이가 포함됩니다. 헤더 역시 필수이며 24옥텟이었고, 연산 코드와 응답 코드를 포함한 공통 연산 필드를 담았습니다. 본문은 연산별 데이터를 담으며 비어 있을 수도 있었습니다.RFC 3652

신뢰 경계는 패킷 경계를 따르지 않았습니다. RFC 3652는 메시지 자격 증명의 디지털 서명이 엔벨로프 내용을 보호하지 않는다고 명시합니다. 헤더와 본문은 보호했습니다. 비어 있지 않은 자격 증명은 개시자의 디지털 서명 또는 이미 확립된 세션 키에 기반한 단방향 메시지 인증 코드(MAC)를 담을 수 있었습니다. RFC는 자격 증명을 메시지를 인증하고 전송 중 데이터 무결성을 확인하는 방법으로 제시합니다. 이 두 메커니즘은 서로 교환할 수 없습니다. MAC은 공유 비밀에 의존하고, 디지털 서명은 다른 키 모델을 사용합니다.RFC 3652RFC 2104

이 구분은 엔벨로프가 하는 일을 고려하면 자연스러웠습니다. 핸들 클라이언트는 UDP 데이터그램이나 TCP 바이트 스트림을 사용할 수 있었습니다. RFC 3652는 UDP로 운반되는 메시지를 IP와 UDP 헤더를 제외하고 512옥텟으로 제한했습니다. 더 긴 메시지는 분할되어야 했고, 각 조각은 수신 측이 메시지를 재조립할 수 있도록 엔벨로프에 자신의 시퀀스 번호를 담았습니다. TCP가 핸들 수준의 프레이밍을 없애지 않았습니다. 바이트 스트림에도 여전히 메시지 경계가 필요했으며, 프로토콜은 더 큰 메시지를 재조립을 위해 분할할 수 있었습니다.RFC 3652RFC 768RFC 793

반면 헤더와 본문은 클라이언트와 서버가 무엇을 하고 있는지를 설명했습니다. 연산 코드는 일종의 핸들 연산을 요청했고, 응답 코드는 성공, 누락된 값, 참조, 권한 부여 실패, 인증 요구 같은 결과를 보고했습니다. 프로토콜의 서비스 모델은 별도의 핸들 네임스페이스와 데이터 모델 위에 놓였으며, RFC 3650이 전체 서비스 아키텍처를 기술했습니다. 따라서 메시지의 보호되는 의미 콘텐츠는 전달 래퍼 다음부터 시작됩니다. 조각을 구문 분석하는 것과 그 연산을 권한 부여하는 것은 같은 일이 아니었습니다.RFC 3652RFC 3650RFC 3651

인증은 권한 부여가 아니었다

RFC 3652는 클라이언트의 증명과 서버의 권한 결정도 분리했습니다. 관리 작업의 경우 서버는 챌린지를 보낼 수 있었고, 클라이언트는 개인 키 또는 공유 비밀 키의 소유를 증명하는 응답을 되돌려 보냈습니다. 그 증명을 검증한 후에도 서버는 요청된 연산에 대해 관리자가 충분한 권한을 가졌는지 확인해야 했습니다. 성공한 챌린지-응답이 그 자체로 핸들을 변경할 승인은 아니었습니다. 프로토콜은 상태와 키가 여러 연산을 지원하는 세션을 설정할 수도 있었습니다.RFC 3652

자격 증명을 설명할 때 이 구분이 중요합니다. RFC 3552는 데이터 무결성, 피어 인증, 기밀성, 시스템 보안을 서로 다른 목표로 다룹니다. 서명이나 MAC이 그 모든 것을 자동으로 제공하지는 않습니다. RFC 3652 자체의 보안 절은 서버 서명과 클라이언트 인증을 다루지만, 형식 정의는 더 좁습니다. 자격 증명은 헤더와 본문을 다루며, 전달 엔벨로프는 다루지 않습니다. 그 문장 자체만으로 공개 배포된 시스템에서 공격자가 메시지를 변경했다는 사실이 확립되지 않습니다. 하위 계층 채널이 다른 보호를 제공할 수 있으며, 이 RFC는 사고 보고서가 아니라 프로토콜 사양입니다.RFC 3552RFC 3652

또한 핸들 자격 증명을 X.509의 인증서 및 폐기 목록 서명 프로파일과 혼동해서는 안 됩니다. RFC 3279는 그 PKI 프로파일을 위한 알고리즘 식별자와 인코딩을 정의합니다. 이는 RFC 3652의 서명 바이트 범위를 넓히거나 그 엔벨로프를 보호되는 콘텐츠로 만들지 않습니다. 이는 암호학 용어와 실제로 인증되는 대상 사이의 유용한 경계입니다.RFC 3279RFC 3652

RFC 3652는 Informational로 표시되어 있으며, IESG 노트는 핸들 시스템과 그것의 IETF 식별자 아키텍처와의 적합성에 대해 논의가 IETF 합의에 이르지 못했다고 밝힙니다. 이 문서는 보편적 채택의 증거가 아니라 제안된 시스템 프로토콜을 기록합니다. 그 지속적인 교훈은 더 소박합니다. 하나의 메시지가 서로 다른 규칙에 따라 프레이밍되고, 재조립되고, 인증될 수 있으므로 무결성에 대한 어떤 주장도 자격 증명이 실제로 다루는 바이트가 무엇인지 명시해야 합니다.RFC 3652

출처