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

"Koodli, Rajeev" <> Mon, 07 July 2014 22:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 273991B297C; Mon, 7 Jul 2014 15:51:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.552
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id POdAP6HLYgyv; Mon, 7 Jul 2014 15:51:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4C1C61B2985; Mon, 7 Jul 2014 15:51:24 -0700 (PDT)
Received: from ([]) by with ESMTP; 07 Jul 2014 15:45:52 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.01,621,1400050800"; d="scan'208";a="569635041"
Received: from ([]) by with ESMTP; 07 Jul 2014 15:51:23 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 7 Jul 2014 15:51:22 -0700
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 15:51:23 -0700
From: "Koodli, Rajeev" <>
To: Leif Johansson <>, "" <>, IESG <>, "" <>
Thread-Topic: secdir review odraft-ietf-netext-wifi-epc-eap-attributes
Thread-Index: AQHPmbxSp13TgeTpn02AF6Q7mf9UjZuVOHsA
Date: Mon, 07 Jul 2014 22:51:21 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 07 Jul 2014 15:57:13 -0700
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: Mon, 07 Jul 2014 22:51:32 -0000

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.



>	Cheers Leif