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

"Koodli, Rajeev" <rajeev.koodli@intel.com> Tue, 08 July 2014 16:17 UTC

Return-Path: <rajeev.koodli@intel.com>
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 CE36C1B2B99; Tue, 8 Jul 2014 09:17:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.102
X-Spam-Level:
X-Spam-Status: No, score=-5.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
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 5-Ryjc_4NQox; Tue, 8 Jul 2014 09:17:57 -0700 (PDT)
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by ietfa.amsl.com (Postfix) with ESMTP id 245511B2B95; Tue, 8 Jul 2014 09:17:57 -0700 (PDT)
Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 08 Jul 2014 09:17:55 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.01,625,1400050800"; d="scan'208";a="566800142"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34]) by fmsmga002.fm.intel.com with ESMTP; 08 Jul 2014 09:17:51 -0700
Received: from fmsmsx111.amr.corp.intel.com (10.18.116.5) by FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 8 Jul 2014 09:17:51 -0700
Received: from fmsmsx105.amr.corp.intel.com ([169.254.5.225]) by fmsmsx111.amr.corp.intel.com ([169.254.12.83]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 09:17:51 -0700
From: "Koodli, Rajeev" <rajeev.koodli@intel.com>
To: Leif Johansson <leifj@sunet.se>, "secdir@ietf.org" <secdir@ietf.org>, IESG <iesg@ietf.org>, "draft-ietf-netext-wifi-epc-eap-attributes.all@tools.ietf.org" <draft-ietf-netext-wifi-epc-eap-attributes.all@tools.ietf.org>
Thread-Topic: secdir review odraft-ietf-netext-wifi-epc-eap-attributes
Thread-Index: AQHPmbxSp13TgeTpn02AF6Q7mf9UjZuVOHsAgAFrL4D//7k5gA==
Date: Tue, 8 Jul 2014 16:17:50 +0000
Message-ID: <CFE160D4.1613%rajeev.koodli@intel.com>
References: <53BA57E3.8080300@sunet.se> <CFE03243.1594%rajeev.koodli@intel.com> <53BBF2A5.10506@sunet.se>
In-Reply-To: <53BBF2A5.10506@sunet.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.254.93.52]
Content-Type: text/plain; charset="euc-kr"
Content-ID: <4CB080EACC8D624A840EDDCA60DE7B90@intel.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/7B6rWHPFyQifrO-nLazVGzn7tIg
Subject: Re: [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: Tue, 08 Jul 2014 16:17:59 -0000


On 7/8/14, 6:31 AM, "Leif Johansson" <leifj@sunet.se>; wrote:

>On 2014-07-08 00:51, Koodli, Rajeev wrote:
>> 
>>>
>>> 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...


The MN verifies the AUTN (AKA parameter) sent in EAP-Request/AKA-Challenge
to conclude the legitimacy of the source. At this point, EAP-AKA has not
completed yet. If AUTN verification is successful, the MN responds back
with EAP-Respone/AKA-Challenge. See RFC 4187, Section 3:

"The peer runs the AKA algorithm (typically using an identity module)
   and verifies the AUTN.  If this is successful, the peer is talking to
   a legitimate EAP server and proceeds to send the EAP-Response/
   AKA-Challenge…”

-Rajeev



>
>	Cheers Leif
>