Subject: Re: [core] Security design

From: Vipul Gupta <[email-masked]>
Date: Mon, 14 Jun 2010 16:43:00 -0700

The three levels of security outlined here seem like a good place 
to start although the "Shared Key" option is unlikely to scale 
beyond small deployments.

I'm also concerned about the choice of "CBC" mode which would 
unnecessarily extend the "in-sequence, loss-less delivery" 
requirement that DTLS already has for the handshake messages 
to data packets. Cipher-block chaining will preclude decryption
of packet (n+1) until packet n has been received and decrypted. 
A counter-mode encryption algorithm might be a better fit for UDP.

vipul
--
http://labs.oracle.com/people/mybio.php?c=509

> Date: Fri, 4 Jun 2010 11:47:47 -0600
> From: Cullen Jennings <[email-masked]>
> Subject: [core] Security design
> 
> 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
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Fri, 4 Jun 2010 12:33:53 -0600
> From: Cullen Jennings <[email-masked]>
> Subject: [core] SUB/NOT - the sea level view
> To: core <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
> 
> 
> Over the year I have had the pleasure of being in many conversations about what a stateless protocol is, what REST is, HTTP, polling, asynchronous notifications, web based RPC, and blowing soap bubbles.  Though interesting, I have a hard time concretely explaining it to anyone and the oxygen always seems a bit thin at the 10,000 foot view. I do however have a very easy time understanding a very low level view of the systems where there are  some boxes and arrow diagrams of  message flow and roughly the semantics of the data they cary. Let me try and draw my current understanding of how this is going to work.
> 
> We have two nodes - I will call them Source and Sink. 
> 
> 
>   Source         Sink       
>     |    SUB      |         
>     |<------------+         
>     |             |         
>     |    ACK      |         
>     +------------>|         
>     |             |         
>    ... Time Passes ...          
>     |             |         
>     |   NOTIF     |         
>     +------------>|          
>     |             |         
>     |   ACK       |         
>     |<------------+          
>     |             |         
> 
> 
> Sink starts by sending a message I will label "SUB" to the Source. The SUB messages says which resource the Sink would like to be informed about when the resource changes. The Source sends a OK or No there is a problem in some sort of ACK message to the SUB. Eventually the resource changes and Source sends an message I called "NOTIFY" to the Sink. This tells the Sink which resource changed and the current value of it.The Sink sends some sort of acknowledgment. I find the terms client and server very confusing when discussing SUB/NOT so I'm not using those terms. 
> 
> The Sink could be a HTTP proxy that mapped this to COMET, WebSocket, or plain old polling, XMPP, SMTP, just about anything. As far as I can tell, pretty much everything people have been proposing fit into this model.  So first, I'd like to get an idea if people think I am in left field and there is a very different message flow to consider. Second we need to figure out some of the stuff I left out of the picture above such as 
> 
> a) how to cancel a subscription 
> 
> b) how to get the initial value of the subscription around the time you subscribe 
> 
> c) what sort of filtering is available to limit the types of resource changes that result in a NOTIFY 
> 
> d) lifespan of subscription how to refresh a subscription
> 
> e) caching and interaction with sleeping device 
> 
> We have to be clear on how this maps to HTTP and possibly other protocols. One of the problems with HTTP is it has so many ways of doing asynchronous notifications that it hard to decide what to map for. I would be very conformable if we clearly new how to map it to HiBy and to direct HTTP polling. It would be nice to have  back of the cocktail napkin belief that it probably could be mapped to SMNP, XMPP, and the other HTTP approaches. My guess is that the mapping to other protocols is going to turn out to be easy. 
> 
> 
> 
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-archive/web/core/attachments/20100604/2481295c/attachment.htm>
> 
> ------------------------------
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
> 
> 
> End of core Digest, Vol 5, Issue 13
> ***********************************

---

From: Robert Cragie <[email-masked]>
Date: Tue, 15 Jun 2010 09:09:20 +0100

I think the three levels are right.

I don't approve of the use of AES_128_CBC as it requires both AES-128 
block cipher encode and decode. Stream ciphers such as AES_128_CCM or 
AES_128_GCM only require AES-128 encode operation. Due to the use of 
AES-CCM in 802.15.4, many 802.15.4 devices have built in support for 
AES-CCM and AES-128 block cipher encode. AES-128 decode is not widely 
implemented in these devices.

I also think we need to use SHA256 going forward. SHA1 is generally 
deprecated for use now.

And I have had enough of the ECC/RSA debate recently to last me a 
lifetime :-)

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com <http://www.gridmerge.com/>

On 15/06/2010 12:43 AM, Vipul Gupta wrote:
>> From: Cullen Jennings<[email-masked]>
>> From: Cullen Jennings<[email-masked]>
>> To: core<[email-masked]>
>> Message-ID:<[email-masked]>
>> URL:<http://www.ietf.org/mail-archive/web/core/attachments/20100604/2481295c/attachment.htm>
>>

---

From: Yoav Nir <[email-masked]>
Date: Tue, 15 Jun 2010 11:24:55 +0300

I'm not sure I understand how DTLS would work in an Internet-of-things environment. The networks are sometimes low-bandwidth and lossy, but the (D)TLS handshake takes a few roundtrips. You wouldn't want a full DTLS handshake every time some sensor wants to tell some controller that something has changed (say, a light switch has been toggled), especially if the controller is required to perform a prompt action (say, turn on the light). 

Are you envisioning long-lived sessions that last for days even if for most of the time the device is in low-power sleep mode? If so, some thought needs to be given to session maintenance, liveness checks, failure detection? 

Also, with a long lived session, how do you protect against replay attacks? 

Yoav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Vipul Gupta
Sent: Tuesday, June 15, 2010 2:43 AM
To: [email-masked]
Cc: Vipul Gupta
Subject: Re: [core] Security design

vipul

Scanned by Check Point Total Security Gateway.

---

From: Vipul Gupta <[email-masked]>
Date: Tue, 15 Jun 2010 12:36:34 -0700

My previous comment on CBC was incorrect. I had forgotten that DTLS uses
the altered definition of GenericBlockCipher from TLS 1.1 which adds 
explicit initialization vectors so the chaining only applies to blocks
within a single datagram and not across datagrams.

However, Robert makes a good point why counter mode might still be
preferable to CBC (e.g. CCM/GCM only require AES encode op
whereas CBC requires both encode and decode ops).

vipul
--
http://labs.oracle.com/people/mybio.php?c=50

---

From: Robert Cragie <[email-masked]>
Date: Wed, 16 Jun 2010 15:36:35 +0100

I have heard AES-CCM referred to as a stream cipher, although strictly 
speaking it is a mode of operation of a block cipher as you say. In TLS 
terms, it is an AEAD cipher. There should always be some sort of nonce 
in a protected record. In the case of TLS 1.2, it depends on the cipher 
but is effected by seq_num, IV or nonce_explicit, depending on the 
cipher. A typical nonce used for the key stream and embedded in the 
protected record is a monotonically increasing counter or sequence 
number and a simple last value (or window of last values) check is used 
at the receiver to detect replay attacks.

This brings me to the other point: DTLS should be upgraded to TLS 1.2. I 
am not sure if the work is in progress or not.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064

On 16/06/2010 9:19 AM, Yoav Nir wrote:
> I don't think any one's suggesting a stream cipher. All the algorithms that were mentioned were block ciphers.
>
> Also, I guess you are advocating long lived sessions.
>
> You said "if there is a nonce associated with each packet". Is there going to be such a nonce? DTLS doesn't have it, so it would have to be in the underlying protocol. What are the requirements for the responder to check this nonce?  IOW, if I capture an encrypted packet and see that this results in all the lights going off, what's to prevent me from retransmitting the same packet?  How would the controller know to not turn off all the lights this time around?
>
> ________________________________________
> From: Robert Cragie [mailto:[email-masked]]
> Sent: Tuesday, June 15, 2010 10:12 PM
> To: Yoav Nir
> You wouldn't need to do a handshake every time. You use the derived symmetric key for the stream cipher which persists for the duration of the session. If necessary, you can do session resumption based on the shared secret. If there is a nonce associated with each packet based on e.g. a frame counter or absolute time, I am not sure what the replay attack problem is with regard to a long-lived session.
>
> Robert
> Robert Cragie (Pacific Gas&  Electric)
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 1924 910888
> +1 415 513 0064
> http://www.gridmerge.com
>
> On 15/06/2010 9:24 AM, Yoav Nir wrote:

---

From: Richard Kelsey <[email-masked]>
Date: Wed, 16 Jun 2010 15:19:20 -0400

> Date: Wed, 16 Jun 2010 15:36:35 +0100
> From: Robert Cragie <[email-masked]>
>
> This brings me to the other point: DTLS should be upgraded to TLS 1.2.
> I am not sure if the work is in progress or not.

>From poking around on the IETF website,
draft-ietf-tls-rfc4347-bis-03 is DTLS 1.2.  It expired in
April.  It went to working group last call in October 2009,
with only minor changes recommended.  See
  http://www.ietf.org/mail-archive/web/tls/current/msg03867.html
I couldn't find any indication of further activity.

                                        -Richard Kelsey

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 17 Jun 2010 07:46:56 +0200

> I couldn't find any indication of further activity.

Just got word from the TLS chairs that this got sidestepped for a while, but the updated version is planned before Maastricht.  I think we should use the time in Maastricht to do some cross-area discussion.
(Besides TLS, interesting security-related WGs to watch might include HIP.)

Gruesse, Carsten

---

From: Shoichi Sakane <[email-masked]>
Date: Fri, 18 Jun 2010 14:56:18 +0900

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.

Shoichi Sakane

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 19 Jun 2010 12:08:04 -0600

> TLS and DTLS is little different protocol, maybe 50% is same.

Just two minor points .... I was looking at the the code for DTLS in openssl and it it looked like it nearly all the code for TLS and DTLS were the same. 

I'll remind people that HIP does not actually provide confidentiality or integrity of traffic - that is provided by running HIP over IPSEC.

---

From: Tobias Heer <[email-masked]>
Date: Sun, 20 Jun 2010 13:26:14 +0200

Hi, 

> I'll remind people that HIP does not actually provide confidentiality or integrity of traffic - that is provided by running HIP over IPSEC.
Yes, you are right. HIP does not have its own mechanisms for handling the actual payload but relies on IPsec. Therefore, HIP requires at least one IPsec mode (preferably BEET).

Just a tiny clarification to avoid confusion. HIP doesn't actually run over IPsec but sets up IPsec security associations for the playload. Hence, HIP runs directly on IP while all payload is handled by IPsec. However, the IPsec security associations use the symmetric keys that were exchanged during the HIP handshake.

Tobias

-- 
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: Shoichi Sakane <[email-masked]>
Date: Mon, 21 Jun 2010 09:55:07 +0900

Hi,

> Just a tiny clarification to avoid confusion. HIP doesn't actually run over IPsec but sets up IPsec security associations for the playload. Hence, HIP runs directly on IP while all payload is handl…

Tobias,

Thanks for the clarification.  Yes, I intended to run HIP with IPsec.

Cullen,

I don't say that IPsec is the best.  I just say current my impression.
If we could need only UDP, and one or two session would run on a sensor,
DTLS would be nice.  But, my impression from the discussion on the WG that
we can't assume an simple environment.  So, my impression was shifted into
the lower layer.

I also looked the code of OpenSSL openssl-0.9.8.  The representation of
percentage was not suitable to show difference.  That was my fault.
Actually, 14 files, 8242 lines and 227387 bytes in total are added for
DTLS.  The evaluations are different by each person.

Shoichi Sakane

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 21 Jun 2010 12:09:08 -0700 (PDT)

Hi Carsten,
 Yes, we should continue to watch these things but currently we do have a draft:
http://tools.ietf.org/id/draft-oflynn-core-bootstrapping-00.txt
that Colin and I have submitted for the charter item on Constrained security bootstrapping specification. 

If comments could be directed to this draft, the authors would be in a better position to revise it.

Regards,

Behcet

----- Original Message ----
> From: Carsten Bormann <[email-masked]>
> To: core <[email-masked]>
> Sent: Thu, June 17, 2010 12:46:56 AM

> I 
> couldn't find any indication of further activity.

Just got word from the 
> TLS chairs that this got sidestepped for a while, but the updated version is 
> planned before Maastricht.  I think we should use the time in Maastricht to 
> do some cross-area discussion.
(Besides TLS, interesting security-related WGs 
> to watch might include HIP.)

Gruesse, 
> Carsten

core mailing 
> list
> href="mailto:[email-masked]">[email-masked]
> href="https://www.ietf.org/mailman/listinfo/core" target=_blank

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 21 Jun 2010 12:09:13 -0700 (PDT)

Hi Carsten,

Regards,

Behcet

----- Original Message ----

Just got word from the 

Gruesse,