[secdir] Token (was RE: Secdir review of draft-ohba-pana-relay)
"Alper Yegin" <alper.yegin@yegin.org> Mon, 13 December 2010 08:30 UTC
Return-Path: <alper.yegin@yegin.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D11DD3A6CE7; Mon, 13 Dec 2010 00:30:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.59
X-Spam-Level:
X-Spam-Status: No, score=-99.59 tagged_above=-999 required=5 tests=[AWL=-1.040, BAYES_50=0.001, MSGID_MULTIPLE_AT=1.449, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDXGfSN34+5R; Mon, 13 Dec 2010 00:30:25 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id E4C783A6CDE; Mon, 13 Dec 2010 00:30:24 -0800 (PST)
Received: from ibm (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0M1FVw-1QKqEd3fTs-00t71D; Mon, 13 Dec 2010 03:32:00 -0500
From: Alper Yegin <alper.yegin@yegin.org>
To: 'Yoshihiro Ohba' <yoshihiro.ohba@toshiba.co.jp>, 'Alan DeKok' <aland@deployingradius.com>
References: <4D009D34.1020809@deployingradius.com> <4D01DABF.6060604@toshiba.co.jp>
In-Reply-To: <4D01DABF.6060604@toshiba.co.jp>
Date: Mon, 13 Dec 2010 10:31:45 +0200
Message-ID: <001101cb9aa0$367b3480$a3719d80$@yegin>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcuYPqjxXV+rcKfeSK63xsDrVdaSlACYQXfA
Content-Language: en-us
X-Provags-ID: V02:K0:ziwkryUESO3ycLQz805SxrCb840R42bq8QBvjTYIkGI q2bUQ9YF/f1ruZ9+ysadYlm/kVBVsB8qduj7eQgeu9rhsMGqua kOAZcAPJvTTmYqHVug1D0jjcHw2B40UJx1mU51c8P/dQc4BHXd hmxIwlkvqta/1gCp1UMVWBg6WZNT4JmBLU269ESCAxo5K7Jwzg HwS9Sv/qQZw74OEKWNPYb8oN1XajQsHNVFvHddoYVQ=
Cc: secdir@ietf.org, draft-ohba-pana-relay@tools.ietf.org, margaretw42@gmail.com, pana@ietf.org, paduffy@cisco.com, robert.cragie@gridmerge.com, samitac@ipinfusion.com, 'Ralph Droms' <rdroms.ietf@gmail.com>
Subject: [secdir] Token (was RE: Secdir review of draft-ohba-pana-relay)
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Dec 2010 08:30:25 -0000
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
- [secdir] Secdir review of draft-ohba-pana-relay Alan DeKok
- Re: [secdir] Secdir review of draft-ohba-pana-rel… Yoshihiro Ohba
- Re: [secdir] Secdir review of draft-ohba-pana-rel… Alan DeKok
- [secdir] PRE enforcing message validity (was RE: … Alper Yegin
- [secdir] Token (was RE: Secdir review of draft-oh… Alper Yegin
- Re: [secdir] PRE enforcing message validity (was … Alan DeKok
- Re: [secdir] Token (was RE: Secdir review of draf… Alan DeKok
- Re: [secdir] Token (was RE: Secdir review of draf… Alan DeKok
- Re: [secdir] Token (was RE: Secdir review of draf… Robert Cragie
- Re: [secdir] Token (was RE: Secdir review of draf… Robert Cragie
- Re: [secdir] Token (was RE: Secdir review of draf… Alan DeKok
- Re: [secdir] Token (was RE: Secdir review of draf… Alan DeKok
- Re: [secdir] Token (was RE: Secdir review of draf… Robert Cragie
- Re: [secdir] Token (was RE: Secdir review of draf… Robert Cragie
- [secdir] pana-relay security considerations Alper Yegin
- Re: [secdir] pana-relay security considerations Alan DeKok
- Re: [secdir] pana-relay security considerations Alper Yegin
- Re: [secdir] pana-relay security considerations Alan DeKok
- Re: [secdir] pana-relay security considerations Alper Yegin
- Re: [secdir] pana-relay security considerations Alan DeKok
- Re: [secdir] pana-relay security considerations Alan DeKok
- Re: [secdir] pana-relay security considerations Margaret Wasserman
- Re: [secdir] pana-relay security considerations Alper Yegin