The HIP Diet Exchange HIP DEX

1. Robert Moskowitz ICSA labs an Independent Division of Verizon Business July 26, 2010 rgm@labs.htt-consult.com The HIP Diet ExchangeHIP DEX

2. Purpose of this presentation • Present work on a new HIP Exchange specifically architected for resource limited devices by • Explain why HIP BEX is not suited for these devices • Explain the new HIP Diet Exchange (HIP DEX) • And using it to key 802.15 MACsec • Possible directions for HIP • Next steps

3. Why not HIP BEX? • Characteristics of 802.15.4 (Low Rate Wireless Personal Area Networks) • Over-the-air data rates of 250 kb/s, 100kb/s, 40 kb/s, and 20 kb/s • Low power consumption • Small Processors with minimum memory • Typically battery operated

4. Putting HIP on a DietBasic premise • The HIP Diet Exchange – HIP DEX • Use static ECDH as Host Identities • With ECDH derived key only used for session key protection • Master Key in 802.11 terminology • Randomly generated a key and encrypted with DH derived key • CMAC function now defined for Diffie-Hellman key as the the Master Key • Key derivation from random key can use CMAC • We do not need a hash function! • We can 'manage' without Digital Signatures

5. HIP Diet Exchange (DEX) • Parties are • I ::= Initiator • R ::= Responder • MR ::= Malicious Responder • MI ::= Malicious Initiator • Functions are • ECR ::= AES encrypt • MAC ::= CMAC • | ::= concatenation • EX ::= Key expansion

6. HIP Diet Exchange (DEX) • Values are • PK ::= Public key of • e.g. Pki is Public key of I • DHk ::= Derived Diffie-Hellman key compressed via CMAC with nonce as key • DHlist ::= List of ECDH key sizes supported • n ::= nonce • Pn ::= Puzzle based on and containing nonce n • Sn ::= Puzzle solution based on nonce n • x,y ::= random secrets

7. HIP Diet Exchange (DEX) • The HIP DEX, rather than a BEX, exchange is identified by a DEX HIT • I & R HITs included in exchange headers I or MI R or MR I1 ::= (DHlist) ------> R1 ::= <--- Pn, Pkr, DHlist I2 ::= Sn, PKi, ECR(DHk,x|n), MAC(DHk,(Sn, PKi, ECR(DHk,x|n))) ------> I or MI R R2 ::= <--- DHlist, ECR(DHk,y|n), MAC(DHk, (DHlist, ECR(DHk,y|n))) I R <--- Data, MAC(EX(x,y), Data) ------> Note be end of exchange, parties can ONLY be R and I.

8. Putting HIP on a DietSummary of Crypto Components • A 'Dietetic' HIP exchange CAN be achieved with • AES-CBC (and CMAC) • AES-CCM used by ESP or MACsec • Static ECDH • I2 and R2 MACs prove private key ownership • Can be installed by manufacturer • ECDH key derivation typically only occurs for initial join

9. 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 • Alternative to 802.15 immediate ACK • Which is not effective on multihop or off PAN • 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

10. HIP Diet Exchange (DEX)Adding Password Authentication • Password Augmented Authentication • Provides bootstrap mechanism to add a node to a controller • Supports emergency adHoc access • EMT access to a Pacemaker • Utility field technician to a substation controller • Controller implicitly invites password Auth • R1 ALWAYS contains a challenge • The Puzzle values • Initiator MACs challenge with password and encrypts that in the DH derived key

11. 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 • Initiator cannot tell if R1 came from Responder or attacker unless PKr from another source • Need zero knowledge alternative • As in IEEE 802.11s SAE • And draft-harkins-ipsecme-spsk-auth

12. Using HIP DEX for MACsec • Use 6lowpan for HIP directly over MAC layer • Sec 5 for fragmentation • Develop pair-wise and broadcast/multicast key distribution • HIP DEX has implicit concept of Master and Pair-wise keys • Use 802.11 Group key model • Or 802.1AE? • ICMP error messages • Remove IP header and run directly over 6lowpan

13. HIP DEX exchanges • DEX provides Master and Pair-wise Keys • On initial joining of PAN and whenever new MK needed (e.g. lost of state) • Accelerated Group key setup within exchange • Only if Responder is owner of key

14. HIP DEX exchanges • Pair-wise Key Updates • Via HIP UPDATE exchange • Frequency determined by local policy • Lost state or key exhausted • Only AES-CBC and CMAC functions needed • Group Key • Via HIP UPDATE exchange • Sent by key owner • Frequency determined by local policy • Lost state, membership change, key exhausted • Only AES-CBC and CMAC functions needed

15. The Evolution of HIP • First there was the Base Exchange • This already implied there would something not 'Base' • Well constructed for P2P applications • Then HIP for RFID • VERY lightweight exchange for Active 'tags' • Now HIP DEX • Designed for constrained sensors

16. The Evolution of HIP • Host Identity Namespace and HITs will be available for any Object on the Internet • We need attention to implementation commonality for systems that will support 2 or all three exchanges • We need to think out how best to leverage this development

17. Next Steps • HIP DEX will be worked on in • IETF and IEEE 802.15 HIP Interest Group • Refine processes • HIP DEX • MACsec key hierarchies management • Present progress at IEEE 802.15 Interim in September • November IEEE 802 and IETF same week • I will be attending IEEE 802

18. Questions?