Re: [secdir] Secdir review of draft-ohba-pana-relay

[Alan DeKok <[e-mail]>]

Yoshihiro Ohba wrote:
> Relaying happens only one time for each message belonging to the same
> PANA session.  We can clarify this in the draft.

  Yes.  The draft does not forbid a message passing through multiple relays.

> I agree that some message validity check at the PRE can help address
> issues you mentioned above.  In my analysis: (1) Some check requires
> the PRE to be stateful (e.g., sequence number check on relayed PANA
> message requires the PRE to keep track of sequence numbers for each
> session), (2) some check does not require the PRE to be stateful
> (e.g., message length check), and (3) some check is impossible unless
> security is compromised (e.g., AUTH AVP check of relayed PANA message
> using the PANA SA between the PaC and the PAA).  Let's discuss (1) and
> (2).   There are several design choices here:
> 
> (a) (1) and (2) are mandatory
> (b) (1) is optional, (2) is mandatory
> (c) (1) and (2) are optional
> 
> I listed these choices because ZigBee has chosen pana-relay mainly
> because of the stateless nature of PRE in its current design and I
> think that making PRE stateful can be a too strong requirement for ZigBee.

  A cryptographic token can help with this.  The token can contain
information about the sequence number, signed by a secret known only to
the PRE.

> To address Margaret's security comment, we (co-authors) are currently
> discussing whether we can recommend use of DTLS to protect PRY message
> between PRE and PAA for less-trusted environment.  Your suggested
> token-based approaches (PRE-generated and PaC-generated tokens) can be
> another recommendation for similar environment.  I think we need to
> consider tradeoff between the level of improvement in security and the
> required cost for each alternative.

  Yes.  Adding a token is simple, and requires minimal changes to the
PAA (echo the token), and some small work on the PRE (generate / verify
the token).

  In contrast, DTLS takes much more work.

  Alan DeKok.