IPsec

IPsec    (wiki)

IPsec 자체는 end-to-end security scheme이다.

따라서 tunnel mode, transport mode 둘 다 end-to-end를 제공할 수 있지만 tunnel의 경우 host-to-host, network-to-network 등 gateway가 어디에 있느냐에 따라 end-to-end가 아닐 수 있다.

ESP

Encapsulating Security Payload format

Offsets	Octet16	0								1								2								3
Octet16	Bit10	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
0	0	Security Parameters Index (SPI)
4	32	Sequence Number
8	64	Payload data
…	…
…	…
…	…									Padding (0-255 octets)
…	…																	Pad Length								Next Header
…	…	Integrity Check Value (ICV) …
…	…

• SPI, Security Parameters Index (32 bits)
  Arbitrary value used (together with the destination IP address) to identify the security association of the receiving party.
• Sequence Number (32 bits)
  A monotonically increasing sequence number (incremented by 1 for every packet sent) to protect against replay attacks. There is a separate counter kept for every security association.
• Payload data (variable)
  The protected contents of the original IP packet, including any data used to protect the contents (e.g. an Initialisation Vector for the cryptographic algorithm). The type of content that was protected is indicated by the Next Header field.
• Padding (0-255 octets)
  Padding for encryption, to extend the payload data to a size that fits the encryption's cipher block size, and to align the next field.
• Pad Length (8 bits)
  Size of the padding (in octets).
• Next Header (8 bits)
  Type of the next header. The value is taken from the list of IP protocol numbers.
• ICV, Integrity Check Value (multiple of 32 bits)
  Variable length check value. It may contain padding to align the field to an 8-octet boundary for IPv6, or a 4-octet boundary for IPv4.

Security association ( SA )

The IP security architecture uses the concept of a security association as the basis for building security functions into IP. A security association is simply the bundle of algorithms and parameters (such as keys) that is being used to encrypt and authenticate a particular flow in one direction. Therefore, in normal bi-directional traffic, the flows are secured by a pair of security associations.

Security associations are established using the Internet Security Association and Key Management Protocol (ISAKMP). ISAKMP is implemented by manual configuration with pre-shared secrets, Internet Key Exchange (IKE and IKEv2), Kerberized Internet Negotiation of Keys (KINK), and the use of IPSECKEY DNS records. 

In order to decide what protection is to be provided for an outgoing packet, IPsec uses the Security Parameter Index (SPI), an index to the security association database (SADB), along with the destination address in a packet header, which together uniquely identify a security association for that packet. A similar procedure is performed for an incoming packet, where IPsec gathers decryption and verification keys from the security association database.

IKE          ( RFC2409 )

InternetKey Exchange is the protocol used to set up a security association (SA) in the IPsec protocol suite. IKE builds upon the Oakley protocol and ISAKMP. IKE uses X.509 certificates for authentication - either pre-shared or distributed using DNS (preferably with DNSSEC) and a Diffie–Hellman key exchange - to set up a shared session secret from which cryptographic keys are derived. In addition, a security policy for every peer which will connect must be manually maintained.

RFC 2409

   IKE implementations MUST support the following attribute values:

      - DES [DES] in CBC mode with a weak, and semi-weak, key check

      (weak and semi-weak keys are referenced in [Sch96] and listed in

      Appendix A). The key is derived according to Appendix B.

      - MD5 [MD5] and SHA [SHA}.

      - Authentication via pre-shared keys.

      - MODP over default group number one (see below).

   In addition, IKE implementations SHOULD support: 

3DES for encryption;

Tiger for hash; 

the Digital Signature Standard(DSS), RSA signatures and authentication with RSA public key encryption; 

and MODP group number 2.

IKE implementations MAY support any additional encryption algorithms defined in Appendix A and MAY support ECP and EC2N groups.

Note

IPSec에서 key distribution은 Diffie-Hellman을 사용하고 RSA는 옵션, 전자서명과 인증에만 사용한다.

RSA로 session key 암호화 해서 키분배 하면 되는데 Diffie-Hellman을 사용하는 이유는, RSA를 이용해 키분배하고 서버와 통신하던 중 서버가 탈취당했을 경우 서버에는 서버의 RSA private key가 남아있는 상태라서 클라이언트가 서버의 public을 이용해 session key를 암호화 해 보낸다면 서버를 탈취한 공격자가 쉽게 session key를 탈취할 수 있다.

Diffie-Hellman의 경우, 키 분배를 위해 설정했던 비밀값을 삭제하면 session key를 얻기 위해 다시 키 분배 과정을 거쳐야하므로 서버가 탈취당했다고 하더라도 session key를 얻을 수 없다.

물론 RSA도 키 분배에 사용했던 개인키와 공개키를 파기하면 위와 같은 개념으로 session key를 얻을 수 없게 된다.

그러나 RSA는 Diffie-Hellman에 비해 프로세싱 자원 소모가 커서 한 번 사용하고 key suite를 파기하는 식으로는 사용하지 않기 때문에, Diffie-Hellman을 사용한다.

Transport mode

In transport mode, only the payload of the IP packet is usually encrypted or authenticated. The routing is intact, since the IP header is neither modified nor encrypted; however, when the authentication header is used, the IP addresses cannot be modified by network address translation( NAT ), as this always invalidates the hash value. The transport and application layers are always secured by a hash, so they cannot be modified in any way, for example by translating the port numbers.

transport mode의 경우 선택의 여지 없이 end-to-end다.

Tunnel mode

default mode. In tunnel mode, the entire IP packet is encrypted and authenticated. It is then encapsulated into a new IP packet with a new IP header. Tunnel mode is used to create virtual private networks( VPN ) for network-to-network communications (e.g. between routers to link sites), host-to-network communications (e.g. remote user access) and host-to-host communications. 

tunnel mode는 이처럼 tunnel mode를 지원하는 gateway가 필요하다.( 일종의 VPN이다. )물론 host-to-host일 경우 gateway가 host 자신이 될 수 있다. 위 그림같은 상황이면 network-to-network라서, end host에 도착하기 전에 decryption되므로 end-to-end라고 보기 힘들다.