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

Leif Johansson <> Tue, 08 July 2014 13:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A86CC1B283E; Tue, 8 Jul 2014 06:31:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.422
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uqnPrTDLaYaW; Tue, 8 Jul 2014 06:31:28 -0700 (PDT)
Received: from ( [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 246921B282B; Tue, 8 Jul 2014 06:31:27 -0700 (PDT)
Received: from ( [IPv6:2001:6b0:8:2::214]) by (8.14.4/8.14.4/Debian-4) with ESMTP id s68DVOTC010262 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Jul 2014 15:31:24 +0200
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id s68DVI4E018774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jul 2014 15:31:21 +0200 (CEST)
X-Footer: c3VuZXQuc2U=
Received: from [] ([]) (authenticated user by (Kerio Connect 8.2.4) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128 bits)); Tue, 8 Jul 2014 15:31:17 +0200
Message-ID: <>
Date: Tue, 08 Jul 2014 15:31:17 +0200
From: Leif Johansson <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Koodli, Rajeev" <>, "" <>, IESG <>, "" <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN)
X-CanIt-Geo: ip=; country=SE; latitude=62.0000; longitude=15.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: 09MnNvoAu - 5fe47dd6c817 - 20140708
X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw
X-Scanned-By: CanIt (www . roaringpenguin . com)
Subject: Re: [secdir] secdir review odraft-ietf-netext-wifi-epc-eap-attributes
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Jul 2014 13:31:30 -0000

On 2014-07-08 00:51, Koodli, Rajeev wrote:
> Hi Leif,
> Thanks for the review.
> Please see inline:
> On 7/7/14, 1:18 AM, "Leif Johansson" <> 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.
>> 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.
> You mean the ³SHOULD² should be made specific to 3GPP? If so, we can
> clarify at the beginning itself.


>> 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.
> We can clarify this.
> The AT_CONNECTIVITY_TYPE attribute indicates what connectivity type MN
> wants to use. The Network (³3GPP AAA Server²) communicates with the
> subscriber database ("3GPP HSS") to retrieve MN credentials, but this is
> outside the scope of this ID and is specific to 3GPP. Regardless, the
> Network provides back to the MN what is supported (based on the
> credentials obtained from the subscriber database). So, the MN signaling
> the attribute does not create new threats.

Yeah I understand how the attribute works. What I don't understand is
how the MN knows it gets the AT_CONNECTIVITY_TYPE from the right source
since this handshake happens before the EAP authentication has finished.

Again - I may just be confused about EAP...

	Cheers Leif