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

[Tina TSOU <[e-mail]>]

Hi,
We need an AAA consideration section.

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Glen Zorn
Sent: Thursday, September 01, 2011 4:48 AM
To: Zhen Cao
Cc: [e-mail]
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?

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?

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

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

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