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: 22 June, 2010
Source: Robert Moskowitz (ICSAlabs, an Independent Division of Verizon Business Systems)‏
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 (ICSAlabs, an Independent Division of Verizon Business Systems)‏
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

3. Host Identities are typically cryptographic RSA, DSA, ECC public keys
September 2009
doc.: IEEE
June 2010
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
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

4. In HIP the End Point Identifier is Host Identity Tag (HIT) in IPv6
September 2009
doc.: IEEE
June 2010
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
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

5. In some instances, the Internetwork layer could be discarded
September 2009
doc.: IEEE
June 2010
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
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

6. SIGMA Compliant authenticated Diffie- Hellman key exchange
September 2009
doc.: IEEE
June 2010
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,
Going through revisions, -bis Internet Drafts available
SIGMA Compliant authenticated Diffie- Hellman key exchange
Current Base Exchange (BEX)
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

7. What is SIGMA Compliant
September 2009
doc.: IEEE
June 2010
What is SIGMA Compliant
SIGning and MACing
Defined by Hugo Krawczyk
Technion University and IBM
Origin and theory:
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
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

8. 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, 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
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.

9. HIP Basics Cryptographic components 'Public' Key Hashing HMAC
September 2009
doc.: IEEE
June 2010
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
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

10. 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 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?
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

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

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

13. Putting HIP on a Diet If Hashing is removed HMAC is removed
September 2009
doc.: IEEE
June 2010
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
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

14. Putting HIP on a Diet With PK Encryption
September 2009
doc.: IEEE
June 2010
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
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

15. Putting HIP on a Diet Use CMAC in puzzle creation and solution
September 2009
doc.: IEEE
June 2010
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
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

16. Putting HIP on a Diet 'Key' sacrifices in HIP “Diet'
September 2009
doc.: IEEE
June 2010
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
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

17. Putting HIP on a Diet A 'Dietetic' HIP exchange COULD be achieved with
September 2009
doc.: IEEE
June 2010
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
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

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

19. 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
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
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

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

21. 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 no I2 within time t
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

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

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

24. 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
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

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

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

27. Developing HIP DEX Research available 'compress' functions
September 2009
doc.: IEEE
June 2010
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
Work with draft-mcgrew-fundamental- ecc author on fECC encrypt function
Publish HIP DEX Internet Draft
By end of June
Robert Moskowitz (ICSAlabs/VzB)
Michael Bahr (Siemens AG) et al.

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