Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) ‏

1. Robert Moskowitz (ICSAlabs/VzB) 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.

2. Robert Moskowitz (ICSAlabs, an Independent Division of Verizon Business Systems)‏ Key Negotiation using DIET HIP Robert Moskowitz (ICSAlabs/VzB)

3. Robert Moskowitz (ICSAlabs/VzB) 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

4. Robert Moskowitz (ICSAlabs/VzB) 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

5. Robert Moskowitz (ICSAlabs/VzB) 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

6. Robert Moskowitz (ICSAlabs/VzB) 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)

7. Robert Moskowitz (ICSAlabs/VzB) 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

8. Robert Moskowitz (ICSAlabs/VzB) 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

9. Robert Moskowitz (ICSAlabs/VzB) 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

10. Robert Moskowitz (ICSAlabs/VzB) 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?

11. Robert Moskowitz (ICSAlabs/VzB) 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

12. Robert Moskowitz (ICSAlabs/VzB) 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)

13. Robert Moskowitz (ICSAlabs/VzB) 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

14. Robert Moskowitz (ICSAlabs/VzB) 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

15. Robert Moskowitz (ICSAlabs/VzB) 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

16. Robert Moskowitz (ICSAlabs/VzB) 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

17. Robert Moskowitz (ICSAlabs/VzB) 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

18. Robert Moskowitz (ICSAlabs/VzB) 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

19. Robert Moskowitz (ICSAlabs/VzB) 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

20. Robert Moskowitz (ICSAlabs/VzB) 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.

21. Robert Moskowitz (ICSAlabs/VzB) 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

22. Robert Moskowitz (ICSAlabs/VzB) 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

23. Robert Moskowitz (ICSAlabs/VzB) 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

24. Robert Moskowitz (ICSAlabs/VzB) 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

25. Robert Moskowitz (ICSAlabs/VzB) 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

26. Robert Moskowitz (ICSAlabs/VzB) 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

27. Robert Moskowitz (ICSAlabs/VzB) 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

28. Robert Moskowitz (ICSAlabs/VzB) Questions?