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

From: Glen Zorn <[email-masked]>
Date: Thu, 01 Sep 2011 18:48:25 +0700

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

...

---

From: Tina TSOU <[email-masked]>
Date: Thu, 01 Sep 2011 16:00:52 +0000

Hi,
We need an AAA consideration section.

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Glen Zorn
Sent: Thursday, September 01, 2011 4:48 AM
To: Zhen Cao
Cc: [email-masked]
Subject: Re: [HOKEY] WGLC on draft-ietf-hokey-arch-design

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

---

From: Qin Wu <[email-masked]>
Date: Fri, 02 Sep 2011 09:59:58 +0800

H,:
----- Original Message ----- 
From: "Glen Zorn" <[email-masked]>
To: "Zhen Cao" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, September 01, 2011 7:48 PM
Subject: Re: [HOKEY] WGLC on draft-ietf-hokey-arch-design

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

>     Device        Attachment Point                          Attachment

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

> servers doesn't seem to imply minimizing user interaction to me, but

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

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

---

From: Glen Zorn <[email-masked]>
Date: Sun, 04 Sep 2011 15:58:49 +0700

> and is not necessary to rely on client based CAP discovery.

Actually, I think that CAP discovery is completely out of the scope of
hokey; what might be in scope would be the nature of the data that is
obtained as a result of discovery (name, address, etc.) but that may not
belong in this document.

...

> "Minimized User Interaction for authentication"

Yes, that's been fixed in the newest version, I think.

> in both two documents. Am I wrong?

I tend to agree with you.

...

---

From: Qin Wu <[email-masked]>
Date: Mon, 05 Sep 2011 09:34:40 +0800

----- Original Message ----- 
From: "Glen Zorn" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Zhen Cao" <[email-masked]>; <[email-masked]>
Sent: Sunday, September 04, 2011 4:58 PM
Subject: Re: [HOKEY] WGLC on draft-ietf-hokey-arch-design

> obtained as a result of discovery (name, address, etc.) but that may not

[Qin]:Yes, as decribed in RFC5836, CAP discovery is defined as a separate protocol from authentication protocol.
IEEE 802.21 can be candidate protocol to do CAP discovery. Also there are some other ways. So I agree
CAP discovery should be left beyond scope of HOkey. 
As for data obtained from discovery, Do you think NAS-Identifier used for carrying CAP identity is irrelevant?

---

From: Qin Wu <[email-masked]>
Date: Mon, 05 Sep 2011 13:38:18 +0800

HI,:
----- Original Message ----- 
From: "Qin Wu" <[email-masked]>
To: "Glen Zorn" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, September 05, 2011 9:34 AM
Subject: Re: [HOKEY] WGLC on draft-ietf-hokey-arch-design

> As for data obtained from discovery, Do you think NAS-Identifier used for carrying CAP identity is irrelevant?

[Qin]: You are right. Both how to use the results of discovery and how to perform discovery are not the focus of 
 Hokey architecute document. But how to use the results of discovery should be dealt with in the ERP-AAK document.