Subject: [core] Security design

From: Cullen Jennings <[email-masked]>
Date: Fri, 4 Jun 2010 11:47:47 -0600

I've asked several people what they thought we should do with security and received a wide variety of answers. I'm going to try and propose something  here that I think *might* be acceptable to most people. I'm not arguing for or against this, I'm just trying to propose a straw man that helps us get to a decision sooner. 

The proposals is that COAP define three levels of security which are:

0) COAP baseline. No cryptographic security. Runs over UDP without DTLS. 

1) COAP Shared Key. The requires implementation (but not use) of DTLS with symmetric keys but does not require any asymmetric cryptography. 

2) COAP Certificates. This requires implementation of the stuff in 1 plus DTLS with some defined asymmetric key cryptography and certificates. 

A given produce could choose to be compliant with one of these three levels. COAP would not forbid extensions that either allowed it to cary some sort of signed objects so it could get object security later if some application wanted that. COAP would explicitly allow extensions that bound it to a different session mode security than DTLS so, for example, if someone or some group wanted to make a binding to IPsec with or without IKEv2, that would be fine. 

For both "COAP Shared Key" and "COAP Certificate", we would need to mandate one or more mandatory to implement DTLS profiles. I would want to get input and exact text from the DTLS/TLS authors and WG but I'm imagining something like:

COAP "Shared Key" requires implementation of DTLS with TLS_PSK_WITH_AES_128_CBC_SHA

Probably the biggest issue for the certificate mode is the "never too old to not do again" ECC vs RSA debate. I'd really like to separate that out as a separate issue and get agreement around the big picture before we have that particular debate. 

COAP "Certificates" requires implementation of DTLS with X.509 certificates and TLS_XXX_WITH_AES_128_CBC_SHA where we decide on either RSA or ECDH_ECDSA as the value of XXX. 

I forgot to ask people about what hash they liked so I randomly used SHA instead of SHA256 but it would be nice to get feedback from the WG on which hash should be mandatory to implement. I would expect some significant push back from the Security area if we selected SHA1 as the only mandatory to implement hash for a brand new protocol. 

Could something like this work? Thoughts on what would need to change? Could people live with the idea of having three levels sort of like WiFi security? ALternative proposal? Fine tuning this proposal? 

Thanks, Cullen

---

From: Tobias Heer <[email-masked]>
Date: Fri, 18 Jun 2010 09:26:48 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Shoichi Sakane
> Sent: Friday 18 June 2010 7:56
> To: [email-masked]
> Subject: Re: [core] Security design
> 
> On 06/17/10 14:46, Carsten Bormann wrote:
>> Besides TLS, interesting security-related WGs to watch might include HIP.
> 
> +1
> 
> HIP has some advantages from other choices.
> 
> TLS and DTLS is little different protocol, maybe 50% is same.
> We need to have different stacks in a single node if we want
> to use both TCP and UDP.
> Further more, a node has to maintain different secure sessions.
> The node has to start different negotiation with a single peer
> for each session which is denoted by an IP address and a pair
> of port numbers.
> Thoretically, it could bind to an IP address and differnt port
> numbers, but, it will break the interoperability.
> 
> We can get away from it when we select IPsec.
> But, the selection of the key management protocol is the big issue.
> Several existing protocols, like IKE, negosiate keys in the out-band.
> So, a node has to maintain another channel for exchanging keys.
> It would be a burden for a sensor node.
> HIP does make it in the in-band.
> 
> Currently, I think HIP is a good candidate though how we operate
> the asymmetric cipher processing in the sensor node is another big
> issue.  We might be able to refer it to a third machine.
> 

FYI. Some people in the HIP context are currently working on reducing the cost of HIP to make it applicable to resource constrained devices.
The main aspects of this work are a) reduce the computation complexity by reducing the amount of PK crypto, b) reducing the code size by reconsidering which ciphers and hashes to use, c) considering very lossy channels to make the handshake robust.

The goal of this work is to make HIP "lighter" while still maintaining the way it works.

Robert Moskowitz is the main driver of this work.

BR, 

Tobias

> Shoichi Sakane
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
> 
> The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

-- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group 
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 21 Jun 2010 14:17:38 -0400

I have NOT been following CORE.  Tobias Heer recently focused my 
attention this way by forwarding his post here from yesterday.

First a few words about HIP, then some crypto observations, then where 
HIP is going.

HIP in brief:

HIP is a KMS, like IKE and IEEE 802.11i's 4-Way Handshake.  It 
establishes a Security Association between two parties.  This Security 
Association (SA) provides keying information for a per-datagram 
protection envelope.  Currently HIP Base EXchange (BEX, RFC5201) 
provides keys for ESP in a variant of ESP transport mode (RFC 5202).  
HIP is a VERY lightweight 4 packet KMS; BEX follows the SigMa model like 
IKEv2.

Crypto notes:

One of the challenges we have in our work is that there is need for 
datagram protection at different layers.  And each layer has its one 
risks and vulnerablities.  Sometimes one protection at one layer 
mitigates risks at another, sometimes not.  But our current model is a 
KMS per layer.  Thus we have TLS, IKE, and the 4-Way Handshake.  Becuase 
HIP is actually independent of IP, its can be used as a KMS for layers 
besides layer 3.  I have been proposing HIP for direct use on layer 2 
keying.

15 years ago there was a very limited understanding of KMS, and the 
attack models were simple.  Now the attack models are rich, and the 
solutions are fully vetted with every piece of crypto we can put in them 
because code and processing is no longer a challenge, right?  Over the 
past few months I have been pulling off the crypto layers asking a lot 
of WHY questions.  I have created a taxonomy of sorts of what we have 
built and why it is there.  So first I will ask you do you need 
transactional digital signatures?  If so, I will work with you to 
understand how BEX can fit in to your work.  If not see below.

HIP Directions

HIP -bis

We are working on recharting the HIP workgroup and rev all the 
documents, addressing a series of issues and moving to Standards Track.  
The big item is 'crytpo agility' that HIP is lacking.  Along the way we 
will be adding ECC PKs.  We do not see the work as long or hard, most of 
the spec changes will be done for July.  Of course debate can slow 
things.  This new version of BEX with the addition of ECC may well be 
suited to your needs, if you need transactional digitial signatures.

HIP Diet EXchage (HIP DEX)

I am writing an Internet Draft for DEX that will make the July 5th 
deadline.  There is also a presentation for IEEE 802 the week of Jul 12th.

DEX uses only THREE crypto algorithms:  AES-CCM, CMAC, ECC encryption.  
I tossed hashing and that threw out Diffie-Hellman and ECDSA.  Without 
PK signing I loose SigMa; I believe I have met the design goals of SigMa 
even so.  Without DH I loose PFS; DEX has a limited model where both 
party's keys must be compromised to expose the session key.

HIP DEX is 4 packets,  It also has an aggressive exchange model to deal 
with lossful networks.  There is no new crypto in DEX to evaluate.  No 
existing crypto is used in different manners to assess the risks.  Only 
how does this new exchange stand up to the current network attack 
models.  (or at least that is my Not So Humble Opinion on what I am 
writing up!).