IKEv1의 하이브리드 인증이 IKEv2의 사용자 인증으로 어떻게 옮겨가는가

서버 인증서를 먼저 요구하고 그다음 사용자 이름을 요구하는 모든 구형 VPN 프로필은 한 번의 교환 안에 두 개의 인증 사건을 담고 있으며, 그 형태는 그것을 도입한 프로토콜보다 오래 살아남는다. IKEv1의 하이브리드 모드는 게이트웨이가 공개 키로 자신을 증명하고 사용자는 나중에 XAuth로 자신을 증명한다. IKEv2는 같은 두 단계 개념을 다른 기계장치로 표현하며, 마이그레이션이 실패하는 지점이 바로 그 차이다. 어떤 버전 번호도 하나를 다른 하나로 바꿔 주지 않으며, 옛 옵션 이름을 새 프로필에 복사하면 협상은 하지만 아무것도 인증하지 못하는 클라이언트가 된다.

하이브리드 모드가 IKEv1 안에서 한 일

하이브리드 프로필에서 응답자는 첫 단계 교환을 자신의 인증서로 서명하고, 개시자는 의도적으로 아무 인증서도 제시하지 않는다. 따라서 신원 증명은 비대칭이며, 이것이 게이트웨이가 기존 PKI를 유지하고 사용자가 디렉터리 암호를 유지하게 해 주었다. 첫 단계가 끝나면 XAuth가 요청과 응답으로 동작하며, 이미 암호화된 ISAKMP 채널 안에서 사용자 이름과 암호 속성을 나른다.

신뢰가 어디에 떨어지는지 보라. 인증서는 클라이언트가 어느 게이트웨이에 도달했는지 답한다. XAuth는 어느 사용자가 접근을 원하는지 답한다. 어느 것도 다른 것을 대신하지 못하며, 아무 서버 인증서나 받아들이도록 설정된 클라이언트는 첫 번째 답을 조용히 버린 것이다. 하이브리드라는 이름은 사전 공유 키를 쓰는 공격적 모드와 XAuth의 조합에도 쓰이는데, 사용자 경험은 같지만 구성이 다른 배열이므로 이름이 아니라 프로필을 읽어야 하며, 두 변형 모두 표준이 되지 못한 초안에서 나왔으므로 두 벤더가 하이브리드 모드를 구현하고도 서로 연동하지 못할 수 있다.

IKEv2가 같은 두 증명에 이르는 방식

IKEv2는 작업을 IKE_SA_INIT과 IKE_AUTH로 나눈다. 첫 교환은 신원 없이 제안과 키를 합의하고, 두 번째는 IDi, IDr, AUTH 페이로드를 나른다. EAP 아래에서 개시자의 첫 AUTH 페이로드는 비어 있는 채로 나가고, 응답자가 인증서와 서명으로 먼저 인증한 뒤 EAP 대화가 IKE_AUTH 메시지 안에서 진행된다.

이를 안전하게 만드는 장치는 키 재료다. 성공한 EAP 방법은 세션 키를 내보내고 개시자의 마지막 AUTH 페이로드는 그 키로 계산되므로, 사용자의 증명과 터널의 키가 서로 묶인다. XAuth에는 그런 대응물이 없어서, 그 속성은 첫 단계 이후에 도착하며 키에 아무것도 기여하지 않는다. 바로 이 틈을 IKEv2 골격이 메우도록 설계되었고, 그래서 동작하는 IKEv2 로그인은 무엇이든 묻기 전에 서버 인증서를 검증한다.

이 순서는 유용한 진단이기도 하다. 클라이언트가 인증서를 보여 주기도 전에 자격 증명을 문제 삼는다면, 그것은 IKEv2 EAP 교환을 전혀 하고 있지 않다.

세 신원을 분리해 두라

세 신원이 한 필드로 무너지면 마이그레이션이 잘못된다. 클라이언트가 검증하는 게이트웨이 신원이 있고, 보통 인증서의 subject나 SAN에 있는 DNS 이름이다. EAP에서 제시되는 사용자 신원이 있으며, 도메인 로그인, 주소, 또는 명시적 EAP 신원 문자열일 수 있다. 그리고 그 사용자를 네트워크와 경로에 매핑하는 권한 부여 원천이 있다.

strongSwan의 swanctl 문법은 그 분리를 드러내는데, 연결은 게이트웨이에 remote { auth = pubkey }을, 사용자에 local { auth = eap-mschapv2 }을 설정하고 EAP 신원은 따로 나른다.

새 프로필의 사용자 신원이 옛 XAuth 속성과 다를 때, 예를 들어 짧은 이름 대신 UPN을 쓸 때, 인증 서버는 알 수 없는 사용자를 보게 되고 장애는 잘못된 암호처럼 보인다. 자격 증명을 확인하기 전에 신원 문자열을 확인하라.

옵션을 매핑하고 그다음 함정을 예상하라

매핑은 짧고 모든 행에는 인증 시점에만 나타나는 함정이 있다.

그 행 중 어느 것도 단순한 이름 변경이 아니며, 구성 페이로드는 주소와 확인자를 형식이 지정된 속성 목록으로 전달하는 반면, XAuth의 속성 공간은 그 자체의 발명이었다. 둘을 서로 바꿀 수 있다고 보는 것이 프로필이 게이트웨이가 결코 보내지 않을 설정을 요구하게 되는 경로다.

트래픽 선택자는 별도의 경고를 받을 자격이 있다. IKEv1은 관심 트래픽을 빠른 모드 교환에 묶인 프록시 ID로 표현했고, IKEv2는 IKE_AUTH 중에 선택자를 협상하며 응답자가 이를 좁힐 수 있다. 불일치는 자식 SA가 없는 설정된 IKE SA를 만들고, 일부 클라이언트는 그것을 기꺼이 연결됨으로 표시한다.

옛 연결을 경계로 다루라

RFC 9395는 IKEv1을 폐기 대상으로 지정했으므로 옛 하이브리드 연결은 날짜가 붙은 호환성 경계이지 토대가 아니다. 전환하는 동안 두 프로필을 나란히 돌려야 하며, 중요한 시험은 새 프로필이 뜨는지가 아니라 같은 사용자가 같은 기기에서 같은 자원에 도달하는지다.

인증서 검증은 끝까지 엄격하게 유지하라. 클라이언트가 자기 인증서를 제시하지 않기 시작하면 핸드셰이크가 통과할 때까지 서버 검사를 느슨하게 하고 싶어지는데, 그것은 남은 유일한 증명을 초록 아이콘과 맞바꾸는 일이다.

옛 프로필을 은퇴시키기 전에 네 가지를 적어 두라: EAP 방법, 신원 문자열, 권한 부여 원천, 그리고 지원이 끝나는 날짜다.