Re: [Pana] IESG discussions on draft-ohba-pana-relay

"Alper Yegin" <alper.yegin@yegin.org> Fri, 24 June 2011 08:10 UTC

Return-Path: <alper.yegin@yegin.org>
X-Original-To: pana@ietfa.amsl.com
Delivered-To: pana@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A56C11E8089 for <pana@ietfa.amsl.com>; Fri, 24 Jun 2011 01:10:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.15
X-Spam-Level:
X-Spam-Status: No, score=-101.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmARxJLHWs65 for <pana@ietfa.amsl.com>; Fri, 24 Jun 2011 01:10:09 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 1864711E8087 for <pana@ietf.org>; Fri, 24 Jun 2011 01:10:09 -0700 (PDT)
Received: from ibm (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0Lon23-1RGo7S2FA3-00fx6P; Fri, 24 Jun 2011 04:09:40 -0400
From: "Alper Yegin" <alper.yegin@yegin.org>
To: "'Jari Arkko'" <jari.arkko@piuha.net>, "'Yoshihiro Ohba'" <yoshihiro.ohba@toshiba.co.jp>, <pana@ietf.org>
References: <4DF04217.3080304@toshiba.co.jp> <6491375641982933760@unknownmsgid> <BANLkTinVZ2Bvd6A+znQTiB7X-P6XXh3Cow@mail.gmail.com> <4E037743.2060602@gridmerge.com> <4E037A9D.8080200@piuha.net>
In-Reply-To: <4E037A9D.8080200@piuha.net>
Date: Fri, 24 Jun 2011 11:09:21 +0300
Message-ID: <021a01cc3246$0b890390$229b0ab0$@yegin@yegin.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcwxzLSaaiXIpFF7SoaV+7DotegRqwAd597g
Content-Language: en-us
X-Provags-ID: V02:K0:j7DiO5+X4D/Xs4laS04ohoSkbpqRyGZ6pGJ1tj5ofVh mbdG+j+3of4z7elY+Q9gUllx0EMyvdreShfa6/dY/7r43bb9Gj j4LuV91mTxz8VHVfaDA8x4ppoEgQGxmFQ9ItxvXWSTzgVYVF3a O3k2JPUDBFpbvPSTBAcwTFgzuzk/YZzuZ29KugigV4ZMHmCmG+ 0hs4oGkl5uHmoK+vg8M8hpD2uKJ4H+HFMcaeE3/SSM=
Cc: draft-ohba-pana-relay@tools.ietf.org, 'Stephen Farrell' <stephen.farrell@cs.tcd.ie>
Subject: Re: [Pana] IESG discussions on draft-ohba-pana-relay
X-BeenThere: pana@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Protocol for carrying Authentication for Network Access <pana.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pana>, <mailto:pana-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pana>
List-Post: <mailto:pana@ietf.org>
List-Help: <mailto:pana-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jun 2011 08:10:10 -0000

I think importing text from the other one Stephen had suggested would be an
improvement. Like this:


3. Security of Messages Sent between PRE and PAA

PRE/PAA security is OPTIONAL since PANA messages are designed to be
used in untrusted networks, but if cryptographic mechanism is
supported, it SHOULD be IPsec. When the device characteristics preclude
support for IPsec, an alternative mechanism such as DTLS [REF], or
link-layer cryptographic security, etc. may be used instead. This section
describes how IPsec [RFC4301] can be used for securing the PANA relay
messages.

Alper




> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net]
> Sent: Thursday, June 23, 2011 8:41 PM
> To: Yoshihiro Ohba; pana@ietf.org
> Cc: Stephen Farrell; draft-ohba-pana-relay@tools.ietf.org
> Subject: IESG discussions on draft-ohba-pana-relay
> 
> We discussed this draft today. The remaining Discuss was about how
> mandatory we should make IPsec. You had discussed about a SHOULD with
> Stephen. I suggested that while interoperability is useful and
> mandatory-to-implement mechanisms are good for it, we also have to talk
> about how much value we bring with a security mechanism. In this case
> there are some issues like MITMs able to block PANA packets. However,
> some of these vulnerabilities are not helped by relay - PAA security,
> as
> the relay can still do bad things, and because ARP/ND vulnerabilities
> between the client and relay in any case make it possible to become a
> MITM. Stephen had some suggested text that I agree with:
> 
> "PRE/PAA security is OPTIONAL since PANA messages are designed to be
> used in untrusted networks, but if cryptographic mechanism is
> supported,
> it SHOULD be IPsec."
> 
> Jari