요약

  • RFC 3722는 iSCSI 이름 입력을 유니코드 매핑, NFKC 정규화, 금지 문자 검사라는 규정된 절차로 처리하도록 하여, 구현체가 준비된 UTF-8 형태를 바이트 단위로 비교할 수 있게 했습니다.
  • 이러한 재현 가능성은 전사 및 구현 제약을 다루었을 뿐, 이름의 소유권이나 스푸핑 문제를 해결하지는 못했습니다. 시각적으로 유사한 문자는 서로 구별되는 채로 남았고, 프로파일은 유니코드 3.2에 고정되었습니다.

스토리지 콘솔에서 두 이름이 사람 눈에는 서로 바꿔 쓸 수 있어 보여도, 대상 시스템 입장에서는 서로 다른 이름일 수 있습니다. 관리자가 라벨, 이메일, 매뉴얼에서 이름을 입력하는 상황에서 이 간극은 중요합니다. 단순한 이니시에이터는 수신한 바이트가 설정된 타겟과 일치하는지 판단해야 하기 때문입니다. 2004년 4월에 발표된 RFC 3722는 iSCSI(Internet Small Computer Systems Interface) 이름의 이 좁지만 중대한 경계를 다루었습니다.

설계상 문제는 두 기대의 충돌이었습니다. 국제화된 이름을 전사하는 사람에게는 대소문자 비구분 처리와 동등한 문자열에 대한 예측 가능한 처리가 유리합니다. 단순하거나 임베디드 장치에는 정확히 구현할 수 있는 비교 규칙이 유리합니다. 즉, 이름을 준비하고 UTF-8로 인코딩한 뒤 결과 옥텟을 비교하는 방식입니다. 어느 쪽이든 자의적인 선택을 내리면 하나의 표기가 서로 다른 프로토콜 값으로 이어질 수 있습니다. 장치에 광범위하고 로캘에 민감한 매칭을 요구하면 프로토콜은 구현하기 어렵고 예측 불가능해집니다.

RFC 3722는 무제한적인 정리 과정 대신 프로파일을 선택했습니다. 이 문서는 유니코드 3.2를 문자 집합으로 지정하고 Stringprep의 매핑, 정규화, 거부 규칙을 적용합니다. 매핑 테이블은 Stringprep 프레임워크의 B.1과 B.2를 포함하고, 프로파일은 정규화 형식 KC(NFKC)를 사용하며, C.1.1부터 C.9까지의 금지 출력 테이블을 검사하고 양방향 문자열 검사를 적용합니다. 절차의 순서가 중요합니다. 구현체는 입력을 확인한 뒤 더 편리한 동등 관계를 발명하도록 초대받지 않습니다.

이 규칙들은 일부 입력 구분을 사라지게 하고 다른 구분은 보존합니다. 사용자 인터페이스를 통해 입력된 ASCII 대문자는 반드시(MUST) 소문자로 매핑됩니다. 허용되는 ASCII 집합은 소문자, 숫자, 하이픈, 마침표, 콜론이며 공백은 제외됩니다. 미묘한 예로 U+3002(한자 문장부호 온점)가 있습니다. 일부 도메인 이름 입력 시스템은 이를 ASCII 마침표 U+002E와 동등하게 취급하지만, RFC 3722는 이를 금지합니다. 즉, 이 프로파일은 다른 애플리케이션이 우연히 수행하는 치환을 그대로 물려받지 않습니다.

결과는 "모든 유니코드를 정리한 것"이 아닙니다. 명시적으로 이름 붙은 문자 집합과 테이블 집합 아래의 특정 준비된 표현입니다. UTF-8 인코딩 규칙은 별도의 UTF-8 사양에서 오며, iSCSI 이름 문법과 네이밍 권한 제약은 별도의 검사로 남습니다. RFC 3721은 주변의 이름 및 디스커버리 모델을 설명하고, RFC 3722는 문자열 처리 프로파일을 제공합니다. 어느 문서도 성공적인 준비가 그 이름의 사용 승인, 특정 당사자의 현재 통제, 특정 주소에서의 도달 가능성을 증명하지는 않습니다.

가장 놓치기 쉬운 잔여 한계는 다음과 같습니다. RFC 3722는 시각적으로 유사한 문자를 서로 매핑하지 않습니다. 라틴 문자, 그리스 문자 또는 키릴 유사 문자, 특정 폰트에서 비슷하게 렌더링되는 두 글자는 사람이 혼동한다는 이유만으로 동일해지지 않습니다. 보안 절에서는 그 위험을 설명합니다. 시스템이나 운영자가 일관되지 않은 해석을 사용하면 이니시에이터가 의도한 것과 다른 타겟에 도달하거나 정당한 타겟에 도달하지 못할 수 있다는 것입니다. 이는 이름 처리에서 가능한 실패 모드에 대한 경고이지 입증된 공격 사례에 대한 보고가 아닙니다.

이 경계는 Stringprep이 결정할 수 있는 것과 없는 것을 분명히 합니다. 매핑과 정규화는 정의된 변형을 하나의 표현으로 수렴시킬 수 있습니다. 금지 테이블은 프로토콜이 허용하지 않는 입력을 거부할 수 있습니다. 양방향 검사는 혼합 방향 텍스트에 대한 제약을 강제할 수 있습니다. 그러나 어떤 작업도 네이밍 권한의 소유자가 누구인지, 화면에 표시된 라벨이 신뢰할 수 있는지, 시각적으로 기만적인 문자열을 사람이 받아들여야 하는지를 확립하지 못합니다. 이러한 문제는 이 프로파일을 넘어서는 통제가 필요합니다.

RFC 3491(Nameprep)은 국제화 도메인 이름을 위한 또 다른 Stringprep 프로파일을 정의하므로 관련이 있습니다. 그러나 이는 iSCSI 프로파일이 아니며, 도메인 이름 관례를 iSCSI 이름 처리에 무단으로 가져와서는 안 됩니다. RFC 3454가 프레임워크를 제공하고, RFC 3722는 자신의 프로토콜 목적에 맞는 규칙을 선택합니다. RFC 7143이 이후 iSCSI 프로토콜 자료를 통합했지만, 역사적 프로파일의 유니코드 3.2 기반은 RFC 3722의 속성으로 남습니다. 새로운 식별자 시스템 전반에 대한 현재 권고가 아닙니다.

이 표준은 결국 관대한 해석을 재현 가능성과 교환했습니다. 구현자에게는 고정된 절차를, 운영자에게는 두 입력이 동등하거나 불일치하는 이유를 추론할 수 있는 방법을 제공했습니다. 그러나 재현 가능한 비교는 입력되는 문자열만큼만 견고하며, 유사 문자에 의한 기만을 해결하지는 못합니다. 지속되는 교훈은 유니코드가 스토리지 이름에 대해 안전해졌다는 것이 아니라, 프로토콜은 어떤 차이를 지우고, 어떤 차이를 거부하며, 어떤 차이를 사람과 주변 통제에 맡기는지 정확히 정의해야 한다는 점입니다.

출처