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

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Tue, 08 July 2014 17:15 UTC

Return-Path: <jsalowey@cisco.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 59D2B1A036E; Tue, 8 Jul 2014 10:15:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.702
X-Spam-Level:
X-Spam-Status: No, score=-12.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 V4miTkvU3DUq; Tue, 8 Jul 2014 10:15:23 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9752D1B2B56; Tue, 8 Jul 2014 10:15:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3264; q=dns/txt; s=iport; t=1404839725; x=1406049325; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hEQUGSR8hhx9GNLbcsA7d4IwOVVwf+yECLRpPEuDALA=; b=JGVvhh/lc6zsq5tiygmn1bopipXED1AUjVdM5a5tL4EX7mP5JO6vzujK 6uCeEft8WY1+v15b97SoLjnywa+2YZBCTl/BrvXF7vvrFzjVomcgcMMSn c5Fy8zZRrs1Dr3rCJsz+gKbyV9/UYfUgDX1XFr7RmhRk0FzPBiK1706kH Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhcFAHQmvFOtJA2B/2dsb2JhbABRCYMOUlqCb7wUCIZuUwEZfxZ1hAMBAQEDAQEBATE6CxACAQYCGAQoAgIlCyUCBA4FiDoIDZJBnB8GmUMXgSaNQSgYGweCcTyBFgWadoFIkkSDQ4Iw
X-IronPort-AV: E=Sophos;i="5.01,626,1400025600"; d="scan'208";a="59195544"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP; 08 Jul 2014 17:15:24 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s68HFLI6003494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jul 2014 17:15:21 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 12:15:21 -0500
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: "Koodli, Rajeev" <rajeev.koodli@intel.com>
Thread-Topic: [secdir] secdir review odraft-ietf-netext-wifi-epc-eap-attributes
Thread-Index: AQHPmbxSp13TgeTpn02AF6Q7mf9UjZuVOHsAgAFrL4D//7k5gIAAY+eA
Date: Tue, 8 Jul 2014 17:15:21 +0000
Message-ID: <298C55D6-7F96-4BB5-9313-BA02A2B4D2F2@cisco.com>
References: <53BA57E3.8080300@sunet.se> <CFE03243.1594%rajeev.koodli@intel.com> <53BBF2A5.10506@sunet.se> <CFE160D4.1613%rajeev.koodli@intel.com>
In-Reply-To: <CFE160D4.1613%rajeev.koodli@intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.33.248.44]
Content-Type: text/plain; charset="euc-kr"
Content-ID: <245DFF5B68F71C44A2000454473F1D63@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/vnXnw2xfC3mQQHSqRfWJxvoLPCo
Cc: 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>, "secdir@ietf.org" <secdir@ietf.org>
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 17:15:25 -0000

On Jul 8, 2014, at 9:17 AM, Koodli, Rajeev <rajeev.koodli@intel.com>; wrote:

> 
> 
> 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…”
> 

[Joe] Is the attribute in question protected by AT_MAC?  If not, its possible that it could be modified in transit.  

> -Rajeev
> 
> 
> 
>> 
>> 	Cheers Leif
>> 
> 
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview