하나의 IKEv2 로그인에 두 개의 신원: 먼저 머신, 그다음 사용자

클라이언트 인증서가 검증되고, 첫 번째 교환이 완료되며, 그 직후 추가 인증 라운드에 관한 오류와 함께 연결이 멈춘다. 인증서 체인에는 잘못된 것이 없고 네트워크에도 변화가 없다. 게이트웨이는 연결하는 쪽에 두 번째 증명을 요구하도록 설정되어 있고, 클라이언트는 그것을 한 번도 보내지 않는다. 누가 무엇을 어떤 순서로 증명하는지 정하는 것이 이 작업의 전부이며, 그것은 자신이 서 있는 엔드포인트에서 정책을 읽는 데서 시작한다. 서로 다른 종류의 두 증명을 고정된 순서로 두는 것은 설계 결정이지 체크박스가 아니다.

증상: 첫 증명이 성공한 뒤의 실패

첫 번째 교환이 완료되고 로그는 건강해 보인다, 게이트웨이가 EAP로 사용자 신원을 요구할 때까지 이어진다. 그러면 핸드셰이크가 멈추거나 추가 라운드를 지목하는 프로토콜 오류가 돌아온다. 완전히 유효한 머신 인증서가 그 유효성과 무관한 이유로 거부된다. 정책은 두 번째 증명을 요구했고, 클라이언트의 응답은 끝내 도착하지 않았다.

그 실패에 대한 두 설명은 어디에 서 있는지에 따라 모두 정확하다. 클라이언트 쪽에서는 유효한 인증서를 거부하는 서버로 보이고, 서버 쪽에서는 로그인을 끝내지 못하는 클라이언트로 보인다. 같은 사건이 한 로그에서는 신뢰 문제로, 다른 로그에서는 능력 문제로 읽힌다. 어느 쪽인지 알려주는 것은 설정된 정책뿐이다.

확장이 더하는 것과 더하지 않는 것

IKEv2에는 하나의 세션 안에서 여러 번의 인증 교환을 실행하기 위한 확장이 있다. RFC 4739는 다른 순서들과 함께, 인증서 신원을 증명한 뒤 EAP로 사람을 인증하는 클라이언트를 개요로 제시한다. 문서의 상태는 Experimental이며, 어떤 구현도 이 기능을 제공할 의무가 없다. 상대가 협상하기 전까지 지원에 대해 아무것도 가정하지 마라.

양쪽이 확장을 지원하고 교환 중에 그것에 합의해야 한다. 두 번째 라운드용으로 설정된 게이트웨이는 클라이언트에게 실행을 강요할 수 없고, 지원하는 클라이언트도 서버가 요구하지 않으면 사용하지 않는다. 이 비대칭성 때문에 실패는 능력에 관한 분명한 진술 대신 보통 타임아웃이나 프로토콜 오류로 나타난다. 한쪽의 설정을 읽어도 무슨 일이 일어날지의 절반만 알 수 있다.

엔드포인트마다 하나의 증명이 일반적인 형태이며, 이것은 그 설계가 아니다. 게이트웨이가 자기 인증서를 제시하고, 사용자가 EAP로 응답하며, 각 쪽은 상대를 정확히 한 번 인증했다. 그 두 증명은 반대쪽 엔드포인트에서 오므로, 어느 것도 머신과 그것을 쓰는 사람에 대해 별개의 것을 말하지 않는다.

EAP-TLS는 세 번째 형태이며 그것도 이 설계가 아니다. 거기서는 클라이언트 인증서가 EAP 메서드 안에서 제시되므로, 클라이언트는 여전히 한 번의 IKE 인증을 완료한다. 자격 증명은 여러 라운드의 경우와 똑같아 보일 수 있지만 프로토콜은 두 번이 아니라 한 번의 라운드를 나른다. 그래서 EAP-TLS 배포에서 복사한 설계는 두 번째 증명이 기대되는 지점에서 실패한다.

같은 파일이 게이트웨이에서는 다르게 읽힌다

같은 swanctl 파일은 어디서 실행되는지에 따라 다르게 읽히며, 이것이 사람들을 넘어뜨리는 부분이다. 노트북에서는 게이트웨이가 상대이고, 게이트웨이에서는 노트북이 상대이므로 local 쪽은 내가 누구인지로, remote 쪽은 누구를 받아들일지로 써라. local 블록은 이 엔드포인트가 스스로를 어떻게 인증하는지 설명하고, remote 블록은 다른 쪽 끝에 무엇을 요구하는지 밝힌다. 두 파일 사이에서 블록을 복사하면 한 글자도 바꾸지 않고 의미가 뒤집힌다. 두 파일을 비교해도, 같은 단어가 각 파일에서 반대를 뜻하기 때문에 거의 아무것도 알 수 없다.

절의 위치는 라운드 번호가 덮어쓰지 않는 한 그 순서를 정한다. 따라서 추가 local 또는 remote 절은 대안이 아니라 추가 라운드를 서술하며, swanctl.conf 참조에 있는 명시적 라운드 번호는 바로 그 순서를 의도적으로 만들기 위해 존재한다. 그것이 없으면 블록을 옮길 때 동작이 바뀐다. 종이 위에서 동등해 보이는 두 설정이 반대 순서로 동작하는 것도 같은 이유다.

그 순서 규칙이 기억할 만한 실패 유형을 만든다. 두 번째 remote 블록은 또 하나의 허용 가능한 선택지가 아니며 두 번째 요구이므로, 둘 중 하나로 읽히는 정책이 그리고 그다음처럼 동작한다. 게이트웨이 정책은 등록된 머신의 인증서를 받아들인 뒤 그 사용자의 EAP 교환을 그 순서로 요구할 수 있다.

라운드와 독립 요인을 구별하라

두 라운드가 자동으로 두 개의 독립 요인이 되지는 않는다. 증명을 반복하거나 같은 저장소에 두 자격 증명을 두는 것은 설계가 더하려 했던 강도를 주지 않는다. 독립성은 비밀이 어떻게 보관되고 무엇이 그것을 위협하는지의 성질이며, 프로토콜이 몇 번의 교환을 하는지가 아니다. 라운드를 요인으로 세는 설계는 가진 것을 과대평가한다. 이 구분은 규정 준수 질문이 로그인이 실제로 몇 개의 요인을 쓰는지 물을 때 가장 중요하다.

머신 인증서는 받아들여진 키의 소유만 증명하고 그 이상은 아니다. 하드웨어 증명도, 기기 상태 보고서도 아니므로 상태 정보가 필요한 정책은 다른 메커니즘이 필요하다. subject 필드도, subject는 인증서를 발급하거나 등록한 쪽이 고르기 때문에 신뢰할 수 있는 자산 태그가 아니다. 설계가 머신이 건강하다는 증명을 필요로 한다면, 그 증명은 머신을 측정하는 구성 요소에서 와야 한다.

각 라운드가 실제로 무엇을 증명하는지 추가하기 전에 적어라. 두 라운드가 같은 것을 두 번 증명하면, 두 번째는 보증 대신 지연과 지원 티켓을 더한다. 그 메모는 추가 라운드가 비용에 걸맞은지에 대한 논쟁을 멈추는 것이기도 하다.

조합 규칙을 쓰고 거부를 시험하라

어떤 머신 신원이 어떤 사람과 조합될 수 있는지 정하고, 그 규칙을 적용이 사는 곳에 써라. 나란히 놓인 두 유효한 자격 증명은, 조합이 인증 결과가 아니라 권한 부여 결정이기 때문에 조합에 대해 아무것도 증명하지 않는다. 등록 기록이나 인증 백엔드가 조직이 원하는 관계를 적용해야 한다.

그다음 실패해야 할 것을 시험하라: 승인되지 않은 머신 위의 수용된 사용자, 머신 자격 증명을 가진 승인되지 않은 사용자, 추가 라운드를 수행할 수 없는 상대. 셋 모두가 조용히 같은 접근을 받는다면, 정책은 적용이 아니라 의도를 서술하는 것이다. 선언된 설정은, 한 번도 일치하지 않은 연결이 통과한 규칙과 똑같이 보이기 때문에 데몬이 보고하는 것과 비교하라.

swanctl --list-conns
swanctl --list-sas

성공한 로그인만이 아니라 협상된 라운드와 그로부터 나오는 권한 부여를 확인하라. 그리고 지름길로 옛 IKEv1 XAuth 설정에 손을 뻗지 마라: 연결이 성공할 때까지 필요한 라운드를 지우는 대신 프로토콜, 역할, 순서, 클라이언트의 실제 동작을 맞춰라. 실패하는 라운드를 지우는 것은 두 증명 설계가 아무도 검토하지 않은 한 증명 설계로 조용히 바뀌는 길이다. 삭제는 변경 기록에 남겨라.