IETF가 2021년 12월 30일 RFC 9154 "Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer"를 발표했습니다(Proposed Standard, 저자 J. Gould, R. Wilhelm). 이 문서는 도메인 이름 같은 EPP 객체를 등록대행자(registrar)끼리 이전(transfer)할 때 쓰는 인증 정보(authorization information, 흔히 '이전 코드'·'auth code'로 불림)를 다루는 운영 방식을 정의합니다. 핵심은 세 가지입니다. 인증 정보는 강한 난수로 만들고, 이전이 진행되는 동안에만 짧게 유효하게 하며, 레지스트리(registry)는 이를 해시로만 저장합니다.
무엇이 발표되었나
확장 프로비저닝 프로토콜(EPP, RFC 5730)은 객체 이전을 허가할 때 인증 정보를 쓰도록 정의합니다. 실제로는 RFC 5731(도메인)과 RFC 5733(연락처)에 정의된 비밀번호 방식 인증 정보가 주로 쓰입니다. RFC 9154는 이 방식이 보안, 복잡도, 저장, 유효 기간 면에서 문제가 있다고 지적합니다. 특히 지금까지는 인증 정보를 해시가 아니라 암호화한 형태로 장기간 보관해 왔는데, 문서는 이를 비밀번호 유출 위험이 잠재해 있고 현재 모범 사례에 맞지 않는 방식으로 봅니다.
이 문서는 새 프로토콜을 만들지 않고, 기존 EPP 기능을 활용하는 운영 방식을 정의합니다. 주요 내용은 다음과 같습니다.
- 지원 여부 알림: 클라이언트(등록대행자)와 서버(레지스트리)는
urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0네임스페이스 URI를 각각 login 명령과 greeting에 넣어 이 방식을 지원한다고 알립니다. - 강한 난수: 인증 정보는 안전한 난수로 생성해야 하며(MUST), 엔트로피는 128비트 이상을 권고합니다(SHOULD). 공백을 뺀 출력 가능 ASCII 94자를 쓰면 20자, 영숫자 36자를 쓰면 25자가 필요합니다.
- 짧은 유효 기간(TTL): 객체를 생성할 때는 인증 정보를 빈 값으로 두고, 이전이 진행될 때만 설정합니다. 이전이 성공하면 레지스트리가 자동으로 해제하고, 그렇지 못하면 TTL이 끝났을 때 기존 등록대행자가 해제합니다. 등록대행자는 인증 정보를 등록인(registrant)에게 줄 때 TTL도 알려야 합니다(MUST).
- 저장과 전송: 레지스트리는 SHA-256 같은 256비트 이상 해시 함수와 인증 정보마다 다른 128비트 이상의 무작위 솔트(salt)로 인증 정보를 저장해야 합니다(MUST). 기존 등록대행자는 인증 정보를 저장하면 안 되고, 새 등록대행자는 이전 절차 동안에만 임시로 보관할 수 있습니다. 평문 인증 정보는 로그에 남기면 안 되며, 모든 통신은 암호화된 채널로 해야 합니다.
- info 응답: 이미 설정된 인증 정보를 EPP info 응답으로 돌려주지 않습니다.
영향 범위
이 문서가 직접 다루는 대상은 EPP로 통신하는 레지스트리와 등록대행자입니다. 권한 DNS 서버나 리졸버의 동작, DNS 프로토콜 자체는 바뀌지 않습니다.
도메인을 보유한 조직의 DNS 운영자에게는 도메인 이전 절차가 바뀔 수 있다는 점이 관련됩니다. 이 방식을 적용한 등록대행자를 쓰면 인증 정보가 평소에는 설정되어 있지 않고, 이전을 요청할 때만 발급되며, 정해진 유효 기간 안에 써야 합니다. 레지스트리는 인증 정보가 충분히 강한지 검사해 2202("Invalid authorization information") 오류를 돌려줄 수 있으므로, 등록대행자는 새 값을 만들어 다시 시도할 준비를 해야 합니다.
운영자가 할 일
- 도메인 이전을 계획하고 있다면, 이용 중인 등록대행자의 인증 정보 발급 방식과 유효 기간을 미리 확인해 두십시오. 받은 인증 정보는 유효 기간 안에 새 등록대행자에게 전달해야 합니다.
- 인증 정보를 메일이나 문서, 티켓 시스템에 오래 남겨 두지 마십시오. 이 RFC는 레지스트리와 등록대행자에게 평문 인증 정보를 기록하지 말라고 요구합니다. 등록인 쪽에서도 같은 원칙을 따르는 것이 좋습니다.
- 레지스트리나 등록대행자 시스템을 운영한다면 RFC 9154의 4~5절(난수 생성, TTL, 해시 저장, create·update·info·transfer 명령 처리)을 검토하십시오.
원문을 한국어로 번역·요약한 글입니다. 정확한 내용은 원문을 확인해 주세요. AI의 도움을 받아 작성하고 담당자가 검토했습니다.