[core] #294: Add discussion of using non-trivial token for protecting against hijacking

["core issue tracker" <[e-mail]>]

#294: Add discussion of using non-trivial token for protecting against hijacking

 Michael Scharf (tsv-dir reviewer) notes (msg04191-tsvdir-6):

 Section 11

 * Section 11

 => This section IMHO needs a discussion on minimum requirements on how to
 select Message ID and Tokens. Both are a means to protect against
 "hijacking" of transactions / falsification of responses, but if an
 attacker can guess these values, an attacker can inject wrong data into a
 CoAP communication. Compare e.g. to a TCP receiver that carefully checks
 whether sequence numbers are valid, i.e., within the receive window.

 * Section 5.3.1

 »The Token is used to match a response with a request.  The token value is
 a sequence of 0 to 8 bytes.«

 => While CoAP optimizes its protocol fields for single bits, the document
 does not comment at all on reasonable sizes for the token. At least some
 text mentioning the high overhead of a 4 or 8 byte token compared to the
 rest of the CoAP headers could be useful. Possibly also addressing the
 security-size tradeoff.

 Carsten Bormann plans to reply:

 The Token length was chosen to be as big as it is to enable this kind of
 protection, if desired.  More likely, we will simply use DTLS security
 where that matters.  But a short discussion of this could be added. Note
 that there is a recommendation that message-IDs are allocated sequentially
 in draft-ietf-lwig-guidance; for a constrained system, this may be the
 only way to keep enough message state for reliable duplicate removal.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  [e-mail]
  [e-mail]           |     Status:  new
     Type:  other        |  Milestone:  post-IESG-1
  technical              |    Version:  coap-14
 Priority:  minor        |   Keywords:
Component:  coap         |
 Severity:  Submitted    |
  WG Document            |
-------------------------+-------------------------------------------------

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