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

[Yoshihiro Ohba <[e-mail]>]

Thank you very much for reviewing the draft.  Please see my comments
below.

(2010/12/09 18:11), Alan DeKok wrote:
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG. These comments were written primarily for the benefit of the
> security area directors. Document editors and WG chairs should treat
> these comments just like any other last call comments.
> 
> Margaret Wasserman said:
>> IMO, there is (at least) one way in which the introduction of a relay
>> changes the security model for PANA.  In the original PANA protocol,
>> the PANA Authentication Agent (PAA) determines the source IP Address
>> and source UDP Port number of the PANA Client (PaC) by looking in the
>> headers of the request, and responds to that IP Address/Port.
>> However, in the case where a relay is being used, the client IP
>> Address/Port are included in an option in the relay message.  Requests
>> are sent from the relay and responses are sent to the relay, using the
>> IP Address/Port in the headers, but the client (using information from
>> the option) is authenticated.  I understand that this changes the
>> security properties of the PANA exchange, but I am not sure if it
>> changes them in a way that matters for the PANA protocol.
>>
>> So, I could use help here from someone who understands EAP (and
>> ideally, PANA) well enough to understand how/if a relay can safely be
>> used in a PANA environment.
> 
>    The proposed document doesn't affect the security of EAP.  EAP is
> already transported over insecure and unauthenticated channels (i.e.
> EAPoL), so changing the PANA transport requirements should have no
> effect on EAP.
>
>    Some questions:
> 
> Are multiple relays allowed?  If so, how do they work?  If not, how are
> they detected, and forbidden by the participants?
> 

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

>    The Security Considerations section says:
> 
>     Since the PRE does not maintain per-PaC state, the PRE is robust
>     against resource consumption DoS (Deniable of Service) attack.
> 
>    However, the PRE relays packets to the PaC.  This means that entities
> on the PAA network can now send PANA messages to the PaC, when they
> previously could not.  While the PaC is supposed to discard invalid
> and/or unexpected messages (RFC 5191), the PRE can be used to send
> messages to *arbitrary* UDP ports on the PaC or any other machine in the
> PaC network.
> 
>    The same attack applies (but less so) in the inverse direction.  A
> fake PaC can send the PAA arbitrary PANA messages.  Since this can
> already happen today, there is no new issue here.
> 
>    Having a stateful PRE would help address this attack.  It would not
> prevent it, as the PANA messages are unsigned, and anyone can pretend to
> be the PRE.
> 
>    I would suggest requiring that the PRE enforce the Message Validity
> checks of RFC 5191, Section 5.5.  If this cannot be done in its
> entirety, this draft should add a new section entitled "Message Validty
> checks for the PRE".
> 
>    e.g. The PRE MUST relays only well-formed PANA messages to the PAA.
> And before relaying messages back to the PaC, it ensures that the
> Relayed-Message AVP contains a well-formed PANA message.  All malformed
> messages MUST be discarded.
> 

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.

(Just to clarify, "stateless" here means that per-PaC state does not
need to be maintained by PRE.)

>    Since the behavior of the PAA is also changing, it would be good to
> leverage the PAA session tracking to add a cryptographic token between
> the PRE and PAA.  This token would be added by the PRE prior to relaying
> a message, and the PAA could echo it back in the response.   This
> ability means that the PRE is still stateless (in terms of tracking
> packets), but gains a little bit of security by maintaining additional
> state.
> 
>   The token would be subject to eavesdropping, so it offers small
> additional security.  Adding it is a recommendation, not a requirement
> of this review.
> 
>    The token could be (for example) a signature of the PaC source IP and
> port, using a secret known only to the PaC, and generated automatically.
>   The secret would also need to change periodically.
> 
>    Along with Message Validation, this token would increase the bar for
> attackers sending packets to the PaC.  Rather than simply being able to
> leverage the PRE to send arbitrary traffic to the PaC, the attacker
> would need to be able to monitor PRE ->  PAA traffic, and to then send
> well-formed PANA messages to the PaC, to the port used by the PaC for
> receiving PANA messages.  That minimizes the attack exposure.
> 

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.

> 
>     There is also some confusion between PRE and PRY, such as:
> 
>     (c) The source IP address and UDP port number of the PRY is stored in
>     a new PANA session attribute "IP address and UDP port number of the
>     PRE".
> 
>    The text should consistently refer to "address of the PRE", or
> "address carried within the PRY"

We will improve the consistency about referring to addresses.

Thank you,
Yoshihiro Ohba

> 
> 
>    Alan DeKok.
> 
>