| 검색 | ?
대문 / 네트웍, 프로그래밍 / ISAKMP (Internet Security Association and Key Management Protocol)

ISAKMP (Internet Security Association and Key Management Protocol)

1.1. 개요

[https]RFC2408 - Internet Security Association and Key Management Protocol (ISAKMP)[]는 통신하고자 하는 양단간에 통신을 보호하기 위한 보안통신을 달성하기 위해서 필요한 암호화 및 무결성 확인을 방법이 정해지도록 일련의 절차들이 필요한데 이와 같은 일을 하도록 절차를 명시한 Protocol 이라고 할 수 있습니다.

이와 혼용해서 많이 표현되는 것중에 [https]RFC2409 - The Internet Key Exchange (IKE)[]가 있으며 이것은 ISAKMP가 명시한 절차에 필요한 구체적인 Protocol의 종류와 사용방법등을 정의한 것입니다. 그러나 이 둘간의 유사성이 매우 커서 2010년 9월에 개정된 [https]RFC5996 - Internet Key Exchange Protocol Version 2 (IKEv2)[]에서 IKE와 ISAKMP를 통합하여 정의하게 되었습니다.

보안을 만족하는 통신을 위해서 필요한 일련의 Protocol, Algorithm, Key, 그외의 속성들을 SA(Security Association, 보안 관련 집합정보)라고 하며 송신자와 수신자가 안전하게 이러한 정보를 교환하기 위해서 SA 및 Session-Key를 관리(생성, 협상, 삭제)할 수 있도록 하는 Protocol 중 하나가 ISAKMP라고 합니다.

대표적으로 IPSEC으로 통신하고자 하는 양단을 구현하기 위해서는 상호간 보안협상(Securify Association)이 필요하며 이를 위해서 구체적인 Protocol은 IKE를 이용하고 Packet의 format은 ISAKMP의 형식을 준수하도록 구현하여 이를 달성하게 됩니다.

ISAKMP는 다음과 같은 위치에서 역할을 합니다. (참고: [https]RFC2408 Section 2.2 ISAKMP Placement[])
ISAKMP_Placement.png
[PNG image (26.5 KB)]
  • ISAKMP는 기본적으로 모든 전송 Protocol 또는 IP를 통해서 구현될수 있습니다.
  • "DOI(Domain of Interpretation) Definition"는 실제 통신에 사용되는 값들이 어떤 구조하에 어떤 의미로 사용되는지를 정의해 놓은 것을 말합니다.
  • "Key Exchange Definition"은 Diffie-Hellman Key Agreement Method (Diffie-Hellman 키 분배 방법)과 같은 Key교환에 대한 방법을 말합니다.
  • "API"는 ISAKMP와 Security Protocol과의 Interface를 말합니다. (예를 들면 Linux의 경우 Netlink를 통한 xfrm module과의 Interface나 PF_KEY를 통한 Key관리등이 있습니다.)
  • "Security Protocol"은 AH(Authentication Header)이나 ESP(Encapsulation Security Protocol)와 같은 IP level (OSI Layer 3) 에서 동작하는 보안 Protocol 규약들을 말합니다.

이 문서를 작성하는 시점에서 RFC문서의 상황을 정리하면 크게 IKEv1과 IKEv2 계열로 나뉘어 구분할 수 있으며 이 두가지는 상호간 함께 운영하는 것이 고려되지는 않지만 공통으로 사용할 수 있는 Header format을 사용하면서 명확히 구분되어 사용할 수 있습니다.

1.2. 요구사항

ISAKMP는 Message를 교환하는데 있어서 강한인증(strong authentication)기능을 제공해야 하며 이를 위해서 다음을 만족하도록 정의됩니다.
  • IP주소등이 위조가 가능하지 않도록 합니다.
  • 암호학적인 요소로 보호되는 방식을 포함합니다.
  • 디지털 서명 알고리즘을 지원해야 하지만, 특정한 알고리즘에 제약되어 제한을 두지는 않습니다.
  • 모든 전송 protocol을 통해서 구현이 가능하지만 모든 구현에는 UDP port 500번을 사용하는 송신 및 수신 기능이 포함되어야 합니다.

1.2.1. 키 교환(Key exchange) 요소

  • 키 설정 (Key establishment)
    • 키 생성(Key generation)
    • 키 전달(Key transportation)
      • 송신자가 임의의 Session Key를 생성한 후 수신자의 공개키로 암호화하여 상대방에게 전달하고 수신자는 이를 자신의 비밀키로 복호화하여 Session Key를 알아낼 수 있는 방법입니다.
  • 키 교환 인증 (Key exchange Authentication)
    • Key를 교환 중이거나 교환이 완료된 이후에도 발신자를 인증할 수 있어야 합니다.
    • Key 교환이 완료되기 전에 Session Key를 가지고 있다는 것을 증명하는 방법의 경우 인증되지 않은 메세지에 대한 불필요한 컴퓨팅 자원을 소모하지 않도록 할 수 있어 키 교환을 완료 후 인증하는 것보다 유용합니다.
  • 키 교환 대칭성 (Key exchange symmetry)
    • 키 교환하는 양쪽중에 어디서나 키 교환을 시작할 수 있는 성질을 말하는데 누가 키 교환을 시작했는지와 상관없도록 하는 것이기에 [https]반향공격(Reflection attack)[]에 대한 취약성에 유의해야 합니다.

1.2.2. SA(Security Association, 보안 관련 집합정보) 요소

  • SPI (Security Parameter Index) (참고: [https]RFC4303 - Section 2.1. Security Parameters Index (SPI)[])
    • SA를 식별하기 위해서 각 보안 프로토콜들은 SPI(Security Parameter Index)를 나타내는 영역을 가지고 있으며 이는 시스템 내에서 유일한 값으로 사용합니다.
  • DOI (Domain of Interpretation) (참고: [https]RFC2407 - The Internet IP Security Domain of Interpretation for ISAKMP[])
    • 다음 요구사항에 대한 규약(Convention)을 말합니다. (해석하는 기준을 정의한 집합)
      • define the naming scheme for DOI-specific protocol identifiers
      • define the interpretation for the Situation field
      • define the set of applicable security policies
      • define the syntax for DOI-specific SA Attributes (Phase II)
      • define the syntax for DOI-specific payload contents
      • define additional Key Exchange types, if needed
      • define additional Notification Message types, if needed
  • Situation (참고: [https]RFC2407 - Section 4.2. IPSEC Situation Definition[])
    • 협상에 필요한 보안 서비스를 결정하기 위해서 필요한 모든 정보를 말합니다.
  • Exchange Type
    • 메세지의 수와 Payload들이 정의되며 익명성, [https]PFS(Perfect Forward Secrecy)[], 인증등의 서비스를 달성하기 위해서 메세지의 교환 형태가 정의된 것을 말합니다.
  • Payload
    • DOI (Domain of Interpretation)에서 여러종류의 payload 들이 정의되고 SA 내용 및 키 교환을 위한 내용들을 전송하기 위해서 생성 및 해석을 합니다.
  • 제안 및 협상 (Proposal)
    • 제안자가 선택할 수 있는 요소들을 열거하고 이들 중에서 수신자가 선호하거나 가능한 요소들를 선택하도록 하여 제안자와 수신자가 가장 선호하는 형태의 구현을 선택하도록 하는 것을 말합니다.

1.3. ISAKMP 단계(Phase)

ISAKMP는 단계1(Phase 1)과 단계2(Phase 2)의 두 단계로 나뉘어 구분될 수 있습니다.

단계1(Phase 1)에서는 단계2(Phase 2)에서 협상(Negotiation)하는 일련의 과정들을 보호하기 위해서 사용될 SA(Security Association, 보안 관련 집합정보)를 생성하여 교환하는 과정이며 단계2(Phase 2)의 협상(Negotiation)할 때의 Data들을 암호화 하는데 사용됩니다. 이로써 단계2(Phase 2)에서 생성 및 교환된 SA(Security Association, 보안 관련 집합정보)는 안전하게 보호될 수 있으며 이를 이용하여 실제 Data의 통신을 안전하게 보호할 수 있게 됩니다.

1.4. Payload 구조

1.4.1. ISAKMP Header Format

  • ISAKMP message는 다음과 같은 header(HDR) 구조에 맞춰 교신을 시작하며 추가적인 payload가 뒤따를 수 있습니다. (참고: [https]RFC2408 Section 3.1 ISAKMP Header Format[])
    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    Initiator Cookie
    (8 octets)
    Responder Cookie
    (8 octets)
    Next Payload (1 octet) Major version (4 bits) Minor version (4 bits) Exchange Type (1 octet) Flags (1 octet)
    Message ID (4 octets)
    Length (4 octets)
    • "Initiator Cookie" : ISAKMP SA를 시작하는 Initiator가 붙이는 식별자입니다. SA에 대한 통보나 삭제등에 사용됩니다.
    • "Responder Cookie" : ISAKMP SA를 수신하는 Responder가 붙이는 식별자입니다. SA에 대한 통보나 삭제등에 사용됩니다.
    • "Next payload" : 다음에 오는 첫번째 Payload의 유형를 나타냅니다.
      값 의미
      0 NONE
      1 Security Association (SA)
      2 Proposal (P)
      3 Transform (T)
      4 Key Exchange (KE)
      5 Identification (ID: IDi/IDr)
      6 Certification (CERT)
      7 Cerificate Request (CR)
      8 Hash (HASH) (AUTH)
      9 Signature (SIG)
      10 Nonce (NONCE)
      11 Notification (N)
      12 Delete (D)
      13 Vendor (VID)
      14~127 RESERVED
      128~255 Private Use
    • Major / Minor version field
    • "Exchange Type" : Message의 교환 유형를 나타냅니다.
      IKEv1
      값 의미
      0 None
      1 Base
      2 Identify Protection
      3 Authentication Only
      4 Aggressive
      5 Informational
      6~31 ISAKMP Future Use
      32~239 DOI(Domain of Interpretation) Specific Use
      240~255 Private Use
      • "Base" 교환 : 4개의 Message로 구성됩니다.
      • "Identify Protection" 교환 : 기본적으로 Base와 전달되는 Payload들은 같지만 6개의 Message로 구성됩니다.
      • "Authentication Only" 교환 : Key 를 생성하지 않고 인증만을 위해서 사용되는 Message 교환입니다.
      • "Aggressive" 교환 : 3개의 Message만으로 상대방을 인증하고 SA의 보호를 위한 Key까지 생성합니다.
      • "Informational" 교환 : 일방적으로 단순히 정보를 전달(Notification)하거나 특정 SA를 지우는(Delete) 명령을 보내고 끝냅니다.
    • "Flags" : Message의 교환 형태에 필요한 특정 옵션을 나타냅니다.
      Bit(0 ~ 7) 의미
      0 E(ncryption Bit)
      1 C(ommit Bit)
      2 A(uthentication Only Bit)
      3 ~ 7 RESERVED(항상 0으로 설정되어 있어야 함)
    • "Message ID" : Phase2 (2단계) Message 교환을 위해서 사용하는 ID입니다. Phase1 (1단계) Message 교환중에는 이 값이 반드시 0이어야 합며 Phase2(2단계) 협상과정중에 Protocol의 상태를 나타내주는 Unique한 Message Identifier로 이용됩니다. 이 값은 Initiator가 난수(Random)값으로 생성합니다.
    • "Length" : Header를 포함한 전체 Message의 길이(Header size + Payload size) 를 octet단위로 나타냅니다.

1.4.2. Generic Payload Header

  • 모든 Payload들은 다음과 같이 Generic Payload Header구조로 나타내며 Next payload에 의해서 Chaining방식으로 packet을 build할 수 있습니다. (참고: [https]RFC2408 Section 3.2 Generic Payload Header[])
    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    Next Payload (1 octet) RESERVED (1 octet) Payload Length
    (Payload)
    • "Next Payload" : 다음 Payload의 유형이며 마지막 Payload에서는 이 값이 0(NONE)으로 표시되어야 합니다. 이 값에 의해서 다음 Payload가 연달아서 연결되어 올 수도 있다는 것을 알 수 있습니다.
    • "RESERVED" : 반드시 0으로 설정되어야 합니다.
    • "Payload length" : Header를 포함한 길이(Header size + Payload size) 를 octet단위로 나타냅니다.
  • 즉, 예를 들자면 다음과 같은 형태로 packet이 빌드됩니다.
    ISAKMP_payload_chaining.png
    [PNG image (49.47 KB)]


1.4.3. Data Attributes

  • ISAKMP Payload안에는 여러가지 속성들(Attributes)이 기술되어야 할 필요가 있습니다. 이 경우 속성값들을 표현하기 위해서 다음과 같은 구조로 나타냅니다. (참고: [https]RFC2408 Section 3.3 Data Attributes[])
    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    AF (1 bit) Attribute Type (15 bits) AF=0 ? Attibute Length (2 octets)
    AF=1 ? Attribute Value (2 octets)
    AF=0 ? Attibute Value (Variable size: Attibute Length)
    AF=1 ? Not Transmitted
    • "AF" : 0인 경우 "Attribute Length"에 의한 가변 크기의 Data를 Attibute Value로 나타낼 수 있으며 1인 경우 고정된 2 octets크기의 Data를 나타내도록 합니다.
    • "Attribute Type" : 표현하고자 하는 속성의 식별값이며 DOI(Domain of Interpretation)에 정의되어 있습니다.
    • "Attribute Length" : "AF"가 0 인 경우 실제 Data 의 길이를 나타냅니다. "AF"가 1인 경우 2 octets 크기의 값을 나타낼 수 있습니다.
    • "Attribute Value" : "AF"가 0 인 경우 "Attribute Length"에 명시한 크기만큼의 Data를 나타냅니다.

1.4.4. Security Association Payload

  • 이 payload는 Security Attribute들, DOI에서 정의하는 사항, 협상에 대한 Situation등을 명시합니다. (참고: [https]RFC2408 Section 3.4 Security Association Payload[])
    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    Next Payload (1 octet) RESERVED (1 octet) Payload Length
    Domain of Interpretation (DOI) (4octets)
    (Situation) (Variable length)
    • "DOI" : 32bit 부호없는 정수형이며 1단계(Phase 1)중에는 0의 값으로 지정하며 2단계(Phase 2) 과정중에 IPSec을 기술하기 위해서 1의 값을 지정합니다. (IPSec 뿐만 아니라 SNMPv3, RIPv3등의 보안이 적용되는 다양한 프로토콜이 적용될 수 있기 때문에 해당하는 Payload에 어떤 프로토콜에 대한 내용을 담는지를 DOI로 지정하게 됩니다.)
      • 값이 0인 경우는 "Generic ISAKMP SA"를 지칭합니다.
      • 값이 1인 경우는 "IPSec DOI"([https]RFC2407 - The Internet IP Security Domain of Interpretation for ISAKMP[])를 지칭합니다.
      • 그 밖에 나머지는 IANA에서 미래를 위해서 예약된 값이며 RFC와 같은 사양을 연계참조하지 않고 임의로 값을 할당하지는 않습니다.
    • "Situation" : DOI에서 지정한 필드규격에 맞게 가변길이로 표현됩니다. (참고: [https]RFC2407 Section 4.6.1 Security Association Payload[]

1.5. 참고자료


Copyright ⓒ MINZKN.COM
All Rights Reserved.