요약

  • RFC 3157은 기밀성과 무결성을 보호하기 위해 자격 증명 이동성을 요구했지만, 암호화된 저장을 신뢰의 부재로 다루지는 않았다. 자격 증명 서버는 보호된 키를 사용할 수 없는 상태로 남으면서도 그 가용성과 수명 주기에 대한 권력을 계속 쥐고 있을 수 있었다.
  • 이 요구사항은 서버 기반 이전과 장치 간 직접 이전을 모두 지원했다. 전자는 내구성 있는 저장과 정책을 한 곳에 모았고, 후자는 그 집중을 기기 쌍, 인증, 접수 확인이라는 복잡성과 맞바꿨다.
  • 성공적인 업로드, 다운로드 또는 인증된 응답은 그 이름이 가리키는 조작만 증명한다. 안전한 목적지 저장, 다른 사본의 삭제, 이후 행동에 대한 권한, 상대의 수용, 응용 결과는 증명하지 않는다.

하나의 신원이 한 대의 기기를 넘어 살아남기 시작했다

단순한 모델은 물리적으로 이해하기 쉬웠다. 사용자가 한 데스크톱에서 키 쌍을 생성하고, 공개 부분을 인증 기관에 보내며, 개인 키는 그 기기에 보관한다. 키는 이동하지 않았다. 기기, 로컬 저장소, 신원이 하나의 운명을 공유하는 것처럼 보였다.

2001년 무렵 이 모델은 압박을 받기 시작했다. 같은 사람이 사무실에서는 데스크톱으로, 이동 중에는 노트북으로 메일에 서명할 수 있었다. 누군가는 전화기나 양방향 호출기에서 메일을 복호화해야 했다. 라우터가 교체되더라도 그 피어들은 여전히 기존 공개 키에 의존했다. 섀시만 바뀌었다고 모든 피어를 재설정하는 것은 조율 비용을 요구했다.

RFC 3157은 이 더 넓은 문제를 자격 증명 이동성이라 불렀다. 자격 증명에는 개인 키, 신뢰 루트, 티켓, 개인 보안 환경(Personal Security Environment)의 개인 부분이 포함되었다. 그 후속 사용은 S/MIME, IPsec, TLS를 지원할 수 있었지만, 이 요구사항 문서는 그런 시스템을 재정의하지 않았다. 그 대상은 다른 장치가 이미 확립된 보안 신원을 이어가도록 하는 재료를 안전하게 옮기는 일이었다.

“신원을 옮긴다”는 표현은 라우터 사례에서 유용했지만, 문자 그대로 읽으면 위험했다. 실제로 옮겨지는 것은 자격 증명 재료이며, 의존 당사자들의 기존 규칙 아래에서 연속성을 입증하는 능력이었다. 기존 장치, 새 섀시, 관리자, 자격 증명 발급자, 피어 설정, 실행 중인 트래픽은 서로 다른 대상으로 남았다. 복사된 키는 하나의 암호학적 관계를 보존할 수 있었지만, 주변의 모든 권위가 그것을 따른다는 것은 증명하지 않았다.

프레임워크는 두 아키텍처를 모두 살려두었다

RFC 3157은 SACRED 프레임워크가 자격 증명 서버 방식과 직접 이전 방식을 모두 지원하도록 요구했다. 이는 두 개의 네트워크 다이어그램 사이의 외양적 선택이 아니었다. 각 아키텍처는 권력과 실패를 다르게 배치했다.

자격 증명 서버는 저장소 앞에 놓이며 보안 강제에 적극적으로 참여했다. 장치는 보호된 자격 증명을 업로드하고, 임의의 기간 동안 사용 가능한 상태로 두고, 나중에 다른 장치로 다운로드할 수 있었다. 이 모델은 익숙한 클라이언트-서버 프로토콜과 비슷했다. 내구성 있는 저장과 조직이 일관된 처리 정책을 강제할 장소를 제공할 수 있었다.

그 편의는 집중된 의존성을 만들었다. 서버는 운영되고, 신뢰성이 확보되고, 방어되어야 했다. 사용자는 서버를 발견하거나 설정해야 했다. 저장소는 복제하거나 손상시키거나 서비스 불능으로 만들 가치가 있는 대상이 되었다. 조직은 정책 일관성을 얻을 수 있었지만, 여행자는 새 장치가 자격 증명을 필요로 하는 바로 그 순간에 같은 중심점이 접근 불가능하다는 것을 발견할 수도 있었다.

직접 이전은 중개자에서의 장기 저장을 제거했다. 네트워크 노드는 여전히 패킷을 전달할 수 있었지만, 그렇다고 해서 자격 증명 서버가 되는 것은 아니었다. 비용은 바깥으로 옮겨갔다. 장치들은 형식, 인터페이스, 인증 방식, 전송 지원, 동시 온라인 가능성에서 달랐다. 각 측은 상대에 대한 확신이 필요했고, 전달이 중요하다면 송신자는 신뢰할 수 있는 접수 확인이 필요했다.

요구사항은 어느 아키텍처도 보편적으로 옳다고 선언하지 않았다. 한 구현이 한 쪽의 이점을 주장하면서 다른 쪽의 권력을 몰래 상속하는 일을 막기 위해, 이 구분은 유지되었다.

암호문이 서버를 무력하게 만들지는 않았다

일반 요구사항 중 하나는 의도적으로 좁게 쓰였다. 프로토콜은 최종 사용자의 장치 외부 어디에서도 자격 증명이 평문으로 나타나도록 강제해서는 안 된다는 것이었다. 이는 기밀성 경계였다. 이전 설계가 저장이나 전달을 위해 서버가 모든 개인 키를 풀어놓도록 요구하는 것을 막았다.

그러나 이것이 서버에 권력이 없다는 뜻은 아니었다. 저장소 운영자는 여전히 어떤 객체가 존재하는지, 발견될 수 있는지, 어느 버전이 반환되는지, 업로드가 그것을 대체하는지, 삭제 조작이 제거하는지를 통제할 수 있었다. 접근 권한을 가진 사람이 사용 가능한 개인 키를 도출하지 못하면서도 서버의 사본을 지울 수 있었다.

“자격 증명 삭제”조차도 경계를 갖는 의미가 필요하다. 저장소 레코드를 지운다고 해서 모든 장치 사본, 백업, 캐시, 내보내기가 사라졌다는 증거는 되지 않는다. 외부 신원이 파괴되는 것도 아니다. 피어들은 공개 키를 유지할 수 있고, 다른 개인 키 사본이 남아 있을 수 있다. 증명되는 사건은 하나의 조작 아래에서 하나의 저장소가 변형된 것이다.

가용성 역시 공개와 별개였다. RFC 3157은 자격 증명 서버를 주요 서비스 거부(DoS) 표적으로 묘사했다. 운영자나 공격자가 키를 읽는 것을 막는다고 해서 사용자가 필요할 때 키를 획득할 수 있다는 보장은 되지 않았다. 기밀이지만 접근 불가능한 재료는 서명된 메일 워크플로, 라우터 교체 또는 신원 연속성에 대한 다른 의존을 여전히 중단시킬 수 있었다.

이것이 이 문서의 가장 지속적인 경계다. 암호학적 비밀성은 보호된 재료를 누가 배우거나 사용할 수 있는지를 제한한다. 누가 그것을 감추거나, 교체하거나, 롤백하거나, 삭제하거나, 제공을 거부할 수 있는지를 자동으로 제한하지는 않는다.

조작 이름이 접수 증명을 정의했다

서버 모델에는 단일한 “동기화” 동사보다 많은 것이 필요했다. RFC 3157은 사용자가 저장된 자격 증명을 관리하기 위한 조작을 요구했다. 목록 조회, 자격 증명 추가, 삭제, 인증 정보 변경이 그것이다. 셀프 등록 지원도 요구하고, 관리자 대량 초기화도 허용했다.

각 조작은 서로 다른 권한 표면을 가졌다. 목록 조회는 비밀 평문이 아니라 재고를 드러냈다. 다운로드는 객체를 장치에 공개했다. 업로드는 서버 상태를 만들거나 대체했다. 삭제는 서버 측 상태를 제거했다. 비밀번호 변경은 미래의 인증 경계를 바꿨다. 셀프 등록은 계정 관계를 수립했다. 하나의 성공한 조작이 다음 조작을 승인하지는 않았다.

다운로드 전의 사용자 인증은 프로토콜의 계정 모델 아래에서 누가 접근을 요청하는지에 관한 경계를 갖는 질문에 답했다. 서버 인증은 클라이언트가 비밀을 넘겨주거나 사칭자로부터 자격 증명을 받아들이는 것을 막는 데 도움이 되었다. 자격 증명 인증은 이전되는 객체의 치환 또는 손상을 감지하는 데 도움이 될 수 있었다.

그런 검증들도 목적지 기기가 신뢰할 수 있다는 것을 증명하지는 못했다. 정확한 사용자가 침해된 소프트웨어에서 인증할 수 있었다. 진짜 서버가 오래되었지만 유효한 보호 객체를 전달할 수 있었다. 암호학적으로 진본인 자격 증명이 나중에 사람이 승인하지 않은 행동에 사용될 수 있었다. 신원 증명, 객체 무결성, 장치 확신, 행동 허가는 서로 다른 결정으로 남았다.

이후 RFC 3767 프로토콜은 또 하나의 구분을 명시했다. 계정 비밀번호는 서버 접근을 인증할 수 있고, 별도의 자격 증명 비밀번호는 다운로드된 자격 증명의 일부를 보호할 수 있다는 것이었다. 둘을 혼동하면 하나의 성공한 검증이 실제보다 더 큰 권한을 갖게 된다.

불투명한 형식은 조율을 좁혔지만 증거를 넓히지는 않았다

RFC 3157은 자격 증명 유형과 내부 형식이 이전 피어에게 불투명하도록 요구했다. 프로토콜은 모든 개인 키, 티켓, 보호 컨테이너를 이해하는 데 의존해서는 안 되었다. 서로 다른 사용자 인증 방식과 전송 수단도 허용해야 했다.

이는 최소 공통 표면이었다. 두 시스템이 보호된 객체를 옮기기 전에 필요한 의미론적 합의의 수를 줄였다. 제약된 장치는 같은 프레임워크에 참여한다는 이유만으로 다른 장치의 내부 표현을 채택할 필요가 없었다.

불투명성은 검증이 아니었다. 이해하지 않고도 객체를 저장할 수 있는 서버는 목적지 응용이 그것을 파싱할지, 담긴 알고리즘이 여전히 허용되는지, 인증서 체인이 여전히 검증되는지, 자격 증명이 의도된 계정과 맞는지를 추론할 수 없었다. 이식성을 높인 바로 그 추상화가 중간 성공이 증명할 수 있는 범위를 제한했다.

필수 지원(Mandatory-to-support) 선택은 상호운용성의 바닥을 제공했다. 모든 제품이 모든 자격 증명 유형, 인증자, 전송을 지원한다거나, 자칭 두 구현이 작동하는 조합을 공유한다는 증거는 아니었다. 실제 사용되는 경로는 협상과 실행되는 교환만이 확립할 수 있었다.

직접 이전에는 인증된 마침이 필요했다

저장소가 없으면 송신자와 수신자는 다른 체인을 수립해야 했다. RFC 3157은 수신 장치가 송신 장치를 인증할 수 있어야 한다고 말했다. 수신 후에는 수신자가 송신자가 인증할 수 있는 응답을 돌려보낼 수 있어야 했다.

그 응답이 중요한 이유는, 침묵은 여러 상태를 구분할 수 없게 만들기 때문이다. 객체가 아직 전송 중일 수도, 거부되었을 수도, 손상되었을 수도, 저장되었을 수도, 도착 후 잃어버렸을 수도 있었다. 인증된 접수 확인은 불확실성을 좁혔다. 프로토콜 아래에서 참여하는 피어가 자격 증명을 받았음을 인정한 것이다.

그러나 배타성은 증명하지 않았다. 송신자는 다른 사본을 유지할 수 있었다. 중개자가 암호문을 가로챘을 수 있었다. 수신자가 내구성 있는 저장 전에 응답할 수 있었고, 약한 환경에 저장할 수도 있었다. 이후 응용이 그것을 거부할 수도 있었다. 장치가 유효한 인증 재료를 갖고 있었음에도 사용자는 그 조작을 의도하지 않았을 수도 있었다.

접수 확인 후에만 원본을 삭제하는 것은 별개의 정책이자 별개의 관찰 가능한 행동이다. 전체 순서를 “이동”이라고 부르면, 사용 가능한 두 사본이 공존하던 기간이나 어느 쪽도 좋은 사본을 남기지 못하는 실패 양상이 숨겨질 수 있다.

감사는 두 번째 공개 경로가 될 수 있었다

RFC 3157은 구현, 특히 서버에 보안 관련 사건의 감사를 요구했다. 유용한 기록에는 시간, 계정, 조작, 결과가 포함될 수 있었다. 이런 증거는 시도된 다운로드와 완료된 다운로드, 사용자의 삭제와 저장소의 실패, 일반적인 가용성 상실과 공격을 구분하는 데 도움이 되었다.

문서는 또한 감사 경로가 자신이 보호하려던 비밀을 수집하지 않도록 경고했다. 사용자가 실수로 사용자 이름 필드에 비밀번호를 입력할 수 있다. 원시 입력이 로그에 복사된다면, 시스템은 조작에서 가장 덜 보호되고 가장 널리 복제되는 부분에 자격 증명을 보존하게 된다.

이 긴장은 “모든 것을 로그에 남기는” 것으로 해결되지 않는다. 내구성 있는 접수 기록에는 조사에 필요한 충분한 신원과 조작 문맥이 있으면서도 비밀번호, 개인 키, 기타 재사용 가능한 비밀 재료는 배제되어야 한다. 로그 자체도 접근, 무결성, 보존, 시계 증거가 필요하다.

“다운로드 성공”이라는 감사 기록은 어느 보호 객체가 어느 저장 표면에 도달했는지 증명하지 않는다. 완전한 조사는 그 기록을 보호 페이로드의 신원, 프로토콜 전송 기록, 목적지 장치, 로컬 임포트, 이후 사용, 응용 결과와 연결한다.

하드웨어 격리는 다른 질문에 답했다

부록은 스마트 카드와 기타 하드웨어 토큰을 고려했다. 자격 증명이 휴대용 하드웨어 안에 머문다면, 사용자는 호스트 간에 개인 재료를 복사하지 않고 토큰을 호환 장치들 사이에서 옮길 수 있었다. 일부 환경에서 이는 더 강한 격리 모델을 제공했다.

그러나 보편적 대체는 아니었다. 모든 장치가 같은 리더를 가진 것은 아니었다. 토큰에는 비용, 호환성, 실패 양상이 있었다. 조직은 운영상의 이유로 그것을 거부할 수 있었다. SACRED 방식의 프로토콜은 토큰을 물리적으로 관리자에게 돌려보내지 않고도 토큰의 자격 증명을 갱신하는 방식으로 하드웨어를 보완할 수도 있었다.

따라서 RFC 3157은 주요 요구사항을 소프트웨어 기반 자격 증명으로 한정하고 그 서로 다른 보안 자세를 인정했다. 정직한 비교는 “하드웨어는 안전하고 소프트웨어는 불안전하다”가 아니라, 어느 재료가 어느 경계를 넘는지, 어떤 장치가 참여할 수 있는지, 실패와 복구가 어떻게 작동하는지, 어느 당사자가 연속성을 끊을 수 있는지에 관한 것이었다.

요구사항 문서는 어떤 스마트 카드, 전화기, 호출기, 워크스테이션이 안전하다는 것을 증명하지 않았다. 물리적 격리 옵션이 없거나 불충분할 때 미래 프로토콜이 사용할 수 있는 아키텍처를 기술한 것이다.

이후 프로토콜은 이 공간에서 하나의 경로만 구현했다

RFC 3760은 나중에 추상 프레임워크를 제공했고, RFC 3767은 XML 메시지와 BEEP 프로필을 갖춘 표준 트랙 자격 증명 서버 프로토콜을 정의했다. 이는 전송 및 인증 요구사항을 충족하기 위해 TLS 및/또는 DIGEST-MD5 지원을 사용했고, 런타임 검색을 선택적 계정 관리 조작과 구분했다.

이 계보는 명세 작업이 문제에서 프레임워크로, 그리고 구체적인 프로토콜로 이동했음을 보여준다. 그러나 RFC 3157의 모든 요구사항이 배치되었거나, 직접 이전이 보편화되었거나, 특정 제품이 자격 증명을 올바르게 보호했다는 것을 보여주지는 않는다.

RFC 3767의 오프라인 사전 공격에 대한 우려 역시 접수 경계를 보여준다. 프로토콜이 도청자에게 유용한 비밀번호 검증 재료를 주지 않더라도, 비밀번호 품질, 단말 소프트웨어, 서버 가용성, 올바른 자격 증명 암호화에 여전히 의존한다. 한 공격에 대한 저항이 보편적인 계정 안전을 부여하지는 않는다.

RFC 3157의 역사적 가치는 무엇을 압축하지 않았는가에 있다. 이전 기밀성, 저장소 권력, 내구성 있는 가용성, 장치 인증, 접수 확인, 저장, 신원 연속성, 이후 사용은 서로 관련되어 있었지만, 그중 어느 것도 다른 것의 동의어가 아니었다.

이동하는 자격 증명은 증거 표면을 넓혔다

기존의 한 대 기기 모델은 위험을 한 곳에 모았다. 이동성은 복구 가능성과 편의를 높였지만 더 많은 전환점을 만들었다. 모든 업로드, 저장소 변형, 다운로드, 직접 전달, 임포트, 사용은 신원이 복제되거나, 감춰지거나, 치환되거나, 오해될 수 있는 지점이 되었다.

내구성 있는 감사는 자격 증명의 발급자와 보호 객체의 지문에서 시작한다. 이전이 서버 기반인지 직접인지 식별하고, 사용자·서버·장치 인증을 각각 기록하고, 요청된 조작을 명명하고, 버전과 무결성 증거를 보존하고, 저장소 상태와 가용성을 기록하고, 목적지 장치와 신뢰 소프트웨어 가정을 식별하고, 자격 증명이 의존 프로토콜과 서비스 결과로 이어지는 것을 따라간다.

라우터가 기존 키를 수용하고 트래픽이 재개되면, 그것은 성공한 다운로드보다 더 많은 것을 증명한다. 새 장치가 키를 저장했지만 피어들이 거부했다면, 전송 성공은 신원 연속성을 회복하지 않은 것이다. 피어들이 수용했지만 무단 관리자가 이전을 시작했다면, 암호학적 연속성은 관리 권한을 공급하지 않은 것이다.

RFC 3157의 지속적인 통찰은 단순히 키가 이동할 수 있다는 것이 아니다. 이동 중 비밀을 보호하는 것이 그것이 도착하고, 살아남고, 의미를 갖는지를 통제하는 기관과 기계를 소멸시키지는 않는다는 것이었다. 서버는 평문을 몰라도 강력하기에 충분했다.

출처