[Pana] FW: Token (was RE: Secdir review of draft-ohba-pana-relay)

"Alper Yegin" <alper.yegin@yegin.org> Tue, 14 December 2010 08:39 UTC

From: Alper Yegin <alper.yegin@yegin.org>
To: pana@ietf.org
Date: Tue, 14 Dec 2010 10:40:41 +0200
Message-ID: <002e01cb9b6a$99e71cd0$cdb55670$@yegin>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcuYPqjxXV+rcKfeSK63xsDrVdaSlACYQXfAADK45AA=
Content-Language: en-us
Subject: [Pana] FW: Token (was RE: Secdir review of draft-ohba-pana-relay)
Precedence: list

Resending to the list...

-----Original Message-----
From: Alper Yegin [mailto:alper.yegin@yegin.org] 
Sent: Monday, December 13, 2010 10:32 AM
To: 'Yoshihiro Ohba'; 'Alan DeKok'
Cc: 'secdir@ietf.org'; 'draft-ohba-pana-relay@tools.ietf.org';
'margaretw42@gmail.com'; 'Ralph Droms'; 'paduffy@cisco.com';
'samitac@ipinfusion.com'; 'robert.cragie@gridmerge.com'; 'pana@ietf.org'
Subject: Token (was RE: Secdir review of draft-ohba-pana-relay)

Alan,

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

Arbitrary traffic cannot pass the validation on the PaC, as the sequence
numbers need to match. And there is also state machine match needed. PaC's
is in certain state and would not react to any arbitrary message unless the
message is expected in the current state.

Alper

[Pana] FW: Token (was RE: Secdir review of draft-… Alper Yegin