September 2009 doc.: IEEE 802.15-0697-00 June 2010 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)‏ Submission Title: Key Negotiation using DIET HIP Date Submitted: 22 June, 2010 Source: Robert Moskowitz (ICSAlabs, an Independent Division of Verizon Business Systems)‏ Address: Detroit, MI USA Voice:[…], FAX: […], E-Mail: robert dot moskowitz at icsalabs dot com Re: A very light key negotiation protocol using standard components Abstract: Even with recent enhancements, the Host Identity Protocol base EXchange, RFC 5201-bis is still considered too much for sensor. This document presents the HIP DIET Exchange; a truly minimalistic key exchange protocol.. Purpose: Present the HIP key negotiation protocol, what changes are necessary to lighten it, and then the design of the DIET Exchange. Notice: This document has been prepared to assist the IEEE P802.15. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15. Robert Moskowitz (ICSAlabs/VzB) Michael Bahr (Siemens AG) et al.

Key Negotiation using DIET HIP September 2009 doc.: IEEE 802.15-0697-00 June 2010 Key Negotiation using DIET HIP Robert Moskowitz (ICSAlabs, an Independent Division of Verizon Business Systems)‏ Robert Moskowitz (ICSAlabs/VzB) Michael Bahr (Siemens AG) et al.

Host Identities are typically cryptographic RSA, DSA, ECC public keys September 2009 doc.: IEEE 802.15-0697-00 June 2010 What is HIP? A protocol to securely exchange Host Identities and so doing, establish a security context Host Identities are typically cryptographic RSA, DSA, ECC public keys Bind to an End Point Identifier In IP, an address known to the applications and internally mapped to the routable address Robert Moskowitz (ICSAlabs/VzB) Michael Bahr (Siemens AG) et al.

In HIP the End Point Identifier is Host Identity Tag (HIT) in IPv6 September 2009 doc.: IEEE 802.15-0697-00 June 2010 What is HIP? In HIP the End Point Identifier is Host Identity Tag (HIT) in IPv6 Local Scope Identifier (LSI) in IPv4 HITs and LSIs are typically only known to the applications and do not transit the network The Encapsulating Security Payload (ESP, RFC 4303) from IPsec is Used to secure and transport communications between hosts Others MAY be defined Robert Moskowitz (ICSAlabs/VzB) Michael Bahr (Siemens AG) et al.

In some instances, the Internetwork layer could be discarded September 2009 doc.: IEEE 802.15-0697-00 June 2010 What is HIP? HIP's notion of an End Point Identifier disassociates the current tight binding between the Internetwork and Transport layers In some instances, the Internetwork layer could be discarded HIP can provide a security context at the Media layer Independent of any use of IP Robert Moskowitz (ICSAlabs/VzB) Michael Bahr (Siemens AG) et al.

SIGMA Compliant authenticated Diffie- Hellman key exchange September 2009 doc.: IEEE 802.15-0697-00 June 2010 What is HIP? HIP is architecturally ideally suited to be a Key Management System (KMS) for both IP and MAC layers Current status RFC 4423, 5201-5206 Going through revisions, -bis Internet Drafts available SIGMA Compliant authenticated Diffie- Hellman key exchange Current Base Exchange (BEX) Robert Moskowitz (ICSAlabs/VzB) Michael Bahr (Siemens AG) et al.

What is SIGMA Compliant September 2009 doc.: IEEE 802.15-0697-00 June 2010 What is SIGMA Compliant SIGning and MACing Defined by Hugo Krawczyk Technion University and IBM Origin and theory: http://webee.technion.ac.il/~hugo/sigma.ps Diffie-Hellman based 3 packets typical Ephemeral DH provides Perfect Forward Secrecy (PFS) Use of MAC proves correctness of the DH key and thereby guarantees freshness Robert Moskowitz (ICSAlabs/VzB) Michael Bahr (Siemens AG) et al.

The Basics of the HIP exchange September 2009 doc.: IEEE 802.15-0697-00 June 2010 The Basics of the HIP exchange 4 packet exchange to deal with flooding attacks Initiator Responder I1: DH list --------------------------> select precomputed R1 <------------------------- R1: puzzle, D-H, key, sig check sig remain stateless solve puzzle I2: solution, D-H, {key}, mac/sig --------------------------> compute D-H check puzzle check mac & sig <-------------------------- R2: mac/sig check mac & sig compute D-H The first packet reverses the direction of the authenticated DH, thereby protecting the responder from flooding (+ address verification + puzzle). Robert Moskowitz (ICSAlabs/VzB) Michael Bahr (Siemens AG) et al.

HIP Basics Cryptographic components 'Public' Key Hashing HMAC September 2009 doc.: IEEE 802.15-0697-00 June 2010 HIP Basics Cryptographic components 'Public' Key RSA, DSA, or ECDSA Hashing SHA-1, SHA-256, SHA-384 HMAC Diffie-Hellman Modulo and Elliptic Curve AES Many modes of operation supported through ESP from IPsec Robert Moskowitz (ICSAlabs/VzB) Michael Bahr (Siemens AG) et al.

A minimal HIP implementation September 2009 doc.: IEEE 802.15-0697-00 June 2010 A minimal HIP implementation Least amount of Crypto ECDSA, SHA-1, HMAC, ECDH, AES-CCM Still a lot of crypto and code ECDSA keys derived at device setup ECDH keys 'ephemeral' but could be limited to when symmetric keys are exhausted (once a month?) Code space more concern if long-term keys are used Can we do with less? Robert Moskowitz (ICSAlabs/VzB) Michael Bahr (Siemens AG) et al.

September 2009 doc.: IEEE 802.15-0697-00 June 2010 Putting HIP on a Diet Step back and review the components of a Key Management System Exclude Password based approaches Password installation IS the KMS, that is a manual KMS 'Public' key based approaches only proven method Must prove ownership of the private key while providing a shared secret key TLS uses Key encryption by the public key IPsec uses Diffie-Hellman key exchange Robert Moskowitz (ICSAlabs/VzB) Michael Bahr (Siemens AG) et al.

September 2009 doc.: IEEE 802.15-0697-00 June 2010 Putting HIP on a Diet Diffie-Hellman based secrets are NOT uniformly distributed (this IS important!) From draft-irtf-cfrg-kdf-uses-00.txt Must be passed through a Key Derivation Function to 'Extract' a uniformly random key (e.g. HMAC) Robert Moskowitz (ICSAlabs/VzB) Michael Bahr (Siemens AG) et al.

Putting HIP on a Diet If Hashing is removed HMAC is removed September 2009 doc.: IEEE 802.15-0697-00 June 2010 Putting HIP on a Diet If Hashing is removed HMAC is removed CMAC is be a partial replacement Puzzle construction and Key Expansion Diffie-Hellman is removed Requires HMAC Public Key Signatures are lost Requires Hashing to avoid forgeries CMAC cannot protect against forgeries Only Public Key Encryption remains Robert Moskowitz (ICSAlabs/VzB) Michael Bahr (Siemens AG) et al.

Putting HIP on a Diet With PK Encryption September 2009 doc.: IEEE 802.15-0697-00 June 2010 Putting HIP on a Diet With PK Encryption Randomly generated a key and Public key encrypted for transmission This replaces the Diffie-Hellman key Key derivation can then use methods like CMAC Loss of Perfect Forward Secrecy (PFS) If Public key is compromised, all prior secrets encrypted with it are compromised PFS CAN be approached as each party contributes to the initial key in a hidden manner Robert Moskowitz (ICSAlabs/VzB) Michael Bahr (Siemens AG) et al.

Putting HIP on a Diet Use CMAC in puzzle creation and solution September 2009 doc.: IEEE 802.15-0697-00 June 2010 Putting HIP on a Diet Use CMAC in puzzle creation and solution Just needs a bit of work Find a 'simple' compress function for HIT creation 160, 224, or 256 bits down to 96 with collision avoidance. Alternatively encrypt public value with Host ID Robert Moskowitz (ICSAlabs/VzB) Michael Bahr (Siemens AG) et al.

Putting HIP on a Diet 'Key' sacrifices in HIP “Diet' September 2009 doc.: IEEE 802.15-0697-00 June 2010 Putting HIP on a Diet 'Key' sacrifices in HIP “Diet' Diffie-Hellman comes at a very high crypto cost Requires HMAC and thus a hash function to derive keys ECDSA requires a hash Collision resistance required to avoid existential forgeries. Sacrificing these means deviating from SIGMA But could follow closely Robert Moskowitz (ICSAlabs/VzB) Michael Bahr (Siemens AG) et al.

Putting HIP on a Diet A 'Dietetic' HIP exchange COULD be achieved with September 2009 doc.: IEEE 802.15-0697-00 June 2010 Putting HIP on a Diet A 'Dietetic' HIP exchange COULD be achieved with AES-CCM (and CMAC) Elliptic Curve encrypt Proves private key ownership 'Simple' compress function Or alternatively encrypt of a public value Following is DEX protocol The network is the attacker model used Assume both malicious Responder and Initiator Robert Moskowitz (ICSAlabs/VzB) Michael Bahr (Siemens AG) et al.

HIP Diet Exchange (DEX) September 2009 doc.: IEEE 802.15-0697-00 June 2010 HIP Diet Exchange (DEX) Parties are I ::= Initator R ::= Responder MR ::= Malicious Responder MI ::= Malicious Initator Functions are ECR ::= ECC ElGamal Encryption MAC ::= CMAC | ::= concatination EX ::= Key expansion extraction Robert Moskowitz (ICSAlabs/VzB) Michael Bahr (Siemens AG) et al.

HIP Diet Exchange (DEX) September 2009 doc.: IEEE 802.15-0697-00 June 2010 HIP Diet Exchange (DEX) Values are PK ::= Public key of e.g. Pki is Public key of I t ::= retransmit timer value and lifetime n ::= nonce Pn ::= Puzzle based on and containing nonce n Sn ::= Puzzle solution based on nonce n x,y ::= random secrets Robert Moskowitz (ICSAlabs/VzB) Michael Bahr (Siemens AG) et al.

HIP Diet Exchange (DEX) September 2009 doc.: IEEE 802.15-0697-00 June 2010 HIP Diet Exchange (DEX) The HIP DEX exchange is identified by a DEX HIT I or MI R or MR I1 ::= () ------> R1 ::= <--- Pn, PKr I2 ::= t, Pn, Sn, PKi, ECR(PKr,n|x), MAC(x,(t, Pn, Sn, PKi, ECR(PKr,n|x))) ------> I or MI R R2 ::= <--- n, ECR(PKi,n|y), MAC(x, (n, ECR(PKi,n|y))) I R <--- Data, MAC(EX(x,y), Data) ------> Note be end of exchange, parties can ONLY be R and I. Robert Moskowitz (ICSAlabs/VzB) Michael Bahr (Siemens AG) et al.

HIP Diet Exchange (DEX) Dealing with a lossful network September 2009 doc.: IEEE 802.15-0697-00 June 2010 HIP Diet Exchange (DEX) Dealing with a lossful network HIP BEX can be slow with packet loss DEX MUST deal with high packet loss Implement a repeated send until ACK I aggressively sends I1 and continues send it until it receives R1 R sends R1 for every I1 received I aggressively sends I2 and continues send it until it receives R2, then it transitions to connected state R sends R2 for every I2 received, it transitions to connected state when no I2 within time t Robert Moskowitz (ICSAlabs/VzB) Michael Bahr (Siemens AG) et al.

HIP Diet Exchange (DEX) Dealing with a lossful network September 2009 doc.: IEEE 802.15-0697-00 June 2010 HIP Diet Exchange (DEX) Dealing with a lossful network Plus error handling events. E.G. I ignores R1s unless it has has sent an I1 This does have a battery drain attack M sends an I1 to R that looks as if it came from sensor Q On analysis really not different from any other reflector battery attack Robert Moskowitz (ICSAlabs/VzB) Michael Bahr (Siemens AG) et al.

HIP Diet Exchange (DEX) Adding Password Authentication September 2009 doc.: IEEE 802.15-0697-00 June 2010 HIP Diet Exchange (DEX) Adding Password Authentication Password Augmented Authentication Provides bootstrap mechanism to add a client to a server Supports emergency adHoc access EMT access to a Pacemaker Utility field technician to a substation controller Server implicitly invites password Auth R1 ALWAYS contains a challenge Initiator encrypts challenge with password and encrypts that in Responder's Public key Robert Moskowitz (ICSAlabs/VzB) Michael Bahr (Siemens AG) et al.

HIP Diet Exchange (DEX) Adding Password Authentication September 2009 doc.: IEEE 802.15-0697-00 June 2010 HIP Diet Exchange (DEX) Adding Password Authentication Challenge Encryption Use password as CMAC key MAC nonce from R1 puzzle RFC 4615 (AES-CMAC-PRF-128) is starting point Encrypting a challenge from R1 prevents replay attacks R1 cannot be reused if password response is accepted 'Rogue' Responder attack I cannot tell if R1 came from Responder or attacker unless Pkr from another source Need zero knowledge alternative As in IEEE 802.11s Robert Moskowitz (ICSAlabs/VzB) Michael Bahr (Siemens AG) et al.

Using HIP DEX for MACsec September 2009 doc.: IEEE 802.15-0697-00 June 2010 Using HIP DEX for MACsec HIP runs directly over MAC Use 802.1X ethertype? ICMP error messages Remove IP header and run directly over MAC No other considerations Robert Moskowitz (ICSAlabs/VzB) Michael Bahr (Siemens AG) et al.

Conclusions HIP DEX significantly reduced requirements over HIP BEX September 2009 doc.: IEEE 802.15-0697-00 June 2010 Conclusions HIP DEX significantly reduced requirements over HIP BEX Uses established cryptographic functions Easily analysed Full state machine for all event conditions KMS for both IP and MAC layers Further coding advantage Performs over lossful networks Robert Moskowitz (ICSAlabs/VzB) Michael Bahr (Siemens AG) et al.

Developing HIP DEX Research available 'compress' functions September 2009 doc.: IEEE 802.15-0697-00 June 2010 Developing HIP DEX Research available 'compress' functions Redesign puzzle to use CMAC Use RFC 4615 Develop KDF expand using CMAC Use RFC 4615 and NIST 800-108 Work with draft-mcgrew-fundamental- ecc author on fECC encrypt function Publish HIP DEX Internet Draft By end of June Robert Moskowitz (ICSAlabs/VzB) Michael Bahr (Siemens AG) et al.

Questions? September 2009 doc.: IEEE 802.15-0697-00 June 2010 Robert Moskowitz (ICSAlabs/VzB) Michael Bahr (Siemens AG) et al.