RFC 4949

RFC 4949 는 인터넷 문서들이 보안 용어를 같은 뜻으로 쓰게 해 줍니다. 인증이나 인가처럼 자주 쓰는 보안 용어마다 뜻을 하나씩 달아 둔 용어집입니다. 문서를 쓰는 사람은 여기서 용어를 고릅니다. 읽는 사람은 모르는 말을 여기서 찾습니다.

상세

이 문서가 하는 일

RFC(Request for Comments)는 인터넷 기술 문서에 번호를 붙여 내놓는 문서 묶음입니다. 번호를 붙여 내놓는 곳은 IETF(Internet Engineering Task Force)라는 인터넷 표준 단체입니다. RFC 4949 는 그 묶음의 4949번 문서입니다.

4949번 문서는 정보 시스템 보안에 쓰는 용어를 모은 용어집입니다. 제목은 「Internet Security Glossary, Version 2」, 우리말로 「인터넷 보안 용어집 2판」입니다. 항목이 1,600개가 넘습니다. 항목만 334쪽입니다.

항목 하나가 용어 하나를 맡습니다. 인증 · 인가 · 재전송 공격 같은 용어가 저마다 한 항목을 차지합니다. 항목마다 뜻과 함께 그 말을 문서에 써도 되는지가 적혀 있습니다.

이 용어집이 겨냥하는 독자는 인터넷 문서를 쓰는 사람입니다. 새 프로토콜이나 보안 기법을 문서로 내놓을 때 용어를 여기서 골라 씁니다. 읽는 쪽도 보안 문서에서 모르는 말을 만나면 여기서 뜻을 찾습니다.

용어를 하나로 맞추는 까닭

같은 개념을 문서마다 다른 말로 부르면 읽는 사람이 헤맵니다. 두 말이 같은 것을 가리키는지 미묘하게 다른지부터 따져야 합니다. 표준 문서에서는 이 헤맴이 구현의 차이로 번집니다.

그래서 이 용어집은 문서를 쓸 때 지킬 원칙 넷을 세웁니다.

1. 같은 개념에는 언제나 같은 용어와 같은 정의를 씁니다
2. 사전에 나오는 가장 평범한 뜻으로 씁니다
3. 공개된 글에서 이미 널리 쓰이는 말을 씁니다
4. 특정 업체나 특정 기술의 편을 드는 용어는 피합니다

한 무리에서만 통하는 별명도 피하라고 권합니다. 그 무리에서는 익숙한 별명이 다른 무리에서는 헷갈림을 낳기 때문입니다. 새로 지어낸 말로 이미 널리 쓰이는 용어를 대신하는 일도 같은 까닭으로 피합니다.

표준이 아닌 참고 문서

RFC 라고 모두 표준은 아닙니다. 정식 표준으로 올라가는 문서가 따로 있습니다. 정보를 나누려고 내놓는 문서도 있습니다. RFC 4949 는 뒤쪽인 정보 제공용(Informational) 문서입니다.

그래서 이 용어집의 권고는 저자 한 사람의 의견입니다. IETF 가 공식 입장을 정한 것이 아닙니다.

이 용어집도 권고를 적을 때 SHOULD NOT · MAY 같은 영어 낱말을 대문자로 씁니다. 이런 낱말은 권고가 얼마나 센지를 나타냅니다. 강도를 읽는 법은 인터넷 표준 문서와 같습니다.

그 읽는 법을 정해 둔 문서가 RFC 2119입니다. MUST 는 반드시 지킬 것, SHOULD 는 까닭이 없으면 지킬 것, MAY 는 해도 되는 것입니다. 이 용어집에서도 강도는 같습니다. 그래도 권고 자체는 IETF 의 요구가 아니라 비공식 권고로 읽습니다.

대신 권고마다 이유를 같이 적어 둡니다. 쓰지 말기를 권하는(SHOULD NOT) 용어일수록 이유가 깁니다. 따를지는 읽는 사람이 그 이유를 보고 정합니다.

판과 저자

지금 판은 2007년 8월에 나온 2판입니다. 쓴 사람은 Robert W. Shirey 입니다. 2000년에 나온 1판 RFC 2828을 크게 고치고 늘려서 대체했습니다.

2007년 판이라 그 뒤에 나온 기술의 용어는 없습니다. 예를 들어 OAuth라는 말은 한 번도 안 나옵니다. 빠르게 바뀌는 최근 보안 분야는 덜 담겼을 수 있습니다.

영어도 한쪽으로 기울어 있습니다. 미국 영어를 기준으로 삼습니다. 정부나 국방 쪽 용어는 미국 용법만 다룹니다.

항목 하나의 생김새

항목 하나가 어떻게 생겼는지 예 하나로 봅니다. 아래는 「replay attack」 항목 전부입니다.

$ replay attack
   (I) An attack in which a valid data transmission is
   maliciously or fraudulently repeated, either by the
   originator or by a third party who intercepts the data
   and retransmits it, possibly as part of a masquerade
   attack. (See: active wiretapping, fresh, liveness,
   nonce. Compare: indirect attack, reflection attack.)

방금 본 항목은 네 부분으로 나뉩니다. 맨 앞의 $ 와 빈칸은 찾기용 표시입니다. 「$ replay attack」 으로 검색하면 이 말이 다른 항목의 설명 속에 나온 곳은 건너뛰고 정의 항목으로 바로 갑니다.

(I) 는 이 정의를 권하는지 알리는 딱지입니다. 딱지는 모두 넷입니다. 넷의 차이는 아래 「네 가지 딱지」 소절이 다룹니다. 딱지 뒤가 정의 본문입니다.

정의 끝의 괄호는 다른 항목으로 가는 안내입니다. See 뒤에는 함께 볼 용어가 옵니다. Compare 뒤에는 반대말이거나 눈여겨 갈라 볼 차이가 있는 항목이 옵니다. 위 항목은 함께 볼 용어로 논스를 걸었습니다.

뜻이 여럿인 용어는 정의에 번호를 붙입니다. 권하는 뜻이 앞에 옵니다. 서로 가까운 뜻은 1a · 1b 처럼 번호 뒤에 글자를 붙여 가릅니다.

어떤 정의는 특정 맥락에서만 맞습니다. 그럴 때는 맥락 이름을 빗금 두 개 사이에 넣어 표시합니다. /computer operating systems/ 는 「운영체제 맥락에서는」이라는 표시입니다.

정의 아래에 붙는 설명 노트

정의 아래에는 설명 노트가 붙기도 합니다. 설명 노트는 무엇을 담는지 알리는 이름표로 시작합니다. 자주 보는 이름표는 넷입니다.

표에 없는 이름표로 발음(Pronunciation)과 말의 유래(Derivation)도 있습니다. 설명 노트의 글은 다른 인터넷 문서에 옮겨 써도 됩니다(MAY).

네 가지 딱지

딱지는 두 가지를 한꺼번에 알립니다. 이 뜻을 인터넷 문서에 쓰라고 권하는지, 그리고 그 정의가 인터넷 쪽에서 왔는지입니다.

I 와 N 은 둘 다 권하는 뜻입니다. 둘의 차이는 뜻을 정한 권위가 어디 있느냐입니다. N 은 정부 · 업계 · 국제 기구 같은 바깥 권위가 먼저 정한 뜻을 받아 온 것입니다.

O 는 권하지 않는 뜻입니다. D 와 다른 점은 쓸 길이 하나 열려 있다는 것입니다. 인터넷 밖의 용어라고 밝히고 그 뜻을 같이 적으면 써도 됩니다. 권하지 않는 뜻을 싣는 까닭은 문서를 쓰는 사람이 알아 두게 하려는 것입니다.

바깥 권위의 정의가 인터넷 문서에 쓰기에는 낡았거나 좁을 때가 있습니다. 그러면 그 정의를 O 로 남깁니다. 바로 앞에는 그것을 대신할 I 나 N 정의를 둡니다.

D 딱지가 붙은 예로 인증서를 내주는 기관의 이름이 있습니다. 흔히 부르는 certificate authority 는 D 딱지를 달았습니다. 대신 certification authority를 쓰라고 권합니다. certificate authority 는 certification authority 를 부주의하게 쓴 말로 보인다는 것이 그 이유입니다.

문서를 쓰는 쪽에서 보면 딱지에 따라 할 일이 갈립니다.

flowchart TD
    A["쓰려는 용어의 항목을 찾는다"] --> B{"딱지가 무엇인가"}
    B -->|I 또는 N| C["그 뜻으로 쓴다<br/>맥락 표시가 있으면 그 맥락 안에서만"]
    B -->|O| D["인터넷 밖 용어라고 밝히고<br/>뜻을 같이 적는다"]
    B -->|D| E["쓰지 않는다<br/>설명 노트를 보고 다른 말을 고른다"]

갈라 쓰는 보안 용어

이 용어집에는 비슷해 보이는 말을 가르는 항목이 많습니다. 이 소절은 그중 셋을 봅니다. 셋 다 백엔드 코드와 문서에 자주 나오는 말입니다.

첫째는 verify 와 validate 입니다. verify 는 사실이나 값 하나가 참인지 확인할 때 씁니다. validate 는 여러 부품으로 짜인 것이 제대로 섰는지 확인할 때 씁니다. 그래서 서명은 verify 하고 인증서는 validate 한다고 말합니다.

인증서를 validate 하는 과정 안에는 verify 가 여럿 들어 있습니다. 인증서에 붙은 전자 서명을 verify 합니다. 지금 시각이 인증서의 유효 기간 안인지도 verify 합니다. 이렇게 확인한 조각들을 모아 인증서 전체를 validate 합니다.

둘째는 authenticate 입니다. 사람이나 프로세스처럼 시스템 안에서 움직이는 주체를 시스템 개체라고 부릅니다. authenticate 는 시스템 개체가 내세운 속성값이 맞는지 확인하는 일에만 씁니다. 로그인하는 사용자가 아이디를 내세우면, 그 아이디가 정말 그 사람의 것인지 확인하는 일이 authenticate 입니다.

일상 영어의 authenticate 는 「진품임을 입증한다」는 뜻도 있습니다. 그래서 데이터가 안 바뀌었는지 확인하는 일에도 이 말을 쓰고 싶어집니다. 이 용어집은 그런 일에는 authenticate 대신 verify 를 쓰기를 권합니다. 데이터가 안 바뀌었음을 지키는 성질은 무결성이라고 부릅니다.

셋째는 authorization 입니다. authorization 은 시스템 개체에게 시스템 자원에 접근해도 된다고 내주는 승인입니다. 누가 무엇을 해도 되는지 가르는 접근 제어가 이 개념 위에 섭니다.

authorization 과 같은 뜻으로 permission 과 privilege 도 쓰입니다. 이 용어집은 맥락마다 하나를 골라 쓰기를 권합니다. 역할 기반 접근 제어에서는 permission, 운영체제에서는 privilege 를 씁니다. 이 셋을 우리말로는 흔히 권한이라고 뭉뚱그려 부릅니다.

기댈 때와 기대지 않을 때

보안 설계 문서나 서비스 연동 문서를 쓰다가 용어가 헷갈리면 이 용어집을 기준으로 삼을 수 있습니다. 보안 RFC 를 읽다가 낯선 말을 만났을 때 뜻을 찾는 곳으로도 씁니다.

이미 그 말을 따로 정의해 둔 문서가 있으면 그 문서의 정의가 먼저입니다. 용어집의 설명은 그 문서의 글을 덮어쓰려고 쓴 것이 아닙니다.

법률 · 정부 · 업계 문서의 정의를 대신하지도 않습니다. 이 용어집의 정의는 그런 바깥 권위가 정한 정의와 꼭 맞지 않을 수 있습니다. 규제를 따르는 문서라면 그 규제가 쓰는 정의를 봐야 합니다.

관련 항목

이 용어집이 뜻을 정한 보안 용어

인증 · 인가 · 접근 제어 · 권한 · 재전송 공격 · 논스 · 무결성 · 기밀성 · 전자 서명 · 인증서 · 인증 기관 · 중간자 공격 · 취약점 · 위협 · 시스템 개체

이 용어집이 쓰임을 갈라 둔 용어

서명 검증 · 인증서 검증 · 인증 경로 · 신선도 · 활성 도청

이 문서를 내놓은 단체와 발행 절차

RFC · IETF · RFC 에디터 · 인터넷 드래프트 · 표준화 트랙 · 인터넷 표준

이 문서가 대체하거나 끌어다 쓰는 RFC

RFC 2828 · RFC 2119 · RFC 2026

이 용어들을 끌어다 쓰는 보안 기술

TLS · OAuth 2.0 · X.509 · 공개 키 기반 구조 · 역할 기반 접근 제어 · 속성 기반 접근 제어 · 다중 인증