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

2. 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. 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. 4 Putting HIP on a Diet Basic 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. 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. 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. 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 Note be end of exchange, parties can ONLY be R and I.

8. 8 Putting HIP on a Diet Summary 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 18 Questions?