요약

  • RFC 2989는 AAA 프로토콜 제안서를 역량 기준으로 평가했으며, 필수 역량이 모든 교환에서 그 역량을 사용해야 한다는 뜻은 아니었습니다.
  • 이 문서는 하나의 체크리스트 행을 보편적 배포 정책인 것처럼 꾸미는 대신, NASREQ·ROAMOPS·Mobile IP의 서로 다른 요구를 그대로 보존했습니다.
  • 전송 전달, 구문 및 의미 평가, 회계 책임, 권한 부여 효과, 실제 제공된 서비스는 각각 별개의 영수증이었습니다.

관할권을 가진 표

RFC 2989는 IETF의 AAA 워킹그룹이 여러 세계의 요구를 비교하려던 시점에 등장했습니다. 다이얼 접속 서버, 로밍 컨소시엄, Mobile IP 시스템 모두 인증·권한 부여·회계를 필요로 했지만, 동일한 토폴로지, 위협 모델, 운영 부담을 제시하지 않았습니다.

따라서 이 문서는 새로운 유선 프로토콜을 정의하는 것으로 시작하지 않았습니다. NASREQ, ROAMOPS, MOBILEIP, TIA 45.6에서 수집한 요구를 요약했습니다. 일반 기준은 인증, 권한 부여, 회계, Mobile IP 전용 표와 나란히 놓였습니다. 열에는 출처 커뮤니티가 유지되었고, 셀에는 MUST, SHOULD, MAY, MUST NOT, SHOULD NOT에 해당하는M,S,O,N,B가 사용되었습니다.

이 형식은 조달 점수표처럼 보이며, 배포된 사실의 목록으로 오해하기 쉽습니다. 1.1절이 이를 막았습니다.

이 요구는 프로토콜 제안서를 평가하기 위한 것이라고 문서는 밝혔습니다. 규범적 용어는 역량을 지칭했습니다. 자신이 구현한 역량에 대한 필수 요구를 충족하지 못하는 프로토콜 제안서는 비준수였습니다. 모든 MUST와 MUST NOT을 충족하면서 권고를 놓친 제안서는 조건부 준수였습니다. SHOULD와 SHOULD NOT 행까지 충족하면 무조건부 준수였습니다.

이것은 설계에 대한 범위가 한정된 판단이었지, 가동 중인 네트워크의 보고가 아니었습니다.

이 문서는 기밀성으로 이 구분을 구체적으로 보여주었습니다. 프로토콜이 기밀성을 지원하도록 요구하는 것은 모든 프로토콜 트래픽을 암호화하라고 요구하는 것과 같지 않았습니다. 검토자는 후보가 적합한 보호 메커니즘을 갖추었음을 증명할 수 있었습니다. 그 증명이 어느 운영자가 활성화했는지, 어떤 객체를 대상으로 하는지, 어떤 피어와 협상했는지, 어떤 키를 사용했는지, 어떤 패킷이 보호된 채널을 지나갔는지는 밝혀주지 않았습니다.

체크리스트는 제안서에 관할권을 가졌고, 배포는 사용에 관할권을 유지했습니다.

세 개의 열은 하나의 정책이 아니었다

일반 표는 출처 열이 왜 중요한지 보여주었습니다. 확장성은 NASREQ, ROAMOPS, Mobile IP 전체에서 필수였습니다. 장애 조치는 NASREQ와 Mobile IP에서는 필수로 표시되었지만 ROAMOPS에서는 동일하게 표시된 요구가 아니었습니다. IPv4 지원은 세 곳 모두에서 필수였고, IPv6와 인증서 전송은 서로 다른 강도를 지녔습니다. 감사 가능성은 NASREQ 권고로 나타났습니다.

빈 셀은 해당 기능이 쓸모없다는 뜻이 아니었습니다. 필수 셀이 모든 설치에 모든 거래에서 그것을 수행하라고 명령하는 것도 아니었습니다. 이 행렬은 각 요구 프로세스가 후보 프로토콜에 무엇을 요구했는지를 보존했습니다.

그것은 일종의 최소 초기 명세였습니다. 공유 계층은 비교와 상호 운용에 필요한 충분한 역량을 명명하면서, 각 운영자의 미래 결정을 정해준 것처럼 꾸미지 않았습니다. 열 없이 표를 읽는 비용은 제도적인 것입니다. 지역 정책이 보편적 요구인 척하기 시작하거나, 문서에 나열된 보편적 역량이 단지 목록에 있다는 이유로 운영 중인 것처럼 가정되기 때문입니다.

RFC 2119 어휘는 정의된 범위 안에서 의무를 명확히 했습니다. 범위 자체를 확대하지 않았습니다. 프로토콜 역량에 붙은MUST는 그 역량에 관한 진술로 남았습니다.

보안은 서로 다른 경계에서 끝나고 지속되었다

RFC 2989는 전송 수준 보안과 객체 수준 보안을 인접한 행에 두었지만, 서로 다른 보관을 기술했습니다.

전송 수준 보안은 홉별(hop-by-hop)이었습니다. 통신하는 두 AAA 피어는 채널을 인증하고 무결성을 보호하고 암호화할 수 있었습니다. 수신 AAA 엔티티가 메시지를 처리하면 그 보안 계층은 제거되었고, 다음 홉은 새로운 관계를 수립했습니다.

반면 객체 수준 기밀성은 메시지가 프록시나 브로커를 통과하는 동안에도 최종 목적지를 위해 하나 이상의 속성을 보호할 수 있었습니다. 객체 수준 인증과 무결성은 중간 AAA 엔티티를 거쳐도 지속되도록 설계되었습니다. 보호된 데이터는 그 중간자가 수정할 수 없었습니다.

두 메커니즘 모두를 지원한다는 것이 그것의 런타임 조합을 증명하지는 않았습니다. 구현이 코드를 포함하면서도 한 경로를 구성하지 않고 두었을 수 있습니다. 프록시가 한 보안 홉을 종료하면서 객체 봉투를 유지할 수도 있습니다. 선택된 객체 집합에 감사자가 중요하게 여기는 필드가 없을 수 있습니다. 키가 오래되었을 수 있습니다. 검증이 실패하고 로컬 폴백을 촉발할 수 있습니다.

기준은 프로토콜이 무엇을 가능하게 해야 하는지를 검토자에게 알려주었습니다. 실제로 무슨 일이 있었는지는 키, 구성, 추적, 검증 결과만이 보여줄 수 있었습니다.

전달은 해석이 아니었다

신뢰할 수 있는 전송에 대한 명시는 이 문서에서 가장 깔끔한 증거 경계입니다.

RFC 2989는 단일 전송 홉을 넘는 복원력을 요구했습니다: 홉별 재전송과 장애 조치, 재전송에 대한 애플리케이션 제어, 함께 실린(piggybacked) 확인 응답, 적시의 AAA 응답. 또한 메시지가 성공적으로 전달되었음을 알리는 전송 확인 응답을 명명했습니다.

그다음 이 확인 응답을 메시지 의미론 및 구문 평가와 분리했습니다.

수신자는 전송 경계에서 바이트나 메시지 단위를 확인 응답한 뒤, 나중에 인코딩, 속성 집합, 상태 전이 또는 권한 요청을 거부할 수 있었습니다. 프록시는 메시지를 로컬에서 수용하면서 다음 홉이 실패할 수 있었습니다. 백업 서버는 세션 상태가 동기화되지 않은 채 도달 가능할 수 있었습니다. 응답이 제시간에 도착하면서도 거부를 담고 있을 수 있었습니다.

따라서 신뢰성에는 하나의 성공 비트 이상이 필요했습니다. 운영자는 시도 식별자, 홉, 재전송, 장애 조치 선택, 전송 수신 증명, 파싱 결과, 의미 결정, 하류 조치를 보존해야 했습니다.

이 구분은 신뢰할 수 있는 전송을 약화시키지 않았습니다. 전송이 만들지 않은 결정으로부터 전송을 보호한 것입니다.

책임에는 다른 확인 응답이 필요했다

회계 표는 다시 전달(delivery)이라는 단어를 사용했지만, 그 명시는 영수증을 위로 올렸습니다.

보장된 회계 전달에는 애플리케이션 계층 확인 응답이 필요했습니다. RFC 2989는 이를 수신 서버가 메시지 데이터에 대한 책임을 지려 할 때 보내지는 것으로 기술했습니다.

그것은 전송 도착 이상이었지만, 여전히 최종 청구서나 서비스의 참된 상태에는 미치지 못했습니다.

서버는 영구 복제 이전에 보관을 수용할 수 있었습니다. 기록은 나중에 다른 임시 기록과 충돌할 수 있었습니다. 타임스탬프가 모호할 수 있었습니다. 동적 재권한 부여는 하나의 세션에 여러 회계 기록을 만들 수 있었습니다. 수집된 사용량은 청구가 되지 않고도 감사나 비용 배분을 지원할 수 있었습니다. RFC 2989는 청구(billing)를 별도로 청구서 작성으로 정의했습니다.

책임 수용, 저장, 조정, 요율 산정, 청구서 작성, 지불, 고객 경험은 하나의 연쇄였습니다. 애플리케이션 확인 응답은 그중 한 고리를 닫았습니다.

감사 가능성은 행동을 지켜보았지, 정당성이 아니었다

이 문서는 감사 가능한 프로세스를, AAA 패킷이 홈 AAA 서버에서 네트워크 장치로 왕복하는 동안 수행된 행동을 확정적으로 판별할 수 있는 프로세스로 정의했습니다.

이 목표가 중요한 이유는 프록시들이 서로 다른 권한을 가졌기 때문입니다. 로컬 프록시는 응답을 전달하기 전에 지역 정책을 집행할 수 있었습니다. 투명 프록시는 전달되는 정보에 추가·삭제·수정이 없다는 것으로 정의되었습니다. 프록시 브로커는 메시지 경로 안에 있었고, 라우팅 브로커는 당사자들이 직접 서로 연락할 수 있게 하는 정보를 반환할 수 있었습니다.

감사 추적은 그 행동을 기록할 수 있었습니다. 그 존재 자체만으로는 행동이 허용되었는지, 정책이 공정했는지, 주장이 올바른 사람을 식별했는지, NAS가 반환된 제한을 적용했는지, 구독자가 서비스를 받았는지를 증명할 수 없었습니다.

감사 가능성은 변환과 보관에 대한 증거입니다. 정당성과 결과에는 그만의 시험이 필요합니다.

인증, 권한 부여, 회계는 동의어가 아니었다

RFC 2989의 용어는 또 하나의 흔한 혼동을 막았습니다.

인증은 상호 알려진 이름공간에서 주장된 신원을 메시지 발신자 또는 채널 종단으로 검증했습니다. 권한 부여는 자격 증명 제시자에게 권리를 부여할 수 있는지를 결정했습니다. 회계는 분석, 감사, 청구, 비용 배분을 위해 자원 사용 정보를 수집했습니다.

인증 표는 심지어 프로토콜이 모든 권한 교환에서 사용자 자격 증명을 요구하지 않도록 요구했습니다. 식별 또는 주장(assertion)이 권한 부여를 지탱할 수 있었습니다. 그 역량이 그 주장을 스스로 인증되는 것으로 만들지는 않았습니다. 프로토콜이 그 증명이 다른 곳에서 수립되었을 수 있는 결정을 전달해야 한다는 의미였습니다.

권한 부여 표에는 거부 능력, 접근 규칙, 재권한 부여, 상태 조정, 연결 해제 요청이 포함되었습니다. 각각은 통제 표면이었으며, 어느 것도 NAS가 결정을 실행했거나 원하는 네트워크 효과가 뒤따랐다는 증거가 아니었습니다.

체크리스트의 지속되는 교훈

RFC 2989는 요구 문서였기 때문에 실패하지 않았습니다. 그 절제가 성과였습니다.

이 문서는 이질적인 요구를 공통 비교 표면으로 모으면서, 그 표면이 말할 수 없는 것을 밝혔습니다. 역량은 호출이 아니었습니다. 전송 도착은 해석이 아니었습니다. 애플리케이션 보관은 청구가 아니었습니다. 감사 가능성은 정당성이 아니었습니다. 권한 부여는 실제 제공된 접속이 아니었습니다.

Lu Heng의 현실 계층 관점은 이 역사적 경계를 드러냅니다. 요구 출처, RFC 본문, 프로토콜 역량, 구현, 구성, 메시지, 중간자 행동, 결정, 장치 효과, 사용자 결과는 연결된 사실입니다. 한 계층에서의 권위는 다른 모든 계층을 위해 침묵 속에서 증언할 수 없습니다.

가동 코드가 빠진 영수증을 제공합니다. 배포된 시스템은 어떤 기능이 선택되었는지, 어느 경계가 그것을 확인했는지, 어떤 정책이 작동했는지, 어떤 상태가 바뀌었는지, 어떤 결과가 관찰되었는지를 보여주어야 합니다.

체크리스트는 후보를 평가했습니다. 네트워크는 여전히 증거를 만들어야 했습니다.

출처