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

[Glen Zorn <[e-mail]>]

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.

...

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

...