오픈 스크린 네트워크 프로토콜

1. 소개

Open Screen Network Protocol은 브라우저와 장치가 서로를 발견하고 보안 네트워크 연결을 수립하기 위한 기준 네트워크 프로토콜 세트를 제공한다. 이 연결은 Open Screen Application Protocol의 전송 계층으로 사용할 수 있다.

Application Protocol과 Network Protocol은 독립적이다. 그러나 Network Protocol은 Application Protocol의 요구사항을 충족하도록 설계되었다. 전송 계층을 사용하는 다른 애플리케이션 수준 프로토콜에 적합할 수도 있고 그렇지 않을 수도 있다.

네트워크 프로토콜의 기본 흐름은 다음과 같다.

• 에이전트가 로컬 영역 네트워크에서 서로를 발견하기 위해 DNS-SD를 사용한다.

• 초기 인증되지 않은 연결을 수립하기 위해 자체 서명 인증서와 함께 TLS 1.3을 사용한다.

• 상호 ID를 검증하고 인증서를 교환하기 위해 SPAKE2를 사용한다.

• IP 위의 전송 계층으로 QUIC을 사용한다.

부록 C: 전체 흐름 차트의 흐름 차트는 전체 이벤트 순서를 보여준다.

동반 explainer는 프로토콜에 대한 추가 배경을 제공한다.

1.1. 용어

Open Screen Network Protocol agent(또는 OSP agent)는 이 프로토콜의 임의 구현 (브라우저, 디스플레이, 스피커 또는 기타 소프트웨어)을 말한다.

2. 요구사항

2.1. 일반 요구사항

1. Open Screen Network Protocol agent는 동일한 IPv4 또는 IPv6 서브넷에 연결되어 있고 IP 멀티캐스트로 도달 가능한 다른 OSP agent의 존재를 발견할 수 있어야 한다.

2. OSP agent는 에이전트의 IPv4 또는 IPv6 주소, 에이전트의 표시 이름, 그리고 에이전트에 대한 네트워크 전송을 수립하기 위한 IP 포트 번호를 얻을 수 있어야 한다.

2.2. 비기능 요구사항

1. 저가 스마트폰, 스마트 TV 또는 스트리밍 장치에서 볼 수 있는 것과 유사한 완만한 하드웨어 요구사항으로 Open Screen Network Protocol을 구현할 수 있어야 한다. 에이전트 하드웨어 사양은 Device Specifications 문서를 참조하라.

2. 발견 및 연결 프로토콜은 전력 소비를 최소화해야 하며, 특히 배터리로 구동될 가능성이 큰 listening agent에서 그러해야 한다.

3. 프로토콜은 presentation, 원격 재생 또는 미디어 스트림의 내용 등을 포함하여 사용자의 ID나 에이전트에서의 활동에 대해 수동 네트워크 관찰자에게 제공되는 정보의 양을 최소화해야 한다.

4. 프로토콜은 능동 네트워크 공격자가 디스플레이를 사칭하고 controller 또는 receiver로 의도된 데이터를 관찰하거나 변경하는 것을 방지해야 한다.

5. listening agent는 advertising agent가 사용 가능하거나 사용 불가능해질 때(즉, 네트워크에 연결되거나 연결 해제될 때) 이를 빠르게 발견할 수 있어야 한다.

6. 에이전트는 사용자가 다른 에이전트를 인증했다는 사실을 기억할 수 있어야 한다. 이는 에이전트가 사용자가 이미 인증한 에이전트에 연결하려 할 때마다 사용자가 개입하여 다시 인증할 필요가 없다는 것을 의미한다.

7. 에이전트 간 메시지 지연 시간은 대화형 사용을 허용하도록 최소화해야 한다. 예를 들어, 한 에이전트의 양식에 텍스트를 입력하면 presentation에 실시간으로 표시될 만큼 편안해야 한다. 게임 또는 마우스 사용을 위한 실시간 지연 시간이 이상적이지만 요구사항은 아니다.

3. mDNS를 사용한 발견

Open Screen Network Protocol Agent는 자신을 식별하는 정보와 IP 서비스 엔드포인트를 광고하고 수신함으로써 서로를 발견한다. DNS-SD 및 mDNS를 통한 에이전트 광고와 발견은 이 명세에서 정의되며 모든 에이전트가 구현해야 한다. 그러나 에이전트는 유니캐스트 DNS를 통해 동일한 DNS-SD 레코드를 질의하는 것과 같은 추가 발견 메커니즘을 자유롭게 구현할 수 있다.

OSP agent는 DNS-SD Service Name _openscreen._udp를 사용해야 한다.

advertising agent는 _openscreen._udp.local에 대한 mDNS 질의에 응답하는 에이전트이다. 이러한 에이전트에는 presentation display에 대한 사람이 읽을 수 있는 설명인 display name(비어 있지 않은 문자열)이 있어야 한다. 예: "Living Room TV."

listening agent는 _openscreen._udp.local에 대한 mDNS 질의를 보내는 에이전트이다. Listening agent는 display name을 가질 수 있다.

Advertising agent는 에이전트 display name의 접두사인 DNS-SD Instance Name을 사용해야 한다. Instance Name이 전체 display name이 아니면, listening agent가 잘렸다는 것을 알 수 있도록 null(\000) 문자로 끝나야 한다.

Advertising agent는 여러 advertising agent가 동일한 DNS-SD Instance Name을 사용하는 것을 방지하기 위해 mDNS 충돌 해결 절차를 따라야 한다.

에이전트는 Instance Name을 사용자에게 표시할 때 주의해야 한다. Instance Name 표시 지침은 § 7.4.1 인스턴스 및 표시 이름을 참조하라.

Advertising agent는 다음 키와 값을 가진 DNS TXT 레코드를 포함해야 한다.

fp

advertising agent의 agent fingerprint. agent fingerprint를 계산하는 단계는 아래에 정의되어 있다.

mv

메타데이터가 변경되었음을 나타내는 부호 없는 정수 값. advertising agent는 이를 더 큰 값으로 갱신해야 한다. 이는 listening agent가 advertising agent에 연결하여 갱신된 메타데이터를 발견해야 함을 알린다. 값은 variable-length integer로 인코딩해야 한다.

at

[A-Za-z0-9+/] 집합의 문자로 구성된, 추측할 수 없는 영숫자 토큰.

참고: at는 LAN 외부 당사자가 인증을 시도하는 것을 방지한다. § 7.3.3 원격 능동 네트워크 공격자를 참조하라. at는 무차별 대입 공격을 비현실적으로 만들기 위해 최소 32비트의 실제 엔트로피를 가져야 한다.

참고: OSP agent가 (예: 절전 이유로) 네트워크 연결을 일시 중단하는 경우, 네트워크 연결이 재개될 때 발견 상태가 보존되도록 캐시된 유효한 mDNS 레코드를 유지하려고 시도해야 한다.

이 QUIC 기반 프로토콜의 향후 확장은 결정될 capabilities 메커니즘을 통해 동일한 메타데이터 발견 프로세스를 사용하여 해당 확장에 대한 지원을 나타낼 수 있다. Open Screen Network Protocol의 향후 버전이 mDNS를 사용하지만 메타데이터 발견 프로세스와의 호환성을 깨는 경우, 새로운 메타데이터 발견 메커니즘을 나타내는 새 값으로 DNS-SD service name을 변경해야 한다.

3.1. 에이전트 지문 계산

에이전트의 agent fingerprint는 다음 단계에 따라 계산된다.

1. SHA-256을 해시 알고리즘으로 사용하여 [RFC7469]에 따라 agent certificate의 SKPI Fingerprint를 계산한다.

2. 1단계의 결과를 [RFC4648]에 따라 base64 인코딩한다.

참고: 결과 문자열은 길이가 44바이트가 된다.

3.2. 인증서 일련 번호 계산

certificate serial number를 다음 단계의 결과라고 하자.

1. 에이전트가 agent certificate를 생성한 적이 없는 경우:
   1. certificate serial number base를 128비트 UUID라고 하자.
   2. certificate serial number counter를 처음에 0으로 설정되는 32비트 부호 없는 정수라고 하자.
2. 다음과 같이 160비트 값을 생성한다.
   1. certificate serial number counter를 1만큼 증가시킨다.
   2. 상위 128비트를 certificate serial number base에 할당한다.
   3. 하위 32비트를 certificate serial number counter에 할당한다.

3.3. 에이전트 호스트 이름 계산

에이전트가 DNS-SD Service Instance Name 또는 certificate serial number를 변경할 때마다 다음과 같이 agent hostname을 계산해야 한다.

1. base64SerialNumber를 certificate serial number를 base64 인코딩한 것으로 설정한다.

2. encodedInstanceName을 다음 결과로 설정한다.

   1. DNS-SD Instance Name에서 [A-Za-z0-9-] 이외의 모든 문자를 하이픈 -으로 바꾼다.

3. encodedDomain을 다음 결과로 설정한다.

   1. DNS-SD Domain Name에서 [A-Za-z0-9-] 이외의 모든 문자를 하이픈 -으로 바꾼다.

4. agent hostname을 문자열 base64SerialNumber + . + encodedInstanceName + . + encodedDomain으로 설정한다.

TODO: advertising agent에 대한 메타데이터, DNS-SD 레코드 및 인증서 필드의 예시가 포함된 부록을 추가한다.

4. QUIC을 사용한 전송 및 메타데이터 발견

listening agent가 advertising agent에 연결하거나 그에 대한 추가 메타데이터를 알아내려면, SRV 레코드의 IP 및 포트로 QUIC 연결을 시작한다. 인증 전에는 메시지(예: 추가 메타데이터)가 교환될 수 있지만, 그러한 정보는 검증되지 않은 것으로 취급해야 한다(예: 인증되지 않은 에이전트의 display name이 검증되지 않았음을 사용자에게 표시).

두 에이전트가 사용하는 connection ID는 길이가 0이어야 한다. 길이가 0인 connection ID가 선택된 경우, 에이전트는 새 QUIC 연결을 수립하지 않고 IP 또는 포트를 변경할 수 없다. 이러한 경우 에이전트는 IP 또는 포트를 변경하기 위해 새 QUIC 연결을 수립해야 한다.

4.1. TLS 1.3

OSP Agent가 다른 에이전트에 QUIC 연결을 만들 때, 연결을 보호하기 위해 TLS 1.3을 사용해야 한다. TLS 1.3은 다음 애플리케이션별 매개변수와 함께 사용되어, 연결이 OSP를 사용하여 특정 OSP Agent와 통신하는 데 사용될 것임을 나타내야 한다. OSP Agent는 이러한 매개변수가 없는 수신 연결을 거부할 수 있다.

• 사용되는 ALPN은 "osp"여야 한다.

• server_name extension은 agent hostname으로 설정되어야 한다.

• 수신된 agent certificate에 대해 계산된 agent fingerprint는 advertising agent가 광고한 fp mDNS TXT 레코드와 일치해야 한다.

OSP Agent는 TLS early data를 보내서는 안 된다.

ALPN을 IANA에 등록한다. [Issue #228]

4.2. 에이전트 인증서

각 OSP Agent는 TLS 1.3 certificate 교환에 사용할 공개 키가 포함된 X.509 v3 agent certificate를 생성해야 한다. advertising agent와 listening agent 모두 QUIC 연결을 만들 때 TLS 1.3 Certificate 메시지에서 agent certificate를 사용해야 한다.

agent certificate는 다음 특성을 가져야 한다.

• 256비트 ECDSA 공개 키.

• 자체 서명.

• TLS 1.3에 정의된 ecdsa_secp256r1_sha256 signature scheme을 지원.

  • AlgorithmIdentifier 값은 [RFC5480](공개 키) 및 [RFC5758] (signature scheme)에 정의된 것과 같다.

  • [X690]은 식별자를 인코딩하는 데 사용되는 Distinguished Encoding Rules(DER) 표현을 지정한다.

• 서명에 유효.

각 agent certificate에는 위 단계로 계산된 고유한 certificate serial number가 있다. 아래의 <sn> 값은 해당 일련 번호로 대체되어야 한다.

다음 X.509 v3 필드는 다음과 같이 설정된다.

위에서 언급하지 않은 필수 필드는 [RFC5280]에 따라 설정해야 한다.

참고: OSP agent는 사용자 인터페이스와 디버깅 목적을 위해 O 키의 값으로 구현자 또는 장치 모델 이름을 사용할 수 있다. 또한 사용자 인터페이스와 디버깅 목적을 위해 위치 키(L, ST, C)의 값으로 에이전트 구현자 또는 장치 제조사의 위치를 사용할 수 있다.

OSP agent가 아직 § 6 인증을 통해 검증하지 않은 agent certificate를 보게 되면, 해당 에이전트를 검증되지 않은 것으로 취급하고 그 에이전트와 추가 메시지를 교환할 수 있게 하기 전에 해당 에이전트와 인증을 시작해야 한다.

OSP agent가 인증을 통해 검증한 유효한 agent certificate를 보게 되면, 추가 메시지를 보내기 전에 해당 에이전트와 인증을 시작할 필요는 없다.

listening agent가 advertising agent로부터 메시지를 수신하려 하거나 advertising agent가 listening agent에 메시지를 보내려는 경우, 연결에 데이터를 주기적으로 보내 QUIC 연결을 유지하려 할 수 있다.

OSP agent가 (예: 절전 이유로) 네트워크 연결을 일시 중단하는 경우, 네트워크 연결이 복원되면 이전에 연결되어 있던 OSP agent에 대한 QUIC 연결을 재개하려고 시도해야 한다.

5. CBOR 및 QUIC 스트림을 사용한 메시지 전달

메시지는 CBOR을 사용하여 직렬화된다. 메시지 그룹을 순서대로 보내려면, 해당 메시지 그룹은 하나의 QUIC 스트림으로 보내야 한다. 독립적인 메시지 그룹(그룹 간 순서 의존성이 없는 경우)은 서로 다른 QUIC 스트림으로 보내야 한다. 여러 CBOR 직렬화 메시지를 동일한 QUIC 스트림에 넣기 위해 다음을 사용한다.

참고: Open Screen Agent는 오디오, 비디오 또는 데이터 스트리밍 사용 사례에 필요할 수 있는 동시 스트림 수를 염두에 두고, 애플리케이션 성능을 저해하지 않도록 QUIC 스트림 제한(MAX_STREAMS)을 구성해야 한다.

각 메시지에 대해 OSP agent는 단방향 QUIC 스트림에 다음을 써야 한다.

1. 메시지의 유형을 나타내는 type key. variable-length integer로 인코딩된다(부록 A: 메시지의 type key 참조).

2. CBOR로 인코딩된 메시지.

에이전트가 인식하지 못하는 type key를 가진 메시지를 수신하면, 애플리케이션 오류 코드 404로 QUIC 연결을 닫아야 하며, CONNECTION_CLOSE frame의 reason phrase에 알 수 없는 type key를 포함해야 한다.

Variable-length integer는 QUIC이 사용하는 Variable-Length Integer Encoding으로 인코딩된다.

6. 인증

지원되는 각 인증 방법은 해당 방법에 특정한 인증 메시지를 통해 구현된다. 인증 방법은 메시지 자체에 의해 명시적으로 지정된다. 인증 상태 메시지는 모든 인증 방법에 공통이다. 새로 추가되는 인증 방법은 새 인증 메시지를 정의해야 한다.

Open Screen Network Protocol agent는 사전 공유 키와 함께 § 6.1 SPAKE2를 사용한 인증을 구현해야 한다.

인증 전에 에이전트는 사용자의 사전 공유 키(PSK) 입력 용이성과 지원되는 PSK 입력 방법을 지정하는 auth-capabilities 메시지를 교환한다. PSK 입력 용이성 값이 더 낮은 에이전트는 인증 요청을 보내거나 받을 때 사용자에게 PSK를 제시한다. 두 에이전트의 PSK 입력 용이성 값이 같은 경우, 서버가 사용자에게 PSK를 제시한다. 동일한 사전 공유 키가 양쪽 에이전트에서 사용된다. 사용자에게 PSK를 제시하는 에이전트가 PSK presenter이고, 사용자가 PSK를 입력해야 하는 에이전트가 PSK consumer이다.

PSK 입력 용이성은 0 이상 100 이하 범위의 정수이며, 0은 사용자가 이 장치에서 PSK를 입력할 수 없음을 의미하고 100은 사용자가 이 장치에서 PSK를 쉽게 입력할 수 있음을 의미한다. 지원되는 PSK 입력 방법은 숫자 및 QR 코드 스캔이다. 0이 아닌 PSK 입력 용이성을 가진 장치는 numeric PSK 입력 방법을 지원해야 한다.

모든 인증 방법은 사용자에게 PSK를 표시하거나 사용자에게 PSK 입력을 요청하기 전에 auth-initiation-token을 요구할 수 있다. advertising agent의 경우, mDNS TXT 레코드의 at 필드는 해당 에이전트로 보내거나 해당 에이전트에서 보내는 첫 번째 인증 메시지의 auth-initation-token으로 사용되어야 한다. 에이전트는 auth-initation-token이 설정되어 있고 advertising agent가 제공한 at와 일치하지 않는 인증 메시지를 폐기해야 한다.

auth-capabilities 메시지의 psk-min-bits-of-entropy 필드에서, 에이전트는 PSK에 요구하는 최소 엔트로피 비트를 20에서 60비트까지의 범위로 지정할 수 있으며, 기본값은 20이다. PSK presenter는 이 필드에서 받은 값만큼의 엔트로피와 이 필드에서 보낸 값만큼의 엔트로피를 모두 최소한 만족하는 PSK를 생성해야 한다.

에이전트가 사용자에게 PSK를 둘 이상의 방식(예: QR 코드와 numeric PSK 모두)으로 표시하기로 선택하는 경우, 동일한 PSK에 대한 것이어야 한다. 서로 다르면 PSK presenter가 사용자가 어느 것을 사용하기로 선택했는지 알 수 없으며, 이는 인증 실패로 이어질 수 있다.

부록 C: 전체 흐름 차트는 에이전트가 사용자에게 표시할 문자열 또는 QR code를 생성하기 위해 지원할 수 있는 두 가지 PSK 인코딩 방식을 설명한다.

6.1. SPAKE2를 사용한 인증

[Meta] CFRG PAKE 경쟁 결과 추적 [Issue #242]

이 절에서 정의된 모든 메시지와 객체에 대해서는 전체 CDDL 정의가 있는 부록 A: 메시지를 참조하라.

기본 인증 방법은 다음 cipher suite를 사용하는 SPAKE2이다.

1. Elliptic curve는 edwards25519이다.

2. Hash function은 SHA-256이다.

3. Key derivation function은 HKDF이다.

4. Message authentication code는 HMAC이다.

5. Password hash function은 SHA-512이다.

Open Screen Network Protocol은 PSK가 일회용이며 어떤 형태로도 저장되지 않기 때문에, SPAKE2로 PSK를 해시하는 데 memory-hard hash function을 사용하지 않고 대신 SHA-512를 사용한다.

SPAKE2는 명시적 상호 인증을 제공한다.

이 인증 방법은 에이전트가 숫자나 짧은 비밀번호처럼 사용자가 전화, 키보드 또는 TV 리모컨에 입력할 수 있는 낮은 엔트로피의 비밀을 공유한다고 가정한다.

SPAKE2는 대칭적이지 않으며 Alice(A)와 Bob(B)이라는 두 역할을 갖는다.

이 인증 방법에 사용되는 메시지는 auth-spake2-handshake, auth-spake2-confirmation 및 auth-status이다. [SPAKE2]는 auth-spake2-handshake 및 auth-spake2-confirmation이 어떻게 계산되는지 자세히 설명한다.

SPAKE2에서 사용되는 A 및 B 값은 각각 client와 server의 agent fingerprint이다. pw는 사용자에게 제시되는 PSK이다.

PSK presenter 또는 PSK consumer는 (SPAKE2에서 Alice 역할을 맡아) 인증을 시작할 수 있다.

PSK presenter가 인증을 시작하려는 경우, 사용자에게 PSK를 제시하고 auth-spake2-handshake 메시지를 전송하여 인증 프로세스를 시작한다. auth-spake2-handshake 메시지의 public-value 필드는 SPAKE2의 pA 값으로 설정되어야 하며 psk-status 필드는 psk-shown으로 설정되어야 한다.

PSK consumer가 auth-spake2-handshake 메시지를 수신하면, 아직 그렇게 하지 않았다면 PSK consumer는 사용자에게 PSK 입력을 요청한다. PSK를 수신하면 public-value 필드를 SPAKE2의 pB 값으로 설정하고 psk-status 필드를 psk-input으로 설정한 auth-spake2-handshake 메시지를 보낸다.

PSK consumer가 인증을 시작하려는 경우, PSK consumer는 psk-status 필드를 psk-needs-presentation으로 설정하고 public-value 필드를 pA로 설정한 auth-spake2-handshake 메시지를 PSK presenter에게 보낸다. PSK presenter는 이 메시지를 수신하면 PSK를 생성하여 사용자에게 제시한다. 완료되면 psk-status를 psk-input으로 설정하고 public-value 필드를 pB로 설정한 auth-spake2-handshake 메시지를 PSK consumer에게 보낸다.

에이전트가 auth-spake2-handshake 메시지에서 pA와 pB를 모두 알게 되면, confirmation-value 필드를 Alice의 경우 cA, Bob의 경우 cB로 설정한 auth-spake2-confirmation을 계산하여 다른 에이전트로 보낸다.

에이전트가 auth-spake2-confirmation 메시지를 수신하면, [SPAKE2]의 절차를 사용하여 해당 메시지를 검증한 다음, 인증된 auth-status 메시지로 다른 에이전트에 응답한다. authenticated가 아닌 모든 result 값은 인증 실패를 의미하며, 에이전트는 즉시 연결을 끊어야 한다.

참고: auth-status 메시지는 각 에이전트가 키 확인 검증을 통해 SPAKE2의 결과를 독립적으로 계산하므로 단지 정보 제공용이다.

부록 C: 전체 흐름 차트는 에이전트가 아직 서로를 인증하지 않았을 때의 전체 프로세스를 보여주며, 여기에는 발견, QUIC 연결 수립, 메타데이터 교환 및 인증이 포함된다. 에이전트가 인증을 완료한 경우, 인증 단계는 생략할 수 있다.

7. 보안 및 개인정보 보호

Open Screen Network Protocol은 두 OSP agent가 서로를 발견하고 사용자 및 애플리케이션 데이터를 교환할 수 있게 한다. 따라서 보안 및 개인정보 보호 고려사항을 면밀히 검토해야 한다. 우리는 W3C Security and Privacy Questionnaire를 사용하여 프로토콜 자체를 평가하고, 에이전트가 이러한 보안 및 개인정보 보호 요구사항을 충족하기 위해 사용할 수 있는 권장 완화책도 논의한다.

7.1. 위협 모델

7.1.1. 수동 네트워크 공격자

Open Screen Network Protocol은 동일한 LAN에 연결된 모든 당사자가 OSP agent 간에 흐르는 모든 데이터를 관찰할 수 있다고 가정해야 한다.

이들 당사자는 mDNS 레코드 및 QUIC handshake와 같은 암호화되지 않은 메시지를 통해 노출되는 모든 데이터를 수집할 수 있다.

이들 당사자는 QUIC 연결의 데이터 흐름을 관찰하거나 암호화 타이밍을 관찰하여 암호화 매개변수를 알아내려 시도할 수 있다.

7.1.2. 능동 네트워크 공격자

손상된 router와 같은 능동 공격자는 에이전트 간에 교환되는 데이터를 조작할 수 있다. 이들은 기존 QUIC 연결에 트래픽을 주입하고 새 QUIC 연결을 시작하려고 시도할 수 있다. 이러한 능력은 다음을 시도하는 데 사용될 수 있다.

• 사용자에게 인증하도록 유도하기 위해 에이전트 또는 사용자가 이미 인증한 에이전트를 사칭한다.

• 에이전트에 연결하여 그 capabilities를 질의한다.

특히 우려되는 공격 중 하나는 잘못 구성되었거나 손상된 router가 로컬 네트워크 장치(예: OSP agent)를 Internet에 노출하는 것이다. 이 공격 벡터는 일반적으로 Internet에서 접근할 수 없는 로컬 네트워크 서비스에 연결하여 printer와 smart TV를 제어하는 데 악의적 당사자가 사용해 왔다.

7.1.3. 서비스 거부

LAN에 연결된 당사자는 OSP agent에 대한 접근을 거부하려 시도할 수 있다. 예를 들어, 공격자는 합법적인 연결을 차단하거나 에이전트의 시스템 리소스를 고갈시키기 위해 에이전트에 많은 수의 QUIC 연결을 열려고 시도할 수 있다. 또한 mDNS listener의 캐시 용량을 고갈시키거나 listener가 많은 수의 가짜 QUIC 연결을 열게 하기 위해 허위 DNS-SD 레코드를 멀티캐스트할 수 있다.

7.2. Open Screen Network Protocol 보안 및 개인정보 보호 고려사항

7.2.1. 개인 식별 정보 및 고가치 데이터

다음 데이터는 합리적으로 기밀로 만들 수 없으며 공개된 것으로 간주해야 한다.

1. Open Screen Network Protocol에서 사용하는 IP 주소와 포트.

2. mDNS를 통해 광고되는 데이터. 여기에는 display name 접두사, certificate fingerprint와 serial number, metadata version이 포함된다.

7.2.2. 교차 출처 상태 고려사항

네트워크 프로토콜은 origin state를 직접 처리하지 않는다.

7.2.3. 다른 장치에 대한 출처 접근

설계상 Open Screen Network Network Protocol은 이를 사용하는 애플리케이션 프로토콜을 통해 Web에서 장치에 접근할 수 있게 한다. 이 프로토콜을 구현함으로써, 이러한 장치는 자신을 Web에 제공한다는 것을 알고 있으며 그에 맞게 설계되어야 한다.

아래에서는 이러한 장치의 악의적 사용을 방지하기 위한 완화 단계를 논의한다.

7.2.4. 비공개 브라우징 모드

user agent는 동일한 user agent instance에서의 일반 브라우징과 비공개 브라우징에 대해 별도의 인증 컨텍스트(§ 6 인증 참조)와 QUIC 연결(§ 4 QUIC을 사용한 전송 및 메타데이터 발견 참조)을 사용하는 것이 권장된다. 이렇게 하면 다른 장치가 동일 사용자의 일반 및 비공개 브라우징에서 발생하는 활동을 매칭하기 더 어려워진다.

7.2.5. 영속 상태

에이전트는 § 6 인증을 성공적으로 완료한 에이전트의 ID를 영속화할 가능성이 높다. 여기에는 해당 당사자의 public key fingerprint, metadata version 및 metadata가 포함될 수 있다.

그러나 이 데이터는 일반적으로 Web에 노출되지 않으며, display selection 또는 display authentication 과정에서 user agent의 native UI를 통해서만 노출된다. 사용자가 browsing data를 지울 때 user agent가 이 데이터를 지울지 유지할지는 구현 선택 사항일 수 있다.

7.2.6. 기타 고려사항

Open Screen Network Network Protocol은 Web에 다음에 대한 추가 접근을 부여하지 않는다.

• 새로운 script loading 메커니즘

• 사용자 위치에 대한 접근

• 장치 sensor에 대한 접근

• 사용자의 local computing environment에 대한 접근

• user agent의 native UI에 대한 제어

• user agent의 보안 특성

7.3. 완화 전략

7.3.1. 로컬 수동 네트워크 공격자

로컬 수동 공격자는 Open Screen Network Protocol을 사용하여 사용자 활동 및 장치 capabilities에 관한 데이터를 수집하려 할 수 있다. 이를 해결하기 위한 주요 전략은 사용자 매개 인증이 이루어지기 전에 불투명한 public key fingerprint만 노출하여 데이터를 최소화하는 것이다.

수동 공격자는 TLS 1.3 QUIC 연결의 암호화 매개변수를 알아내기 위해 timing attack도 시도할 수 있다. TLS 1.3용 애플리케이션 프로파일은 constant-time cipher를 요구하며, TLS 1.3 구현은 side channel attack에 저항하는 elliptic curve signing operation을 사용해야 한다.

7.3.2. 로컬 능동 네트워크 공격자

로컬 능동 공격자는 사용자가 일반적으로 신뢰하는 presentation display를 사칭하려 할 수 있다. Open Screen Network Protocol의 § 6 인증 단계는 공유 비밀을 알지 못하는 man-in-the-middle이 에이전트를 사칭하는 것을 방지한다. 그러나 공격자가 기존의 신뢰된 에이전트 또는 아직 인증되지 않은 새로 발견된 에이전트를 사칭하고 사용자가 이를 인증하도록 유도하려 시도할 수 있다. (이 맥락에서 trust는 사용자가 자신의 에이전트에서 다른 에이전트로 § 6 인증을 완료했다는 것을 의미한다.)

이는 여러 기술의 조합으로 해결할 수 있다. 첫 번째는 사칭 시도를 감지하는 것이다. 에이전트는 다음 상황을 감지하고 해당 기준 중 하나라도 충족하는 에이전트를 suspicious agent로 표시해야 한다.

• 동시 광고 중 public key fingerprint가 충돌하는 별개의 IP endpoint를 가진 에이전트.

• 지정된 public key fingerprint 아래에서 이전에 광고된 이름과 display name이 다른 신뢰되지 않은 에이전트.

• 일정 횟수 인증 challenge에 실패한 신뢰되지 않은 에이전트.

• 이미 신뢰된 에이전트의 display name과 유사한 display name을 광고하는 신뢰되지 않은 에이전트.

두 번째는 상호 인증 중 낮은 엔트로피 비밀을 관리하는 것이다.

• 무차별 대입 공격을 방지하기 위해 낮은 엔트로피 비밀을 교체한다.

• 인증 challenge에 응답할 때 증가하는 backoff를 사용하여 무차별 대입 공격도 방지한다.

• 공유 비밀을 생성하기 위해 암호학적으로 건전한 엔트로피 소스를 사용한다.

능동 공격자는 트래픽을 주입하거나 수정하여 QUIC 연결을 통해 교환되는 데이터를 방해하려 할 수도 있다. 이러한 공격은 TLS 1.3의 올바른 구현으로 완화해야 한다. TLS 1.3 프로토콜의 자세한 보안 분석은 [RFC8446]의 부록 E를 참조하라.

7.3.3. 원격 능동 네트워크 공격자

잘못 구성된 firewall 또는 NAT가 LAN에 연결된 에이전트를 더 넓은 Internet에 노출할 수 있기 때문에, 네트워크 장치가 OSP agent를 완전히 보호한다고 의존할 수는 없다. OSP agent는 모든 Internet host의 공격에 안전해야 한다.

Advertising agent는 off-LAN 시도가 § 6 인증을 시작하여 사용자 짜증 (PSK 표시 또는 입력)과 PSK에 대한 잠재적 무차별 대입 공격을 초래하는 것을 방지하기 위해 mDNS TXT 레코드의 at 필드를 설정해야 한다.

7.3.4. 서비스 거부

사용자의 로컬 영역 네트워크에서 발생하는 서비스 거부 공격을 완전히 방지하기는 어려울 것이다. OSP agent는 그러한 공격에도 불구하고 기존 활동을 계속할 수 있도록 새 연결을 거부하거나, 너무 많은 메시지를 받는 연결을 닫거나, 특정 응답자로부터 캐시되는 mDNS 레코드 수를 제한할 수 있다.

7.3.5. 악의적 입력

OSP agent는 parsing vulnerability를 악용하여 대상 장치를 손상시키려는 악의적 입력에 견고해야 한다.

가능한 경우, OSP agent(콘텐츠 및 미디어 렌더링과 같은 애플리케이션 수준 구성요소 포함)는 취약점이 사용자 데이터에 접근하거나 영속적 exploit로 이어지는 것을 방지하기 위해 sandboxing과 같은 defense-in-depth 기술을 사용해야 한다.

7.4. 사용자 인터페이스 고려사항

이 명세는 OSP agent의 보안 관련 사용자 인터페이스에 대해 특정 요구사항을 만들지 않는다. 그러나 PSK 기반 인증은 사용자가 어떤 에이전트를 신뢰할지에 대해 정보에 기반한 결정을 내려야 하므로, 이러한 사용자 인터페이스를 설계할 때 중요한 고려사항이 있다.

1. 에이전트가 다른 장치를 인증하기 전에는, 해당 장치에서 온 모든 데이터가 인증으로 검증되지 않았음을 명확히 해야 한다. (이것이 DNS-SD Instance Name에 어떻게 적용되는지는 아래를 참조하라.)

2. suspicious agent는 의심스럽지 않은 신뢰된 에이전트와 다르게 표시되거나, 전혀 표시되지 않아야 한다.

3. 인증 중 PSK를 제시하는 사용자 인터페이스는 trusted UI에서 이루어져야 하고 spoof하기 어려워야 한다. 어떤 물리적 장치가 PSK를 제시하는지 사용자에게 명확해야 한다.

4. 인증 중 PSK를 입력하는 사용자 인터페이스는 trusted UI에서 이루어져야 하고 spoof하기 어려워야 한다.

5. 사용자가 이 단계를 무심코 클릭하여 지나가는 것을 방지하기 위해, 사용자가 PSK를 입력하는 동작을 수행해야 한다.

6. PSK를 렌더링하고 입력하는 사용자 인터페이스는 접근성 지침을 충족해야 한다.

7.4.1. 인스턴스 및 표시 이름

DNS-SD Instance Name은 인증 전에 사용자가 보는 주요 정보이므로, 이러한 이름을 신중하게 표시해야 한다.

DNS-SD를 agent-info, 즉 애플리케이션 메시지와 연결하지 않도록 문구를 다시 작성한다. [Issue #346]

에이전트는 Instance Name을 검증되지 않은 정보로 취급해야 하며, 성공적인 QUIC 연결 후 agent-info 메시지를 통해 받은 display name의 접두사인지 확인해야 한다. 에이전트가 이 검사를 완료하면 해당 이름을 verified display name으로 표시할 수 있다.

에이전트는 DNS-SD에서 잘린 display name 대신 전체 display name만 사용자에게 표시해야 한다. 잘린 display name은 위와 같이 검증된 후에야 verified display name으로 전체 표시되어야 한다.

부록 A: 메시지

다음 메시지는 Concise Data Definition Language 구문을 사용하여 정의된다. 정수 키가 사용되는 경우, 해당 필드의 이름을 나타내기 위해 주석이 줄에 추가된다. 이 명세의 객체 정의는 wire상의 바이트 수를 줄이면서도 각 키에 대해 사람이 읽을 수 있는 이름을 유지하기 위해 이러한 특이한 구문을 사용한다. 선택적 필드를 쉽게 인덱싱할 수 있도록 object array 대신 정수 키가 사용된다.

각 root message(다른 메시지로 둘러싸이지 않고 QUIC 스트림에 넣을 수 있는 메시지)에는 message type key를 나타내는 주석이 있다.

더 작은 숫자는 더 자주 전송되거나 매우 작거나 둘 다인 메시지를 위해 예약되어야 하며, 더 큰 숫자는 드물게 전송되거나 크거나 둘 다인 메시지를 위해 예약되어야 한다. 이는 더 작은 type key가 wire에서 더 작게 인코딩되기 때문이다.

; type key 1001
auth-capabilities = {
  0: uint ; psk-ease-of-input
  1: [* psk-input-method] ; psk-input-methods
  2: uint ; psk-min-bits-of-entropy
}

psk-input-method = &(
  numeric: 0
  qr-code: 1
)

auth-initiation-token = {
  ? 0: text ; token
}

auth-spake2-psk-status = &(
  psk-needs-presentation: 0
  psk-shown: 1
  psk-input: 2
)

; type key 1003
auth-spake2-confirmation = {
  0: bytes .size 64 ; confirmation-value
}

auth-status-result = &(
  authenticated: 0
  unknown-error: 1
  timeout: 2
  secret-unknown: 3
  validation-took-too-long : 4
  proof-invalid: 5
)

; type key 1004
auth-status = {
  0: auth-status-result ; result
}

; type key 1005
auth-spake2-handshake = {
  0: auth-initiation-token; initiation-token
  1: auth-spake2-psk-status ; psk-status
  2: bytes ; public-value
}

부록 B: PSK 인코딩 방식

다음 부록은 길이가 20비트에서 80비트 사이인 값 P를 받아 사용자에게 표시할 문자열 또는 QR code를 생성하는 두 가지 PSK 인코딩 방식을 설명한다.

에이전트는 일반적으로 한 장치에 PSK를 표시하고 사용자가 다른 장치에 이를 입력해야 하는 인증 단계의 상호 운용성을 최대화하기 위해 이러한 인코딩 방식을 사용해야 한다.

Base-10 숫자

P를 숫자 문자열로 인코딩하려면 다음 단계를 따른다.

1. P를 base-10 정수 N으로 변환한다.

2. N이 9자리보다 적은 경우:

   • N의 왼쪽을 3 - len(N) mod 3자리만큼 0으로 채운다.

   • N을 세 자리씩 묶고 대시로 구분하여 출력한다.

3. N이 9자리보다 많은 경우:

   • N의 왼쪽을 4 - len(N) mod 4자리만큼 0으로 채운다.

   • N을 네 자리씩 묶고 대시로 구분하여 출력한다.

문자열 N을 PSK P로 디코딩하려면 다음 단계를 따른다.

1. N에서 대시와 선행 0을 제거한다.

2. N을 base-10 십진수로 파싱하여 P를 얻는다.

참고: 약 2^30에서 2^40 사이의 P 값은 길이가 10자리에서 12자리 사이인 값을 생성한다. 12자리를 초과하는 값은 입력하기 불편하며 추가 보안 가치가 제한적이다.

참고: 여기에서는 hexadecimal encoding 사용을 허용하지 않는다. 이는 base-10 numeric encoding과 모호할 수 있고, 모든 장치가 영숫자 입력을 지원하지는 않을 수 있기 때문이다.

QR 코드

PSK를 QR 코드로 인코딩하려면 다음 단계를 따른다.

1. N을 P 값을 ASCII 인코딩된 hexadecimal 문자열로 변환한 값으로 설정한다.

2. 값 N으로 text QR code를 구성한다.

QR 코드가 주어졌을 때 PSK P를 디코딩하려면 다음 단계를 따른다.

1. QR 코드를 디코딩하여 문자열 N을 얻는다.

2. N을 hexadecimal number로 파싱하여 P를 얻는다.