June 2010
doc.: IEEE 802.15-10-0412-01-wng0
Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: Key Negotiation using DIET HIP
Date Submitted: 28 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.
Submission
Slide 1
Robert Moskowitz (ICSAlabs/VzB)
June 2010
doc.: IEEE 802.15-10-0412-01-wng0
Key Negotiation using DIET HIP
Robert Moskowitz (ICSA labs, an Independent Division
of Verizon Business)
Submission
Slide 2
Robert Moskowitz (ICSAlabs/VzB)
June 2010
doc.: IEEE 802.15-10-0412-01-wng0
Purpose of this presentation
•
Present work on a new HIP Exchange
specifically architected for resource
limited devices by
–
–
–
–
Submission
Explaining what HIP is and does
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)
Slide 3
Robert Moskowitz (ICSAlabs/VzB)
doc.: IEEE 802.15-10-0412-01-wng0
What is HIP?
•
RFC 4423 introduces the Host Identity
Namespace. When the Host Identity
(HI) is a Cryptographic key (RSA,
DSA, or ECC)
–
Submission
128 bit Host Identity Tag (HIT) is
derived from the HI (hashed) and
functions as an IPv6 address (/28
prefix) for applications
doc.: IEEE 802.15-10-0412-01-wng0
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
•
Submission
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
doc.: IEEE 802.15-10-0412-01-wng0
What is HIP?
–
The SA is used to key ESP (RFC
4304) in transport mode
•
Submission
Or could key IEEE 802.15.4 MAC
security
doc.: IEEE 802.15-10-0412-01-wng0
More on HIP
•
Host Identity validation is not built into HIP.
It can be handled
–
Anonymously – you get what you pay for
•
•
–
–
–
Submission
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 draftietf-hip-cert-03.txt
June 2010
doc.: IEEE 802.15-10-0412-01-wng0
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
•
•
Submission
Secure mobility WORKs (RFC
5206)
IPv4 applications on IPv6 networks
Slide 8
Robert Moskowitz (ICSAlabs/VzB)
June 2010
doc.: IEEE 802.15-10-0412-01-wng0
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, 5201-5206
– Three implementations
•
Boeing, Ericsson, HIPL
– Going through revisions, -bis Internet
Drafts available
Submission
Slide 9
Robert Moskowitz (ICSAlabs/VzB)
June 2010
doc.: IEEE 802.15-10-0412-01-wng0
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:
• http://webee.technion.ac.il/~hugo/sigma.ps
– 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
Submission
Slide 10
Robert Moskowitz (ICSAlabs/VzB)
doc.: IEEE 802.15-10-0412-01-wng0
The Basics of the HIP exchange
•
•
•
•
•
•
Submission
DH list ::= List of Diffie-Hellman formats
supported
Puzzle ::= computational challenge to limit
flooding attacks
Solution ::= solution to puzzle
HI ::= Host Identity Public key
Sig ::= Digital Signature using Host Identity
Mac ::= Message Authentication using
Diffie-Hellman derived key
June 2010
doc.: IEEE 802.15-10-0412-01-wng0
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 list, HI, sig
check sig
remain stateless
solve puzzle
I2: solution, D-H, {HI}, mac, sig -------------------------->
compute D-H key
check puzzle
check mac & sig
<--------------------------
R2: mac, sig
check mac & sig
Submission
compute D-H
Slide 12
Robert Moskowitz (ICSAlabs/VzB)
June 2010
doc.: IEEE 802.15-10-0412-01-wng0
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 through ESP
from IPsec
Submission
Slide 13
Robert Moskowitz (ICSAlabs/VzB)
June 2010
doc.: IEEE 802.15-10-0412-01-wng0
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?
Submission
Slide 14
Robert Moskowitz (ICSAlabs/VzB)
June 2010
doc.: IEEE 802.15-10-0412-01-wng0
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
–
–
Submission
TLS uses Key encryption by the public
key
IPsec uses ephemeral Diffie-Hellman
key exchange
Slide 15
Robert Moskowitz (ICSAlabs/VzB)
June 2010
doc.: IEEE 802.15-10-0412-01-wng0
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)
• But if only used to encrypt a uniformly random
session key, this is mitigated
Submission
Slide 16
Robert Moskowitz (ICSAlabs/VzB)
June 2010
doc.: IEEE 802.15-10-0412-01-wng0
Crypto 'review'
•
If Hashing is removed
–
HMAC is removed
•
CMAC is be a partial replacement
–
–
Diffie-Hellman is limited
•
•
–
Common practice is to use with HMAC
But can encrypt a session key
Public Key Signatures are lost
•
•
Submission
Puzzle construction and Key Expansion
Requires Hashing to avoid forgeries
CMAC cannot protect against forgeries
Slide 17
Robert Moskowitz (ICSAlabs/VzB)
June 2010
doc.: IEEE 802.15-10-0412-01-wng0
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 for
transmission
•
•
•
•
Submission
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
Slide 18
Robert Moskowitz (ICSAlabs/VzB)
doc.: IEEE 802.15-10-0412-01-wng0
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
•
•
Submission
ACL, DNS, X.509
Anonymous with password
authentication
doc.: IEEE 802.15-10-0412-01-wng0
Putting HIP on a Diet
What security assertions lost?
•
Use of static DH means loss of
Perfect Forward Secrecy (PFS)
–
–
–
Submission
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
June 2010
doc.: IEEE 802.15-10-0412-01-wng0
Putting HIP on a Diet
What security assertions lost?
•
Digital signatures
–
ECDSA requires a hash
•
•
This sacrifice means deviating from
SIGMA
–
Submission
Collision resistance required to avoid
existential forgeries.
But could follow closely
Slide 21
Robert Moskowitz (ICSAlabs/VzB)
June 2010
doc.: IEEE 802.15-10-0412-01-wng0
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.
•
–
Submission
Possibly Matyas–Meyer–Oseas hash?
Since ECDH public key is
exponentiation with a random secret,
right truncation can be used for HIT
construction.
Slide 22
Robert Moskowitz (ICSAlabs/VzB)
June 2010
doc.: IEEE 802.15-10-0412-01-wng0
Putting HIP on a Diet
Summary of Crypto Components
• A 'Dietetic' HIP exchange CAN be
achieved with
–
–
AES-CCM (and CMAC)
Static ECDH
•
Proves private key ownership
• Following is DEX protocol
–
The network is the attacker model used
•
Submission
Assume both malicious Responder
and Initiator
Slide 23
Robert Moskowitz (ICSAlabs/VzB)
June 2010
doc.: IEEE 802.15-10-0412-01-wng0
HIP Diet Exchange (DEX)
•
Parties are
–
–
–
–
•
I ::= Initiator
R ::= Responder
MR ::= Malicious Responder
MI ::= Malicious Initiator
Functions are
–
–
–
–
Submission
ECR ::= AES encrypt
MAC ::= CMAC
| ::= concatenation
EX ::= Key expansion extraction
Slide 24
Robert Moskowitz (ICSAlabs/VzB)
June 2010
doc.: IEEE 802.15-10-0412-01-wng0
HIP Diet Exchange (DEX)
•
Values are
–
–
–
–
–
–
Submission
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
Slide 25
Robert Moskowitz (ICSAlabs/VzB)
June 2010
doc.: IEEE 802.15-10-0412-01-wng0
HIP Diet Exchange (DEX)
• The HIP DEX exchange is identified by
a DEX HIT
I or MI
R or MR
I1 ::=
()
R1 ::=
I2 ::=
<---
------>
Pn, PKr
Pn, Sn, PKi, ECR(DH,x|n), MAC(x,(Pn, Sn, PKi, ECR(DH,x|n))) ------>
I or MI
R2 ::=
R
<---
ECR(DH,y|n), MAC(x, (ECR(DH,y|n)))
I
R
<--- Data, MAC(EX(x,y), Data) ------>
Note be end of exchange, parties can ONLY be R and I.
Submission
Slide 26
Robert Moskowitz (ICSAlabs/VzB)
June 2010
doc.: IEEE 802.15-10-0412-01-wng0
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
–
–
–
–
Submission
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
Slide 27
Robert Moskowitz (ICSAlabs/VzB)
June 2010
doc.: IEEE 802.15-10-0412-01-wng0
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
•
•
Submission
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
Slide 28
Robert Moskowitz (ICSAlabs/VzB)
June 2010
doc.: IEEE 802.15-10-0412-01-wng0
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
Submission
Slide 29
Robert Moskowitz (ICSAlabs/VzB)
June 2010
doc.: IEEE 802.15-10-0412-01-wng0
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
Submission
Slide 30
Robert Moskowitz (ICSAlabs/VzB)
June 2010
doc.: IEEE 802.15-10-0412-01-wng0
Using HIP DEX for MACsec
•
HIP runs directly over MAC
–
–
•
ICMP error messages
–
•
Use 802.1X ethertype?
How to handle fragmentation
Remove IP header and run directly
over MAC
No other considerations
Submission
Slide 31
Robert Moskowitz (ICSAlabs/VzB)
June 2010
doc.: IEEE 802.15-10-0412-01-wng0
Conclusions
•
•
HIP DEX significantly reduced
requirements over HIP BEX
Uses established cryptographic
functions
–
•
•
Full state machine for all event
conditions
KMS for both IP and MAC layers
–
•
Submission
Easily analysed
Further coding advantage
Performs over lossful networks
Slide 32
Robert Moskowitz (ICSAlabs/VzB)
June 2010
doc.: IEEE 802.15-10-0412-01-wng0
Developing HIP DEX

Publish HIP DEX Internet Draft
– By July 5 2010
• Present at IETF in Maastricht
– Work with potential implementers/testers
Submission
Slide 33
Robert Moskowitz (ICSAlabs/VzB)
June 2010
doc.: IEEE 802.15-10-0412-01-wng0
Questions?
Submission
Slide 34
Robert Moskowitz (ICSAlabs/VzB)