Re: [HOKEY] WGLC on draft-ietf-hokey-arch-design

[Qin Wu <[e-mail]>]

Hi,
----- Original Message ----- 
From: "Glen Zorn" <[e-mail]>
To: "Qin Wu" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, October 04, 2011 5:02 PM
Subject: Re: [HOKEY] WGLC on draft-ietf-hokey-arch-design


> On 9/2/2011 8:59 AM, Qin Wu wrote:
> 
>> H,:
>> ----- Original Message ----- 
>> From: "Glen Zorn" <[e-mail]>
>> To: "Zhen Cao" <[e-mail]>
>> Cc: <[e-mail]>
>> Sent: Thursday, September 01, 2011 7:48 PM
>> Subject: Re: [HOKEY] WGLC on draft-ietf-hokey-arch-design
>> 
>> 
>>> On 8/10/2011 10:38 AM, Zhen Cao wrote:
>>>> I have read the latest (draft-ietf-hokey-arch-design) version of this
>>>> draft and think it is ready for publication. However I have some
>>>> additional comments to this draft below:
>>>> Section 1, It said
>>>> "
>>>> whereas in AAK the client interacts with the AAA to discover and
>>>> connect to CAPs.
>>>> "
>>>> [Z]: How to understand "discover"? It seems for AAK, there are
>>>> potentially two possible cases.
>>>> case 1: the client has already discovered a list of CAPs and negotiate
>>>> with the AAA to choose one appropriate CAP from the CAPs list.
>>>> case 2: the client only knows a layer-2 identifier as index and then
>>>> the client use index to lookup appropirate CAP by interacting with the
>>>> AAA. which case is correct?
>> 
>> [Qin]: My understanding is ,in AAK, SAP is capable of discovering CAPs 
>> and is not necessary to rely on client based CAP discovery.
>> 
>>> I think that the text regarding AAK in Section 1 is seriously flawed.
>>> It says:
>>>
>>>   Early authentication includes direct
>>>   and indirect pre-authentication as well as Authenticated Anticipatory
>>>   Keying (AKK).  All three mechanisms provide means to execute a full
>>>   EAP authentication with a Candidate Access Point (CAP) while still
>>>   being connected to the Serving Access Point (SAP) but vary in their
>>>   respective system assumptions and communication paths.  In
>>>   particular, direct pre-authentication assumes that clients are
>>>   capable of discovering candidate access points and all communications
>>>   are routed through the serving access point.  On the other hand,
>>>   indirect pre-authentication assumes an existing relationship between
>>>   SAP and CAP, whereas in AAK the client interacts with the AAA to
>>>   discover and connect to CAPs.
>>>
>>> However, RFC 5836 says (about AAK):
>>>
>>> 6.2.  The Authenticated Anticipatory Keying Usage Model
>>>
>>>   In this model, it is assumed that there is no trust relationship
>>>   between the SAP and the CAP, and the SAP is required to interact with
>>>   the AAA server directly.  The authenticated anticipatory keying usage
>>>   model is illustrated in Figure 6.
>>>
>>>     Mobile            Serving               AAA Server      Candidate
>>>     Device        Attachment Point                          Attachment
>>>                        (SAP)                                Point (CAP)
>>>   +---------+   +------------------+   +-----------------+  +--------+
>>>   |         |   |                  |   |                 |  |        |
>>>   |  Peer   |   |   Authenticator  |   |   EAP Server    |  |  AAA   |
>>>   |         |   |                  |   |                 |  | Client |
>>>   +---------+   +------------------+   +-----------------+  +--------+
>>>   |  MD-SA  |<->|  MD-SAP |SAP-AAA |<->|SAP-AAA |CAP-AAA |<>|CAP-AAA |
>>>   +---------+   +------------------+   +--------+--------+  +--------+
>>>   {------------------------------Signaling---------------------------}
>>>
>>>          Figure 6: Authenticated Anticipatory Keying Usage Model
>>>
>>>   The SAP is involved in EAP authenticated anticipatory keying
>>>   signaling.
>>>
>>>   The role of the serving attachment point in this usage model is to
>>>   communicate with the peer on one side and exchange authenticated
>>>   anticipatory keying signaling with the EAP server on the other side.
>>>   The role of the candidate authenticator is to receive the transported
>>>   keying materials from the EAP server and to act as the serving
>>>   attachment point after handover occurs.  The MD-SAP signaling is
>>>   performed over L2 or L3; the SAP-AAA and AAA-CAP segments operate
>>>   over L3.
>>>
>>> So, the AAK client doesn't interact with AAA for any purpose (being an
>>> EAP entity, how could it?) & furthermore, AAK doesn't necessarily
>>> require a full EAP authentication at all (see ERP-AAK).  I think that
>>> this needs to be rewritten; any suggestions for text?
>> 
>> [Qin]: You are right, to get consistent with what it said in RFC5836, 
>> suggest to change the original text as
>> "
>>    Early authentication includes direct
>>    and indirect pre-authentication as well as Authenticated Anticipatory
>>    Keying (AKK).  All three mechanisms provide means to execute a full
>>    EAP authentication with a Candidate Access Point (CAP) while still
>>    being connected to the Serving Access Point (SAP) but vary in their
>>    respective system assumptions and communication paths.  In
>>    particular, direct pre-authentication assumes that clients are
>>    capable of discovering candidate access points and all communications
>>    are routed through the serving access point.  On the other hand,
>>    indirect pre-authentication assumes an existing relationship between
>>    SAP and CAP, whereas in AAK the SAP does not rely on an existing 
>>   relationship between SAP and CAP to interact with the AAA and the AAA
>>   discover and connect to CAPs through this interaction.
>> "
> 
> If CAP discovery is actually outside the scope of AAK, how about we just
> say that?  For example, something like this:
> 
>   Early authentication includes direct
>   and indirect pre-authentication as well as Authenticated Anticipatory
>   Keying (AAK).  All three mechanisms provide means to execute a full
>   EAP authentication with a Candidate Access Point (CAP) while still
>   being connected to the Serving Access Point (SAP) but vary in their
>   respective system assumptions and communication paths.  In
>   particular, direct pre-authentication assumes that clients are
>   capable of discovering candidate access points and all communications
>   are routed through the serving access point.  On the other hand,
>   indirect pre-authentication assumes an existing relationship between
>   SAP and CAP, whereas the discovery of Candidate Access Points is
>   outside the scope of AAK.

[Qin]: Looks good to me, thank for your proposal.

> ...
> 
>>>> Suggest to merge section 3.1.2 into section
>>>> 3.1.1 or just delete the section 3.1.2.
>>>>
>>>> Section 6:
>>>> [Z]:In Quebec meeting, the case where multiple servers are located in
>>>> the same domain has been
>>>> well discussed. I am thinking if this case should be taken into
>>>> account in this section or leave
>>>> this case out of scope of hokey architecture?
>>>
>>> I was going to suggest putting it into the AAA considerations section
>>> but their doesn't seem to be one ;-).
>> 
>> [Qin]: I thought multiple servers cases is relevant to ERP and should be 
>> discussed in RFC5296bis document. It is not good to discuss the same issue
>> in both two documents. Am I wrong?
> 
> It's not good if the two discussions are different ;-), but if they are
> substantially the same, I think it's OK.

[Qin]: Agree.

> ...
> _______________________________________________
> HOKEY mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hokey
>