Subject: Re: [core] #311: Selecting a token length for anti-spoofing

From: "core issue tracker" <[email-masked]>
Date: Wed, 01 May 2013 12:02:50 -0000

#311: Selecting a token length for anti-spoofing

Comment (by [email-masked]):

 From [1361]:

 More information about randomness in tokens, see #311

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-
  [email-masked]           |  [email-masked]
     Type:  other        |      Status:  new
  technical              |   Milestone:  post-IESG-1
 Priority:  critical     |     Version:  coap-15
Component:  coap         |  Resolution:
 Severity:  Submitted    |
  WG Document            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: </ticket/311#comment:1>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Wed, 01 May 2013 20:07:27 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 Fixed in -16.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-
  [email-masked]           |  [email-masked]
     Type:  other        |      Status:  closed
  technical              |   Milestone:  post-IESG-1
 Priority:  critical     |     Version:  coap-15
Component:  coap         |  Resolution:  fixed
 Severity:  Submitted    |
  WG Document            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/311#comment:2>
core <http://tools.ietf.org/core/>

---

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 6 May 2013 11:15:15 +0000

Carsten,

thanks for your extensive work in editing and 'ticketizing' the IESG comments. My feedback on -- #311 selecting a token length ("Randomness in tokens"):
the new text you propose seems to me a good solution to the issues that were noted.

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of core issue tracker
Sent: Monday, April 29, 2013 17:47
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [core] #311: Selecting a token length for anti-spoofing

 Stephen Farrell and Richard Barnes note (msg04285d, msg04288a):

 Section 5.3.1

 Stephen Farrell:

 I suspect you need to have text trading off the Token length versus use of  DTLS or else CoAP may end up too insecure for too many uses. (Note: the  attack here is made worse because the message ID comparison can be  skipped. Removing that "feature" would help a lot here.) 5.3.1's client  "may want to use a non-trivial, randomized token" doesn't seem to cut it  to me. How does this kind of interaction map to DTLS sessions/epoch?
 Basically, I'd like to see some RECOMMENDED handling of token length that  would result in it not being unsafe to connect a CoAP node to the  Internet. (And please note recent instances where 10's of thousands of  insecure devices have been found via probing the IPv4 address space. These  are real attacks.)

 Carsten says:

 Well, ceterum censeo BCP39. But it seems the discussion at the end of
 5.3.1 could make the security considerations for selecting a token value  in NoSec mode more explicit.  Right now the basic consideration, but not  the parameters that go into it, is discussed in 11.4 as well.

 Richard Barnes says:

 In Section 5.3.1, "A client sending a request...".  This needs to be  stronger.  The requirement for a randomized token needs to be a MUST, and  the stack SHOULD limit the number of rejected responses (before closing  the request) based on the length of the token (e.g., 2**(TKL/2)).

 Carsten says:

 (See also Stephen's most recent reply: http://www.ietf.org/mail-  archive/web/core/current/msg04302.html where he seems to argue for a
 RECOMMENDATION.)

 The specification is currently leaving to the client the level of  protection that it makes use of: It can choose the token length based on  its security requirements.

 The phrasing certainly can be improved to avoid the RFC6919 allusion (as  in "MAY WISH TO") and to explain the criteria for choosing the size. E.g.,  explain that, with N=TKL*8 (possibly plus 16 if this is an ACK and the  Message ID also matches, even though that should generally not be  randomized), an off-path attacker has a chance of 2**-N per spoof to  successfully spoof a response.

 To the lockdown proposal (2**(N/2)): Interesting idea.  We don't have  experience with that yet.  One issue might be correlating incoming non-  matching responses to a specific request.  As with any lockdown mechanism,  the potential for DoS (or pure malfunction) also needs to be considered.
 A client that keeps some state can tally recent non-matching responses to  derive a "current attack level"; this might then be used to adjust its  token length for future requests.

 (In today's constrained node networks, attack packet rates that make this  more than a somewhat theoretical concern already will cause other  problems, but we'll need to make the protocol robust for the "cloud" side  as well.)

--
-------------------------+----------------------------------------------
-------------------------+---
 Reporter:               |      Owner:  [email-masked]
  [email-masked]           |     Status:  new
     Type:  other        |  Milestone:  post-IESG-1
  technical              |    Version:  coap-15
 Priority:  critical     |   Keywords:
Component:  coap         |
 Severity:  Submitted    |
  WG Document            |
-------------------------+----------------------------------------------
-------------------------+---

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/311>
core <http://tools.ietf.org/core/>

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