Date post: | 05-Jan-2016 |
Category: |
Documents |
Upload: | melvyn-jones |
View: | 214 times |
Download: | 2 times |
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 1
doc.: IEEE 802.15-10-0412-04-wng0
Submission
Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: Key Negotiation using DIET HIPDate Submitted: 7 July, 2010Source: Robert Moskowitz (ICSA labs, an Independent Division of Verizon Business)Address: Detroit, MI USAVoice:[…], 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.
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 2
doc.: IEEE 802.15-10-0412-04-wng0
Submission
Key Negotiation using DIET HIP
Robert Moskowitz (ICSA labs, an Independent Division of Verizon Business)
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 3
doc.: IEEE 802.15-10-0412-04-wng0
Submission
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 802.15 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)
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 4
doc.: IEEE 802.15-10-0412-04-wng0
Submission
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
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 5
doc.: IEEE 802.15-10-0412-04-wng0
Submission
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
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 6
doc.: IEEE 802.15-10-0412-04-wng0
Submission
What is HIP?
– The SA is used to key ESP (RFC 4304) in transport mode
• Or could key IEEE 802.15.4 MAC security
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 7
doc.: IEEE 802.15-10-0412-04-wng0
Submission
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
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 8
doc.: IEEE 802.15-10-0412-04-wng0
Submission
Why Consider HIP
• HIP is Minimalistic by design– Not chatty (EAP and TLS)– No extended exchange (IKEv2)– Little configuration as little to choose
from
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 9
doc.: IEEE 802.15-10-0412-04-wng0
Submission
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
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 10
doc.: IEEE 802.15-10-0412-04-wng0
Submission
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
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 11
doc.: IEEE 802.15-10-0412-04-wng0
Submission
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
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 12
doc.: IEEE 802.15-10-0412-04-wng0
Submission
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
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 13
doc.: IEEE 802.15-10-0412-04-wng0
Submission
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
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 14
doc.: IEEE 802.15-10-0412-04-wng0
Submission
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
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 15
doc.: IEEE 802.15-10-0412-04-wng0
Submission
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
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 16
doc.: IEEE 802.15-10-0412-04-wng0
Submission
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?
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 17
doc.: IEEE 802.15-10-0412-04-wng0
Submission
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
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 18
doc.: IEEE 802.15-10-0412-04-wng0
Submission
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)
• This is mitigated if only used to encrypt a uniformly random session key
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 19
doc.: IEEE 802.15-10-0412-04-wng0
Submission
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
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 20
doc.: IEEE 802.15-10-0412-04-wng0
Submission
Putting HIP on a DietBasic 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
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 21
doc.: IEEE 802.15-10-0412-04-wng0
Submission
Putting HIP on a DietProof 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
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 22
doc.: IEEE 802.15-10-0412-04-wng0
Submission
Putting HIP on a DietWhat security assertions lost?
• Use of static DH means loss of Perfect Forward Secrecy (PFS)
– 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
Robert Moskowitz (ICSAlabs/VzB)Slide 23
doc.: IEEE 802.15-10-0412-04-wng0
Submission
Putting HIP on a DietWhat 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
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 24
doc.: IEEE 802.15-10-0412-04-wng0
Submission
Putting HIP on a DietOther 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.
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 25
doc.: IEEE 802.15-10-0412-04-wng0
Submission
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
• Proves private key ownership• Following is DEX protocol
– The network is the attacker model used• Assume both malicious Responder
and Initiator
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 26
doc.: IEEE 802.15-10-0412-04-wng0
Submission
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
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 27
doc.: IEEE 802.15-10-0412-04-wng0
Submission
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
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 28
doc.: IEEE 802.15-10-0412-04-wng0
Submission
HIP Diet Exchange (DEX)
• The HIP DEX, rather than a BEX, exchange is identified by a DEX HIT
– I & R HITs included in exchange headersI 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.
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 29
doc.: IEEE 802.15-10-0412-04-wng0
Submission
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
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 30
doc.: IEEE 802.15-10-0412-04-wng0
Submission
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
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 31
doc.: IEEE 802.15-10-0412-04-wng0
Submission
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
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 32
doc.: IEEE 802.15-10-0412-04-wng0
Submission
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 SAE
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 33
doc.: IEEE 802.15-10-0412-04-wng0
Submission
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 802.11 Annex H
• RFC 4615 starting with a REAL random seed
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 34
doc.: IEEE 802.15-10-0412-04-wng0
Submission
Using HIP DEX for MACsec
• Use 6lowpan for HIP directly over MAC– Sec 5 for fragmentation
• Develop broadcast/multicast key distribution
– Use 802.11 Group key model• ICMP error messages
– Remove IP header and run directly over 6lowpan
• No other considerations• Work this out in 6lowpan
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 35
doc.: IEEE 802.15-10-0412-04-wng0
Submission
HIP DEX Packet sizesFragmentation 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.
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 36
doc.: IEEE 802.15-10-0412-04-wng0
Submission
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
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 37
doc.: IEEE 802.15-10-0412-04-wng0
Submission
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
June 2010
Robert Moskowitz (ICSAlabs/VzB)Slide 38
doc.: IEEE 802.15-10-0412-04-wng0
Submission
Questions?