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

From: "core issue tracker" <[email-masked]>
Date: Mon, 29 Apr 2013 15:47:17 -0000

#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/>