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: 24 June, 2010 Source: Robert Moskowitz (ICSA labs, an Independent Division of Verizon Business)‏ 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 (ICSA labs, an Independent Division of Verizon Business)‏ 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) • But if only used to encrypt a uniformly random session key, this is mitigated

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 limited • Requires HMAC • Can encrypt a session key • Public Key Signatures are lost • Requires Hashing to avoid forgeries • CMAC cannot protect against forgeries

14. Robert Moskowitz (ICSAlabs/VzB) Putting HIP on a Diet • With ECDH limited to session key protection • Randomly generated a key and encrypted with DH derived key for transmission • This replaces the Diffie-Hellman key as the session key which requires HMAC • Key derivation from random key can use CMAC

15. Putting HIP on a Diet • Use of static DH means loss of Perfect Forward Secrecy (PFS) • Static DH (NIST SP 800-56A sec 6.3.2) used as device identities • If Private 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

16. 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. • Since ECDH public key really just computed directly from a random secret, simple truncation can be used.

17. Robert Moskowitz (ICSAlabs/VzB) Putting HIP on a Diet • 'Key' sacrifices in HIP “Diet' • Digital signatures • ECDSA requires a hash • Collision resistance required to avoid existential forgeries. • This sacrifice means deviating from SIGMA • But could follow closely

18. Robert Moskowitz (ICSAlabs/VzB) Putting HIP on a Diet • A 'Dietetic' HIP exchange COULD be achieved with • AES-CCM (and CMAC) • Static ECDH • Proves private key ownership • Following is DEX protocol • The network is the attacker model used • Assume both malicious Responder and Initiator

19. Robert Moskowitz (ICSAlabs/VzB) HIP Diet Exchange (DEX) • Parties are • I ::= Initator • R ::= Responder • MR ::= Malicious Responder • MI ::= Malicious Initator • Functions are • ECR ::= AES encrypt • MAC ::= CMAC • | ::= concatination • EX ::= Key expansion extraction

20. Robert Moskowitz (ICSAlabs/VzB) HIP Diet Exchange (DEX) • Values are • PK ::= Public key of • e.g. Pki is Public key of I • DH ::= Derived Diffie-Hellman key • n ::= nonce • Pn ::= Puzzle based on and containing nonce n • Sn ::= Puzzle solution based on nonce n • x,y ::= random secrets

21. 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 ::= Pn, Sn, PKi, ECR(DH,n|x), MAC(x,(Pn, Sn, PKi, ECR(DH,n|x))) ------> I or MI R R2 ::= <--- ECR(DH,n|y), MAC(x, (ECR(DH,n|y))) I R <--- Data, MAC(EX(x,y), Data) ------> Note be end of exchange, parties can ONLY be R and I.

22. 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 it starts receiving datagrams

23. 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

24. 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

25. 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

26. Robert Moskowitz (ICSAlabs/VzB) Using HIP DEX for MACsec • HIP runs directly over MAC • Use 802.1X ethertype? • How to handle fragmentation • ICMP error messages • Remove IP header and run directly over MAC • No other considerations

27. 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

28. Robert Moskowitz (ICSAlabs/VzB) Developing HIP DEX • Research available 'compress' functions • Review puzzle to use CMAC • Use RFC 4615 • Review KDF expand using CMAC • Use RFC 4615 and NIST 800-108 • Publish HIP DEX Internet Draft • By July 5 2010

29. Robert Moskowitz (ICSAlabs/VzB) Questions?