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

[Leif Johansson <[e-mail]>]

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" <[e-mail]> 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.
> 

Thx

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