요약

  • RFC 3983은 IRIS BEEP 채널이 프로파일 수락 이후 '준비' 상태가 된다고 규정했지만, 이 상태는 메시징 능력을 확립한 것이지 서버 신원, 사용자 신원, 레지스트리 데이터 수신 권한을 확립한 것이 아니었다.
  • 인증 자체는 계층화되어 있었다. 레지스트리 유형은 서버 인증 방법을 지정하거나, 기본 TLS 권한명 절차를 사용하거나, 아무 것도 사용하지 않는다고 명시할 수 있었다. 암호화와 사용자 인증은 별개의 조정 선택 항목이었고, 리퍼럴은 자체 자격 증명 경계를 만들어냈다.

RFC 3983에는 채널이 준비 상태가 되는 순간이 있다. 클라이언트는 하나 이상의 BEEP 프로파일을 제시했다. 서버는 하나의 프로파일을 수락했다. 채널이 생성되었다. 이제 IRIS 메시지가 그 채널을 통과할 수 있으며, 서버는 자신이 광고한 레지스트리 유형에 대한 질의를 처리해야 한다. 현대의 대시보드는 운영자에게 '준비'를 협상의 끝으로 읽도록 훈련시키기 때문에, 이 상태는 결론적인 것처럼 들린다. 그러나 이 사양에서 그것은 여러 서로 다른 질문의 시작에 불과했다.

RFC Editor 상태 기록,정오표 기록,Datatracker 이력은 2005년 1월의 Standards Track 문서임을 확인해 준다. RFC 3983은 인터넷 레지스트리 정보 서비스(IRIS)를 블록 확장 교환 프로토콜(BEEP)에 매핑했다. 이 기록들은 무엇이 표준화되었는지는 말해 주지만, 몇 개의 배포가 존재했는지 또는 어떤 서비스가 여전히 접근 가능한지는 말해 주지 않는다.

전송 계층은 기존의 기반 구조를 이유로 선택되었다. BEEP는 이미 프레이밍, 인증, 연결 관리, 협상을 다루고 있었고, 구현자에게 툴킷과 운영 경험이 제공되고 있었다. IRIS 전용 전송 계층은 유사한 구성 요소들을 새로 만들어야 했을 것이다. HTTP는 기능을 제공했지만 저자들의 견해로는 웹 애플리케이션과의 모호성과 고르지 못한 TLS 관행도 함께 가져왔다. 직접 TCP는 리퍼럴 기반 클라이언트가 서로 다른 매개변수로 운영되는 서버들 사이를 이동할 때 필요한 협상 특성이 없었다. 이것은 비교 성능 측정이 아니라 명시된 설계 판단이었다.

프로파일 식별자는 두 개의 축을 동시에 담았다. IRIS 스키마 버전과 레지스트리 유형 URN이다. 채널 생성 과정에서 클라이언트는 여러 개의 프로파일 요소를 제시할 수 있었고, 이를 통해 당사자들은 각각 제공되는 레지스트리 유형에 사용될 IRIS 버전을 협상할 수 있었다. 따라서 프로파일 수락은 합의된 메시지 컨텍스트를 확립했다. 그러나 원격 권위체가 누구인지, 사용자가 누구인지, 그 사용자가 어떤 데이터를 볼 수 있는지는 확립하지 않았다.

'질의 처리'조차도 유한한 의미를 가졌다. 레지스트리 유형은 자체 BEEP 호환 메시지 패턴을 정의할 수 있었지만, IRISlookupEntity작업에 대한 기본 패턴은 지원해야 했다. 이 기본 패턴에서 클라이언트는 유효한 IRIS XML 인스턴스를 BEEPMSG로 보내고, 서버는RPY로 IRIS XML 인스턴스를 반환하며, BEEPERR은 전송 프로파일 결함을 담는다. 응답에는 여전히 레지스트리 계층의 거부, 지원되지 않는 질의 또는 이 전송 계층 위의 계층을 기록하는IRIS 코어와 그상태 페이지가 제공하는 다른 비결과 상태가 담길 수 있었다. 준비 상태는 교환을 가능하게 만들었을 뿐, 그 답을 미리 정하지 않았다.

서버 신원에는 자체적인 규약이 필요했다. BEEP TLS 조정 프로파일을 사용할 때, 각 레지스트리 유형은 IRIS URI에 명명된 권위체를 서버가 어떻게 표현하는지 정의하는 것이 권장되었다. 그렇지 않은 경우 RFC 3983이 기본 방법을 제공했다. 클라이언트는 요청한 권위체를 BEEP의serverName에 넣었다. 서버는 그 권위체를 포함한 X.509 인증서를 반환했다. 그 인증서는 서로 다른 두 가지 검사를 통과해야 했다. TLS 하에서의 암호학적 검증, 그리고 요청된 권위체에 대한 이름 일치 검사로서, 먼저subjectAltNamedNSName을 통하고, 다음으로 지정된 주체명 형식을 통한다.

이 두 검사를 하나로 묶어서는 안 된다. 암호학적으로 유효한 인증서가 다른 이름에 대해 유효할 수 있다. 검증된 인증서 체인 없이 일치하는 문자열은 인증된 신원이 아니다. 기본 절차는 클라이언트가 도달하려 했던 권위체와 서버가 제시한 신원을 결합했다. 그것은 단순히 암호화를 켜고 나머지를 추론한 것이 아니었다.

레지스트리 정의 체크리스트는 이 분리를 명시적으로 만들었다. 이 매핑을 사용하는 모든 레지스트리 유형은 자신의 BEEP 메시지 패턴을 명시해야 했다. 또한 TLS 서버 인증 방법을 정의하거나, 기본 방법을 선택하거나, 서버 인증을 사용하지 않는다고 명시적으로 선언해야 했다. 따라서 유효한 IRIS 프로파일 URI와 수락된 채널은 서버 인증을 의도적으로 선택하지 않은 아키텍처와 공존할 수 있었다. '준비'가 '서버 인증됨'의 축약어로 쓰이는 일은 결코 있어서는 안 되었다.

사용자 신원은 또 하나의 다른 평면을 차지했다. RFC 3983은 세션 암호화 없이 사용자 인증을 수행하는 SASL DIGEST-MD5 및 OTP 조정 프로파일을 열거했다. 암호화만을 위한 TLS 암호 사용 용례, 그리고 암호화와 사용자 인증을 함께 수행하는 별도의 클라이언트 인증서 용례를 열거했다. 익명 접근은 아무 인증 조정 프로파일도 실행되지 않았음을 의미할 수도 있고, SASL 익명 프로파일이 실행되었음을 의미할 수도 있었다. 조합이 중요하다. 암호화됨은 사용자 인증됨과 동의어가 아니었다. 서버 인증됨은 사용자 인증됨과 동의어가 아니었다. 신원이 확인된 사용자가 특정 결과에 대해 자동으로 권한을 부여받는 것도 아니었다.

이 모듈성은 BEEP 자체에서 비롯되었다.RFC 3080과 그상태,정오표,Datatracker 기록은 프로파일, 채널, 메시지, 조정을 정의했다.RFC 3081과 그상태 기록은 이 프레임워크를 TCP에 매핑했다. 조정 작업은 세션의 보안 상태를 변경할 수 있었지만, 나머지 모든 상태 변수를 소급하여 하나의 판정으로 만들지는 않았다.

동시대 참고 문서들은 이 역사적 경계를 더욱 선명하게 만든다.RFC 2246과 그상태는 TLS 1.0을 규정했다.RFC 2222와 그상태 기록은 당시 인용된 SASL 프레임워크를 제공했다.RFC 2817과 그상태, 그리고RFC 2818과 그상태는 RFC 3983이 논의한 두 가지 HTTP/TLS 접근 방식을 대표한다. 이 문서들은 이용 가능한 메커니즘을 설명할 뿐, 어떤 특정 IRIS 연결이 그것들을 올바르게 사용했다는 증거가 아니다.

리퍼럴은 채널 속성들을 혼동할 때의 대가를 드러냈다. IRIS는 클라이언트가 서버들 사이를 이동하는 것을 정상적인 운영 과정으로 기대했다. RFC 3983은 클라이언트가 신뢰할 수 없는 리퍼럴 대상에게 자격 증명을 넘겨서는 안 된다고 경고했다. SASL PLAIN 사용을 권장하지 않았고, TCP 세션이 암호화되기 전에는 그 사용을 금지했다. 암호화는 전송 중 자격 증명을 보호했지만, 수신자가 그 자격 증명을 받아 마땅하다는 것을 확립하지는 않았다. 리퍼럴 대상의 신원과 신뢰는 여전히 평가되어야 했다.

이후의 전송 계층은 메시징 계층이 대체 가능한 상태로 남아 있었음을 확인해 준다.RFC 4992와 그상태 기록은 XPC TCP 전송 계층을 추가하고 IRIS 코어를 갱신하였다. 이 문서상의 순서는 어떤 구현이 왜 한 매핑을 선택했는지를 확립하지 않으며, BEEP의 채택이나 중단을 증명하지도 않는다.

현재의IANA URI Schemes 레지스트리는iris.beep등록을 보존하고 있으며,IANA BEEP Parameters 레지스트리는 프로파일과 조정 네임스페이스를 보존하고 있다. 등록은 프로토콜 이름이 할당되었다는 증거이지, 준비된 채널, 일치하는 인증서, 인증된 사용자 또는 권한 부여된 결과의 증거가 아니다.

RFC 3983의 가장 유용한 역사적 교훈은 준비 상태의 절제된 범위이다. 채널은 협상되고, 열려 있고, 능력을 갖춘 상태이면서도 신원은 부재하거나, 부분적이거나, 별도로 구성되어 있을 수 있었다. 이 모든 상태를 하나의 초록불로 압축해 버리는 운영은 아키텍처의 핵심적 정직성을 잃어버린다. 연결, 기밀성, 신원, 권위체, 결과는 서로 다른 영수증이다.

출처