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

[Qin Wu <[e-mail]>]

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


>> Section 3.1.2 "Minimized User Interaction for authorization"
>> [Z]: This section seems redundant since the previous section has
>> already cover this case. 
> 
> Is that really so, though?  Minimizing the communication with home
> servers doesn't seem to imply minimizing user interaction to me, but
> maybe I'm wrong.

[Qin]: You are not wrong, one use case is in AAK, SAP communicate with the client on one side,
while SAP interaction with the AAA on the other side. With this case, we can
see minimizing the SAP communcation with the home servers does not means minimizing user interaction
between the SAP and the client.
I remember in the meeting, it is suggested to change 
"Minimized User Interaction for authorization"
into
"Minimized User Interaction for authentication"

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


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