[secdir] secdir review odraft-ietf-netext-wifi-epc-eap-attributes

Leif Johansson <leifj@sunet.se> Mon, 07 July 2014 08:18 UTC

Return-Path: <leifj@sunet.se>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7814D1B27A8; Mon, 7 Jul 2014 01:18:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.422
X-Spam-Level:
X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUaP_gdFEVfD; Mon, 7 Jul 2014 01:18:50 -0700 (PDT)
Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E84D1B27A7; Mon, 7 Jul 2014 01:18:50 -0700 (PDT)
Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s678IlNl023858 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Jul 2014 10:18:47 +0200
Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id s678IiOD006663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2014 10:18:47 +0200 (CEST)
X-Footer: c3VuZXQuc2U=
Received: from [193.10.94.125] ([193.10.94.125]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.2.4) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128 bits)); Mon, 7 Jul 2014 10:18:43 +0200
Message-ID: <53BA57E3.8080300@sunet.se>
Date: Mon, 07 Jul 2014 10:18:43 +0200
From: Leif Johansson <leifj@sunet.se>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: secdir@ietf.org, IESG <iesg@ietf.org>, draft-ietf-netext-wifi-epc-eap-attributes.all@tools.ietf.org
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN)
X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6
X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default)
X-Canit-Stats-ID: 09MnkiLLj - f784cdb89a0a - 20140707
X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw
X-Scanned-By: CanIt (www . roaringpenguin . com)
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/WaqUqAn-JYdn4nkQbSRD3p8hQVI
Subject: [secdir] secdir review odraft-ietf-netext-wifi-epc-eap-attributes
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 07 Jul 2014 08:18:52 -0000

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.

The drafts define a set of EAP attributes for signalling wifi handover
from 3gpp devices. In general the draft is well written.

I believe the draft is more or less ready. I have two comments, one of
which is stylistic and the other may be just me misunderstanding the
EAP-AKA handshake...

1. In a few places the draft sais that the defined attributes SHOULD be
used. I would qualify this to say that "mobile nodes implementing the
spec SHOULD" since EAP is used in a lot of situations where 3gpp _could_
be used but isn't.

2. It seems like AT_CONNECTIVITY_TYPE is signalled before the EAP
challenge is completed. Unless I misunderstood something I think this
warrants a discussion in the Security Considerations section. Currently
the text in that section only talks about when attributes are to be
processed but there is no discussion of possible threats based on when
attributes are transmitted.

	Cheers Leif