Host Identity Protocol. Host Identity Protocol. Outline. Outline (cont) Host Identity Protocol Why HIP? Host Identity Protocol

Transcription

1 Outline Host Identity Protocol Petri Jokela (Editor) & Jukka Ylitalo Tik October 3, 2005 Host Identity Protocol Idea behind Setting up associations Mobility and multihoming Host mobility Host multihoming Additional functionality Registration Rendezvous mechanism changes 2 Outline (cont) Middleboxes NATs Standardization Current status implementation Host Identity Protocol Basics draft-ietf-hip-base-02 3 Host Identity Protocol basic idea Identity / locator split features Setting up connections Host Identity Protocol Why? provides a combination of useful features: Identifier-locator split Security Mobility IPv4 and IPv6 interoperability Multi-homing 5 6 1

2 Host Identity Protocol Why? They are available elsewhere but. IP addresses no longer work for identifying hosts is hard to configure Mobile IP is large and complex Mobile IPv4 and IPv6 do not work together No simple solutions for multiaccess Host Identity Protocol The basic idea Process Transport IP layer Link layer < IP addr, port> IP address 7 8 Host Identity Protocol The basic idea A new Name Space of Host Identifiers (HI) Process HIs = Public keys! HIs presented as Transport hash values Host Identity Tag Host identity HIT (IPv6) Local Scope Identifier IP layer LSI (IPv4) Sockets bound to HIs, not to IP addresses Link layer New layer translates IP addresses to HIs and vice versa < Host ID, port> Host ID IP address features Identifier-locator split Currently Hosts located using the IP address Hosts identified using the IP address Problems Mobile host new IP address new identity Connections to locations not entities 9 10 features Identifier-locator split features Security Hosts located using the IP address Hosts identified using a Host Identity (HI) Mobile host new IP address, same HI Connections to identities (HIs) The Host Identity is a public key Prove the ownership using private key Used for host authentication and setting up association Traffic protected with Encapsulating Security Payload (ESP) ESP SA establishment during base exchange

3 Host Identity Protocol packets draft-ietf-hip-base-02 I1, R1, I2, R2 Base exchange UPDATE change connection parameters Rekeying (e.g. SA lifetime expires) Setting up additional SAs Change in locators CER Send certificates CLOSE, CLOSE_ACK closing a association NOTIFY Notification messages Host Identity Protocol packets Packets consist of a HEADER and zero or more parameters header: Next Payload Len Type VER. RES. Controls Checksum Sender's Host Identity Tag (HIT) Receiver's Host Identity Tag (HIT) / / / / Host Identity Protocol are coded in Type-Length-Value format For different purposes: Puzzle solution Diffie-Hellman Transforms Signatures HMACs... Setting up connections draft-ietf-hip-base-02 draft-jokela-hip-esp base exchange 4-way handshake Creates a association Authentication of hosts Negotiates security parameters Diffie-Hellman Establishes ESP security associations Algorithms Keys Opportunistic mode if responder s identity unknown Use only destination IP address in initialization, learn HI query resolving the responder s locator Initiator query: Responder response: HI, IP address Responder

4 Initialization Initiator (IN) Packet I1 The Initiator packet Contains only header Opportunistic mode: Responder s HIT unknown I1: Initialization, Hello, I m here. I want to talk! Responder (RN) : Packet Type = 1 SRC HIT = Initiator's HIT DST HIT = Responder's HIT, or NULL Response: including ESP SA initialization Initiator (IN) R1: Challenge: Solve this puzzle D-H initialization, HI Responder Packet R1 PUZZLE, HOST_ID, [ ECHO_REQUEST, ] [, ECHO_REQUEST ] Reserved, 4 bytes R1 generation counter, 8 bytes - 64 bits - Current generation of valid puzzles - Incremented periodically by sender Responder (RN) Packet R1 PUZZLE, HOST_ID, [ ECHO_REQUEST, ] [, ECHO_REQUEST ] K, 1 byte Lifetime Opaque, 2 bytes Random #I, 8 bytes - Random #I (64 bits) - Initiator solves #J - K lowest bits of the hash must be zero Packet R1 PUZZLE, HOST_ID, [ ECHO_REQUEST, ] [, ECHO_REQUEST ] Group ID Public value / / padding - Group ID bit group 1 - OAKLEY well known group bit MODP group bit MODP group bit MODP group bit MODP group 6 - Public value is the Diffie-Hellman public key generated by the sender Initiator can calculate the shared secret

5 Packet R1 PUZZLE, HOST_ID, [ ECHO_REQUEST, ] [, ECHO_REQUEST ] Transform-ID #1 Transform-ID #2 Transform-ID #n Padding - Proposed transforms - Initiator selects one of them - Defined: - AES-CBC with HMAC-SHA1 1-3DES-CBC with HMAC-SHA1 2-3DES-CBC with HMAC-MD5 3 - BLOWFISH-CBC with HMAC-SHA1 4 - NULL-ENCRYPT with HMAC-SHA1 5 - NULL-ENCRYPT with HMAC-MD5 6 Packet R1 PUZZLE, HOST_ID, [ ECHO_REQUEST, ] [, ECHO_REQUEST ] Reserved E Suite-ID #1 Suite-ID #2 Suite-ID #3 Suite-ID #n Padding - Proposed ESP transforms - Initiator selects one of them - Defined: - AES-CBC with HMAC-SHA1 1-3DES-CBC with HMAC-SHA1 2-3DES-CBC with HMAC-MD5 3 - BLOWFISH-CBC with HMAC-SHA1 4 - NULL-ENCRYPT with HMAC-SHA1 5 - NULL-ENCRYPT with HMAC-MD Packet R1 PUZZLE, HOST_ID, [ ECHO_REQUEST, ] [, ECHO_REQUEST ] HI Length DI-type DI Length Host Identity / / Domain Identifier / / Padding - Responder s HI (public key) - At the moment: or - Domain Identifier - FQDN or NAI (login@fqdn) Packet R1 PUZZLE, HOST_ID, [ ECHO_REQUEST, ] [, ECHO_REQUEST ] Opaque data (variable length) - Opaque data: must be echoed back - May be covered by signature Packet R1 PUZZLE, HOST_ID, [ ECHO_REQUEST, ] [, ECHO_REQUEST ] SIG alg Signature / / Padding - Signature calculated over the packet, excluding - Initiator s HIT - checksum field - PUZZLE: opaque and #I - Any TLV after the signature TLV Puzzle solved, initiator continues with I2 Initiator (IN) -Solve puzzle -Generate keying material -Select ESP SPI I2: Puzzle solution, D-H parameters HI Initiator,SPI Initiator Responder (RN)

6 Reserved Keymat Index Old SPI New SPI - Keymat Index: tells the point from where keys are drawn from the keying material (zero in base exchange) - Old SPI (zero in base exchange) - New SPI; Initiator s ESP SPI - R1_COUNTER may be echoed back if it was in the received R1 packet K, 1 byte Reserved Opaque, 2 bytes Random #I, 8 bytes Puzzle solution #J, 8 bytes - #J: Calculated solution to the puzzle - SHA-1(I,HIT-I,HIT-R,J) - K lowest order bits must be zero Group ID Public value / / padding - Initiator s public D-H key value Responder can calculate the shared secret Initiator s selection for crypto functions - One of the proposed in R1 - Initiator s selection for ESP crypto functions - One of the proposed in R

7 Reserved IV / / / / / / Encrypted / data / / / / Padding - Encrypted Initiator s HI - HOST_ID TLV in Encrypted data field Opaque data (variable length) - If echo_request was present in R1, it must be echoed in a response HMAC - HMAC is calculated over the packet, excluding - checksum (zeroed) - TLVs following HMAC SIG alg Signature / / Padding - Signature calculated over the packet, excluding - Initiator s HIT - checksum field - PUZZLE: opaque and #I - Any TLV after the signature TLV Finalizing connection setup Initiator (IN) R2: SPI Responder -Verify puzzle -Generate keying material -Select ESP SPI Responder (RN) Packet R2 HMAC_2, _SIGNATURE Reserved Keymat Index Old SPI New SPI - Keymat index: tells the point where keys are drawn from the keying material (zero in Base exchange) - Old SPI (zero in Base exchange) - New SPI; Responder s ESP SPI

8 Packet R2 Packet R2 HMAC_2, _SIGNATURE HMAC HMAC_2, _SIGNATURE SIG alg Signature / / Padding - HMAC over the packet plus an additional senders HOST_ID, and excluding - checksum (zeroed) - TLVs following HMAC_2 - signature over the packet, excluding - checksum (zeroed) - Any TLVs following the signature Initiator (IN) Keying material Keying material generation Diffie-Hellman shared secret: K ij KEYMAT = K1 K2 K3... where ESP Security Association Responder (RN) K1 = SHA-1( Kij sort(hit-i HIT-R) 0x01 ) K2 = SHA-1( Kij K1 0x02 ) K3 = SHA-1( Kij K2 0x03 )... K255 = SHA-1( Kij K254 0xff ) K256 = SHA-1( Kij K255 0x00 ) etc Keying material Usage Draw keys encryption Direction 1 *) integrity (HMAC) Direction 1 *) encryption Direction 2 *) integrity (HMAC) Direction 2 *) Draw ESP keys ESP encryption Direction 1 *) ESP authentication Direction 1 *) ESP encryption Direction 2 *) ESP authentication Direction 2 *) Keysizes are natural sizes for used algorithms *) Depends on the numeric value comparison of HITs Mobility and Multihoming Host mobility and micromobility draft-ietf-hip-mm

9 features Mobility : UPDATE For updating location information Connections bound to constant Host Identities (HIs) Mobile host new locator (IP address) same connection endpoint (HI) Connections don t break Peer host informed of new locator (IP addr.) Mobility between IPv4 and IPv6 is supported SEQ, ACK, LOCATOR, ECHO_REQUEST/ ECHO_RESPONSE, Update ID - UPDATE sequence number - Updated by one for each new UPDATE - Scope: only the current association : UPDATE For updating location information : UPDATE For updating location information SEQ, ACK, LOCATOR, ECHO_REQUEST/ ECHO_RESPONSE, peer Update ID - One or more ACK parameters - Acks received Update IDs SEQ, ACK, LOCATOR, ECHO_REQUEST/ ECHO_RESPONSE, Reserved Keymat Index Old SPI New SPI - Keymat Index: tells the point from where keys are drawn from the keying material (zero in base exchange) - Old SPI (zero in base exchange) - New SPI; Initiator s ESP SPI : UPDATE For updating location information : UPDATE For updating location information SEQ, ACK, LOCATOR, ECHO_REQUEST/ ECHO_RESPONSE, Group ID Public value / / padding - public D-H key value - needed if rekeying requested SEQ, ACK, LOCATOR, ECHO_REQUEST/ ECHO_RESPONSE, Traffic Type Locator Type Locator Length Reserved Locator - Traffic type: signaling / user data - Locator type: IPv6, IPv4-in-IPv Locator is the new address - Can be multiple LOCATORs

10 : UPDATE For updating location information : UPDATE For updating location information SEQ, ACK, LOCATOR, [ ECHO_REQUEST/ ECHO_RESPONSE,] Opaque data (variable length) - Opaque data to be echoed back - Optional address check SEQ, ACK, LOCATOR, ECHO_REQUEST/ ECHO_RESPONSE, Opaque data (variable length) - Response to the echo_request : UPDATE For updating location information : UPDATE For updating location information SEQ, ACK, LOCATOR, ECHO_REQUEST/ ECHO_RESPONSE, HMAC - HMAC is calculated over the packet, excluding - checksum (zeroed) - TLVs following HMAC SEQ, ACK, LOCATOR, ECHO_REQUEST/ ECHO_RESPONSE, SIG alg Signature / / Padding - Signature calculated over the packet Location update Without rekeying Location update Without rekeying MN changes location UPDATE (LOCATOR, ESP_INFO SEQ, SIG) UPDATE ( SEQ, ACK, SIG, ECHO_REQUEST) MN MN MN association established CN CN

11 Location update Without rekeying Prevention against attacks MN UPDATE (ACK, SIG, ECHO_RESPONSE) prevents against impersonation attacks HMAC quick and cheap verification SIGNATURE third party DoS attack Optional address check the host is where it is supposed to be CN Multihoming Mobility and multihoming The presented mechanism can be used to ADD addresses Challenges source and destination address selection load balancing need to mesh SAs to avoid replay window problems SAs are symmetrically setup, but asymmetrical groups of addresses between hosts are possible updating keying material for a subset of SAs Future work: needed policies and procedures Work going on Integration with link layer detect link layer changes, signal to layer DNA Working Group integration with transport layer TCP congestion control draft-swami-tcp-lmdr-05.txt PFKEY specifications extensions to PFKEY to support SA movement MOBIKE Working Group Registration draft-koponen-hip-registration-00 Protocol that is used to register with services Server provides service (e.g. rendezvous, PATH) Client registers as a service user Additional functionality Server Service registration: draft-koponen-hip-registration-00 Client I1 R1 with service information I2 with possible registration R2 with confirmation / failure 66 11

12 based initial rendezvous Additional functionality Rendezvous extensions: draft-ietf-hip-rvs-01 : draft-ietf-hip-dns-01 Keys and/or HITs in IP addresses in PKI or SEC needed to secure binding from names to the keys does not support mobility well caching DYN is not considered to be fast enough Simultaneous movement problem A separate Rendezvous point is needed 68 Rendezvous server draft-ietf-hip-rvs-01 contains the location of the Rendezvous server (RVS) RVS has the current location of the MN MN constantly updates the location information to the RVS Three modes of operation specified (at the moment): I1_REWRITE I1_TUNNEL BIDIRECTIONAL Rendezvous server MN RVS 1. Base exchange (1st time only) 2. Registration (1st time only) 3. Location update (after movement) MN: HI, IP MN CN MN: HI, IP RVS Rendezvous server Rendezvous server RVS MN: HI, IP MN 2. Rewrite destination IP address, forward I1 to HIT MN, IP MN RVS MN: HI, IP MN MN MN: HI, IP RVS MN MN: HI, IP RVS 1. Query MN s address 2. Get: HI MN, IP RVS CN If necessary, 1. I1 to HIT MN, IP RVS rewrite source IP CN and add FROM parameter

13 Rendezvous server RVS MN R1, I2, R2 directly between hosts MN: HI, IP MN MN: HI, IP RVS CN modifications draft-ietf-hip-dns-01 We need support for maintaining HIs in the Two new RRs defined HI Stores HI and/or HIT Related to public key field of an IPSECKEY RR RVS node s Rendezvous Servers FQDN or IP address Related to gateway field of an IPSECKEY RR HIT based rendezvous HIT 128 bits long random number Decentralized lookup based on random identifier is hard => T based overlay like i3 based on T Hi3 Additional functionality NAT traversal 75 NAT traversal NATs general NATs Legacy NAT traversal Advanced -aware NAT traversal Four types of NATs RFC3489 Often used to give access to multiple hosts using single public IP address Rewriting the source address and port can break endto-end connectivity

14 NAT problems and NAT Without an open pin-hole, no incoming connections s may be broken IPs and ports used in payloads When using separate control and data plane connections p-2-p applications require knowledge about the address IP fragmentation Integrity protection may be broken if IP addresses are changed should make NAT traversal easier We don t care much about IP addresses base exchange and NAT NATs usually don t pass proto 99 we use over UDP IPv6: NATs are not a problem (at least yet) data exchange and NAT In checksums are calculated using HITs SPI values may collide Encapsulate over UDP (RFC 3948) Legacy NAT traversal draft-nikander-hip-path-00 host A Base exchange and registration - over UDP NAT :2157 == :1934 Pin-hole opened in NAT PATH server Host A is at :1934 host B Required for incoming connections Legacy NAT traversal draft-nikander-hip-path-00 host A NAT :2157 == :1934 PATH server Host A is at :1934 host B I1, via PATH server (RVS) Legacy NAT traversal draft-nikander-hip-path-00 host A R1, I2, R2 directly NAT :2158 == : :2157 == :1934 New pin-hole opened when R1 was sent to Host B PATH server Host A is at :1934 host B Legacy NAT traversal draft-nikander-hip-path-00 host A ESP SA NAT :2158 == : :2157 == :1934 PATH server Host A is at :1934 host B

15 aware NATs inspect base exchange, get HITs and SPI pairs SPIs in I2, R2 reads UPDATE messages for information update recalculates checksums SPINAT SPI based NATting Change addresses based on SPIs in ESP header Standardization draft-stiemerling-hip-nat-03.txt draft-tschofenig-hiprg-hip-natfw-traversal-01.txt 85 Standardization Evolution of drafts: Early era IETF: Working Group Targetted to be ready in summer 2005 ( fall?) Experimental RFCs Base ESP usage with Mobility and Multihoming Rendezvous mos-hip-00 May 1999 mos-hip-arch-00 Dec 1999 mos-hip-arch-00 Feb Jul Jul Jul Nov 2001 IETF: Research Group More research oriented discussion about locator / identity split Evolution of drafts: Restart Evolution of drafts: Current status mos-hip-arch-03 Apr 2003 mos-hip-06 May Sep Feb 2004 nik-hip-mm-00 Jun Jun 2004 ietf-hip-base-00 May Jul 2004 nik-hip-dns-00 May 2004 egg-hip-rvs-00 Jul 2004 ietf-hip-arch-00 ietf-hip-base-01 ietf-hip-mm-00 ietf-hip-dns-00 ietf-hip-rvs-00 ietf-hip-arch-00 ietf-hip-base-01 ietf-hip-mm-00 ietf-hip-dns-00 ietf-hip-rvs-00 ietf-hip-arch-02 Jan 2005 ietf-hip-base-02 Feb 2005 jok-hip-esp-00 Feb 2005 ietf-hip-mm-01 Feb 2005 ietf-hip-dns-01 Feb 2005 ietf-hip-rvs-01 Feb 2005 kop-hip-reg-00 Feb 2005 IESG evaluation Feb 2005 Base exchange Using ESP Mobility & Multihoming Rendezvous Registration

16 Implementation implementation on FreeBSD FreeBDS 5.3 Source code available at: base exchange Mobility and multihoming v4/v6 interoperability Implements currently draft-ietf-hip-base-01 draft-ietf-hip-mm-00 Under LoC 92 server D_DEBUG D_CONTEXT D_STATES D_PROTOCOL PF PFadmin PFres D_IO D_DEBUG D_CONTEXT D_STATES D_PROTOCOL PF PFadmin PFres D_DEBUG D_CONTEXT.C D_STATES.C D_PROTOCOL.C PF PFadmin PFres D_IO D_IO.C Context association HI IP address mappings Keying material Security Associations Security Policies States association state machine Incoming packet handling Packet validation Notifications on errors State transitions Timers

17 D_DEBUG D_CONTEXT.C D_STATES.C D_PROTOCOL.C PF PFadmin PFres D_DEBUG D_CONTEXT.C D_STATES.C D_PROTOCOL.C PF PFadmin PFres D_IO.C D_IO.C Protocol Packet generation Outgoing packets (PF) Resolver (PFres) Administrative tool (PFadmin) / () Incoming packets: callbacks to STATES TLV handling PF packet communication between the kernel and user space Incoming packets: callbacks to PROTOCOL D_DEBUG D_CONTEXT.C D_STATES.C D_PROTOCOL.C PF PFadmin PFres D_DEBUG D_CONTEXT.C D_STATES.C D_PROTOCOL.C PF PFadmin PFres D_IO.C D_IO.C PFadmin Administrative interface for the command-line tool PFres Interface to the resolver library D_DEBUG D_CONTEXT.C D_STATES.C D_PROTOCOL.C PF PFadmin PFres D_DEBUG D_CONTEXT.C D_STATES.C D_PROTOCOL.C PF PFadmin PFres D_IO.C D_IO.C Communication to and PF_KEY Key Management API, Version 2 (RFC 2367) D_IO Abstraction for socket input/output functions Handles creation, reading, writing, and closing of sockets

18 D_DEBUG D_CONTEXT.C D_STATES.C D_PROTOCOL.C PF PFadmin PFres D_DEBUG D_CONTEXT.C D_STATES.C D_PROTOCOL.C PF PFadmin PFres D_IO.C D_IO.C Cryptographic functions generation Diffie-Hellman calculations / signature and HMAC generation and verification Encryption/decryption of TLVs Debug Debugging functions Current state Keying material Packets from IO HIT resolver LSI-HIT hash table HIT resolver Resolves the HI based on FQDN Sends FQDN, HI, and IP addresses to the In case of IPv4, waits for the LSI from the LSI-HIT hash table Maps the LSI to the corresponding HIT for BEET processing Links BEET mode Encrypts / decrypts user data Converts HITs to IP addresses Converts IP addresses to HITs based on SPIs Has tunnel-mode semantics but transportmode format WG supplemental page Ericsson Research: for BSD project BEET mode BEET mode