1. September 2009
doc.: IEEE
June 2010
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)‏
Submission Title: Key Negotiation using DIET HIP
Date Submitted: 12 July, 2010
Source: Robert Moskowitz (ICSA labs, an Independent Division of Verizon Business)‏
Address: Detroit, MI USA
Voice:[…], FAX: […], 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 P 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 P
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

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

3. Purpose of this presentation
September 2009
doc.: IEEE
June 2010
Purpose of this presentation
Present work on a new HIP Exchange specifically architected for resource limited devices by
Explaining what HIP is and does and why should consider using it
Review cryptographic components used in HIP (and many other Key Management Systems (KMS)
Work through what might be a minimal cryptographic for a KMS
Explain the new HIP Diet Exchange (HIP DEX)
A call for action
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

4. September 2009
doc.: IEEE
June 2010
What is HIP?
RFC 4423 introduces the Host Identity Namespace. When the Host Identity (HI) is a Cryptographic key (RSA, DSA, or ECC)
128 bit Host Identity Tag (HIT) is derived from the HI (hashed) and functions as an IPv6 address (/28 prefix) for applications
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

5. September 2009
doc.: IEEE
June 2010
What is HIP?
A 4 packet Peer-to-Peer Host Identity Protocol Base EXchange (HIP BEX) establishes a security association (SA, similar to IKE), indexed by the HITs, but independent of the IP address
HIP's notion of an End Point Identifier (the HITs) disassociates the current tight binding between the Internetwork and Transport layers
Can even function directly on layer 2
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

6. What is HIP? The SA is used to key ESP (RFC 4304) in transport mode
September 2009
doc.: IEEE
June 2010
What is HIP?
The SA is used to key ESP (RFC 4304) in transport mode
Or could key IEEE MAC security
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

7. September 2009
doc.: IEEE
June 2010
Why Consider HIP
Although HIP is an IP layer KMS, it is independent of IP
The same KMS can function at the MAC layer
HIP is constructed with long-used and well understood crypto components
It is 'easy' to analyze
HIP does not need backend validation systems
It works well with ACLs
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

8. Why Consider HIP HIP is Minimalistic by design
September 2009
doc.: IEEE
June 2010
Why Consider HIP
HIP is Minimalistic by design
Not chatty (EAP and TLS)
No extended exchange (IKEv2)
Little configuration as little to choose from
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

9. September 2009
doc.: IEEE
June 2010
More on HIP
Host Identity validation is not built into HIP. It can be handled
Anonymously – you get what you pay for
Man-in-the-middle attacks if both peers are anonymous
No MITM attack if one peer can validate HIT of the other
ACLs – management up to implementation
DNS – RFC 5205
No reverse lookup, but FQDN in BEX
X.509 certificates – Internet Draft draft- ietf-hip-cert-03.txt
If one peer has assertion of other's identity (via ACL, DNS, X.509, DHT), it can it can abort association if HIT and HI do not match information on peer.
For example a field technician can enter HIT of sensor into his notebook's ACL and be assured that there is no Man-in-the-Middle during his connection to the sensor.
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

10. What is the role of HITs? In HIP the End Point Identifier is
September 2009
doc.: IEEE
June 2010
What is the role of HITs?
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
Applications tend to be ignorant of underlying IP addresses, if any
Secure mobility WORKs (RFC 5206)
IPv4 applications on IPv6 networks
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

11. September 2009
doc.: IEEE
June 2010
More on HIP
HIP is architecturally ideally suited to be a Key Management System (KMS) for both IP and MAC layers
Current status
RFC 4423,
Three implementations
Boeing, Ericsson, HIPL
Going through revisions, -bis Internet Drafts available
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

12. HIP BEX is SIGMA Compliant
September 2009
doc.: IEEE
June 2010
HIP BEX is SIGMA Compliant
Authenticate Diffie-Hellman key exchange with SIGning and MACing
Also used by IKEv2
Defined by Hugo Krawczyk
Technion University and IBM
Origin and theory:
Diffie-Hellman based
3 packets typical
Ephemeral Diffie-Hellman 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.

13. The Basics of the HIP exchange
September 2009
doc.: IEEE
June 2010
The Basics of the HIP exchange
DH-list ::= List of Diffie-Hellman formats supported
Puzzle ::= computational challenge to limit flooding attacks
Solution ::= solution to puzzle
DH ::= Diffie-Hellman public key
HI ::= Host Identity Public key
Sig ::= Digital Signature using Host Identity
Mac ::= Message Authentication using Diffie-Hellman derived key
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

14. The Basics of the HIP exchange
September 2009
doc.: IEEE
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, DH-list, HI, sig
check sig remain stateless
solve puzzle
I2: solution, DH, {HI}, mac, sig >
compute DH key check puzzle
check mac & sig
< R2: mac, sig
check mac & sig compute DH
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.

15. HIP Cryptographic Components
September 2009
doc.: IEEE
June 2010
HIP 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 for both HIP exchange and for ESP from IPsec
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

16. A minimal HIP implementation
September 2009
doc.: IEEE
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 lifetime could be extended 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.

17. September 2009
doc.: IEEE
June 2010
General KMS 'review'
Step back and review the components of a Key Management System
Exclude Password based approaches from consideration
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 ephemeral Diffie-Hellman key exchange
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

18. September 2009
doc.: IEEE
June 2010
Crypto 'review'
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)
MACs (e.g. CMAC) CANNOT be used directly to expand the Diffie-Hellman derived key for session keys
This is mitigated if only used to encrypt a uniformly random session key
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

19. Crypto 'review' If Hashing is removed HMAC is removed
September 2009
doc.: IEEE
June 2010
Crypto 'review'
If Hashing is removed
HMAC is removed
CMAC is a partial replacement
Puzzle construction and Key Expansion
Diffie-Hellman is limited
Common practice is to use with HMAC
But can encrypt a session key
Public Key Signatures are lost
Requires Hashing to avoid forgeries
CMAC cannot protect against forgeries
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

20. Putting HIP on a Diet Basic premise
September 2009
doc.: IEEE
June 2010
Putting HIP on a Diet Basic premise
Use static ECDH as Host Identities
With ECDH derived key only used for session key protection
Randomly generated a key and encrypted with DH derived key
This replaces the Diffie-Hellman key as the session key which required HMAC
Key derivation from random key can use CMAC
We do not need a hash function!
We can 'manage' without Digital Signatures
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

21. Putting HIP on a Diet Proof of Identity
September 2009
doc.: IEEE
June 2010
Putting HIP on a Diet Proof of Identity
Nonce encrypted with session key 1st proof
Session key used in MAC of HIP payload 2nd proof
Thus sender of packet must have private key matching HI
The WHO of the HI is outside of HIP
Various methods used
ACL, DNS, X.509
Anonymous with password authentication
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

22. Putting HIP on a Diet What security assertions lost?
September 2009
doc.: IEEE
June 2010
Putting HIP on a Diet What security assertions lost?
Use of static DH means loss of Perfect Forward Secrecy (PFS)
Static DH (NIST SP A sec ) 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
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

23. Putting HIP on a Diet What security assertions lost?
September 2009
doc.: IEEE
June 2010
Putting HIP on a Diet What security assertions lost?
Digital signatures
ECDSA requires a hash
Collision resistance required to avoid existential forgeries.
This sacrifice means deviating from SIGMA
But could follow closely
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

24. Putting HIP on a Diet Other uses of hashing in HIP BEX
September 2009
doc.: IEEE
June 2010
Putting HIP on a Diet Other uses of hashing in HIP BEX
Use CMAC in puzzle creation and solution
Find a 'simple' compress function for HIT creation
160, 224, or 256 bits down to 96 with collision avoidance.
Possibly Matyas–Meyer–Oseas hash?
Since ECDH public key is exponentiation with a random secret, left truncation can be used for HIT construction.
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

25. Putting HIP on a Diet Summary of Crypto Components
September 2009
doc.: IEEE
June 2010
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
Proves private key ownership
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.

26. HIP Diet Exchange (DEX)
September 2009
doc.: IEEE
June 2010
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
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

27. HIP Diet Exchange (DEX)
September 2009
doc.: IEEE
June 2010
HIP Diet Exchange (DEX)
Values are
PK ::= Public key of
e.g. Pki is Public key of I
DHk ::= 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
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

28. HIP Diet Exchange (DEX)
September 2009
doc.: IEEE
June 2010
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 ::= () >
R1 ::= < Pn, PKr
I2 ::= Pn, Sn, PKi, ECR(DHk,x|n), MAC(x,(Pn, Sn, PKi, ECR(DHk,x|n))) >
I or MI R
R2 ::= < ECR(DHk,y|n), MAC(x, (ECR(DHk,y|n)))
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.

29. HIP Diet Exchange (DEX) Dealing with a lossful network
September 2009
doc.: IEEE
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 it starts receiving datagrams
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

30. HIP Diet Exchange (DEX) Dealing with a lossful network
September 2009
doc.: IEEE
June 2010
HIP Diet Exchange (DEX) Dealing with a lossful network
Plus error handling events.
E.G. I ignores R1s unless it 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.

31. HIP Diet Exchange (DEX) Adding Password Authentication
September 2009
doc.: IEEE
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.

32. HIP Diet Exchange (DEX) Adding Password Authentication
September 2009
doc.: IEEE
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 s SAE
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

33. The Importance of Randomness
September 2009
doc.: IEEE
June 2010
The Importance of Randomness
HIP DEX is HIGHLY dependent on good Random numbers
No Hash function typically used in pseudo random number generators
Many underlying assumptions on randomness
An analog approach is in Annex H
RFC 4615 starting with a REAL random seed
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

34. Using HIP DEX for MACsec
September 2009
doc.: IEEE
June 2010
Using HIP DEX for MACsec
Use 6lowpan for HIP directly over MAC
Sec 5 for fragmentation
Develop broadcast/multicast key distribution
Use Group key model
ICMP error messages
Remove IP header and run directly over 6lowpan
No other considerations
Work this out in 6lowpan
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

35. HIP DEX Packet sizes Fragmentation Support Needed
September 2009
doc.: IEEE
June 2010
HIP DEX Packet sizes Fragmentation Support Needed
Minimum packet sizes
Based on 160 bit ECDH keys
I1 – 40 bytes, R1 = 120 bytes, I2 – 180 bytes, R2 – 108 bytes
From core list by Henning Schulzrinne
A basic law of protocol design: all messages start out small, but they never get smaller. Corollary: even if you believe that you need only small messages, somebody else will think of a good application for larger ones - and won't be discouraged by the fact that you tell him that the protocol wasn't designed for that.
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

36. Conclusions HIP DEX significantly reduced requirements over HIP BEX
September 2009
doc.: IEEE
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.

37. Developing HIP DEX Publish HIP DEX Internet Draft
September 2009
doc.: IEEE
June 2010
Developing HIP DEX
Publish HIP DEX Internet Draft
draft-moskowitz-hip-rg-dex-01.txt
Present at IETF in Maastricht
To HIP and 6lowpan/core groups
Work with potential implementers/testers
Develop Interest Group for Hawaii
Or include in existing work in various Task Groups
Or liaison with IETF
6lowpan, but focused on IP, not MAC security
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

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