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

"Koodli, Rajeev" <rajeev.koodli@intel.com> Tue, 08 July 2014 22:20 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 8E55D1A015B; Tue, 8 Jul 2014 15:20:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.552
X-Spam-Level:
X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OcEKc3mrEEBI; Tue, 8 Jul 2014 15:20:07 -0700 (PDT)
Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by ietfa.amsl.com (Postfix) with ESMTP id E34121A015F; Tue, 8 Jul 2014 15:20:06 -0700 (PDT)
Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 08 Jul 2014 15:20:06 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.01,628,1400050800"; d="scan'208";a="454662192"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34]) by azsmga001.ch.intel.com with ESMTP; 08 Jul 2014 15:20:05 -0700
Received: from fmsmsx158.amr.corp.intel.com (10.18.116.75) by FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 8 Jul 2014 15:20:05 -0700
Received: from fmsmsx105.amr.corp.intel.com ([169.254.5.225]) by fmsmsx158.amr.corp.intel.com ([169.254.15.197]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 15:20:05 -0700
From: "Koodli, Rajeev" <rajeev.koodli@intel.com>
To: Leif Johansson <leifj@sunet.se>, "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
Thread-Topic: [secdir] secdir review odraft-ietf-netext-wifi-epc-eap-attributes
Thread-Index: AQHPmtBxgT3VMa/gaUKZ1gsnr5fLR5uWv+aA
Date: Tue, 8 Jul 2014 22:20:03 +0000
Message-ID: <CFE1BBCA.166F%rajeev.koodli@intel.com>
References: <53BA57E3.8080300@sunet.se> <CFE03243.1594%rajeev.koodli@intel.com> <53BBF2A5.10506@sunet.se> <CFE160D4.1613%rajeev.koodli@intel.com> <298C55D6-7F96-4BB5-9313-BA02A2B4D2F2@cisco.com> <53BC2779.70506@sunet.se>
In-Reply-To: <53BC2779.70506@sunet.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.24.71.30]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <5790423FF246AD4D87F014D21CEB4CF4@intel.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/SkWxq715AyXZrgSR0XNWI6PWYGU
Cc: "draft-ietf-netext-wifi-epc-eap-attributes.all@tools.ietf.org" <draft-ietf-netext-wifi-epc-eap-attributes.all@tools.ietf.org>, IESG <iesg@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 22:20:08 -0000

RFC 4187:

"8.2 Protocol Extensibility

   EAP-AKA can be extended by specifying new attribute types.  If
   skippable attributes are used, it is possible to extend the protocol
   without breaking old implementations.  As specified in Section 10.13,
   if new attributes are specified for EAP-Request/AKA-Identity or
   EAP-Response/AKA-Identity, then the AT_CHECKCODE MUST be used to
   integrity protect the new attributes.²


So, this applies for the attribute in question.

-Rajeev



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

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