Subject: [HOKEY] WGLC on draft-ietf-hokey-erp-aak

From: Glen Zorn <[email-masked]>
Date: Wed, 04 May 2011 18:45:08 +0700

This message announces the beginning of Working Group Last Call on
draft-ietf-hokey-erp-aak-04
(http://datatracker.ietf.org/doc/draft-ietf-hokey-erp-aak/).  The last
call period will last 2 weeks and end at noon (12:00 UTC) on 18 May
2011.  Please review the document and reply to this message with any
comments, leaving the Subject: line intact.  Thank you.

---

From: Qin Wu <[email-masked]>
Date: Tue, 10 May 2011 11:35:35 +0800

Hi,
I read and support this work forward. 
Here is my comments belows:
1. Abstract
[Qin]: The abstract is too long. I suggest to change from
"
   The Extensible Authentication Protocol (EAP) is a generic framework
   supporting multiple of authentication methods.

   The EAP Re-authentication Protocol (ERP) specifies extensions to EAP
   and the EAP keying hierarchy to support an EAP method-independent
   protocol for efficient re-authentication between the peer and an EAP
   re-authentication server through any authenticator.

   Authenticated Anticipatory Keying (AAK) is a method by which
   cryptographic keying material may be established prior to handover
   upon one or more candidate attachment points (CAPs).  AAK uses the
   AAA infrastructure for key transport.

   This document specifies the extensions necessary to enable AAK
   support in ERP.
"
to
"
   Authenticated Anticipatory Keying (AAK) is a method by which
   cryptographic keying material may be established prior to handover
   upon one or more candidate attachment points (CAPs).  AAK uses the
   AAA infrastructure for key transport.

   This document specifies the extensions necessary to enable AAK
   support in ERP.
"
Section 4 First Paragraph
"
   As an optimization of ERP, ERP/AAK uses key hierarchy similar to that
  of ERP.  
"
 [Qin]: Suggest to change "optimization" as "extension".

Section 4 Fist paragraph:
"
The hierarchy relationship is illustrated in Figure 2, below.
"
[Qin]: suggestion to change as:
"
The hierarchy relationship is illustrated in Figure 2 shown below.
"
Section 4 Second Paragraph:
"
If the peer has previously authenticated by means of ERP or ERP/AAK,
the DSRK SHOULD be directly re-used.
"
[Qin]: Suggest change "previously authenticated" as "previously been authenticated"

Section 5.2 
"
   SEQ

   A 16-bit sequence number is used for replay protection.

   Sequence number: It is carried in a TV payload.  The Type is TBD
   (which is lower than 128).  It is used in the derivation of the pMSK
   for each CAP to avoid multiple CAP using the same pMSK.  Each NAS-
   Identifier in the packet MUST be associated with a unique sequence
   number.
"
[Qin]: What's the difference between SEQ field defined in figure 5 and Sequence number TLV?
   I assume the sequence number is used to derive pMSK for CAP while SEQ is used by SAP for replay protection.
   It should be clear in the text. I suggest to change the text for SEQ from
   "
   A 16-bit sequence number is used for replay protection.
   "
   to
   "
   A 16-bit sequence number is used by SAP for replay protection.
   The SEQ number field is initialized to 0 every time a new pRK is
   derived.
   "
Section 5.3 
"
      List of Cryptosuites: This is a sub-TLV payload.  The Type is TBD.
      The value field contains a list of cryptosuites, each 1 octet in
      length.  The allowed cryptosuite values are as specified in
      Section 5.2, above.  The server SHOULD include this attribute if
      the cryptosuite used in the EAP-Initiate/Re-auth message was not
      acceptable and the message is being rejected.  The server MAY
      include this attribute in other cases.  The server MAY use this
      attribute to signal to the peer about its cryptographic algorithm
      capabilities.
"
   [Qin]: Do we really need a new type for Cryptosuites?
Can we reuse the Ctryptosuites used for ERP?

Section 7 last setence:
   [Qin]: Remove the last sentence since we can resue the extisting AAA message.
Section 8 the 5th bullet:
"
   o  Authenticate all parties: The EAP Re-auth Protocol provides mutual
      authentication of the peer and the server.  The peer and SAP are
      authenticated via ERP.  The CAP is authenticated and trusted by
      the SAP.
"
      [Qin]: we are assuming there is trust relationship between SAP and CAP.
      Suggest to change from
      "
      The peer and SAP are
      authenticated via ERP.  The CAP is authenticated and trusted by
      the SAP.

      "
      to 
      "
      The peer and SAP are
      authenticated via ERP.  The CAP is authenticated and trusted by
      the Server.

      "
Regards!
-Qin
----- Original Message ----- 
From: "Glen Zorn" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Wednesday, May 04, 2011 7:45 PM
Subject: [HOKEY] WGLC on draft-ietf-hokey-erp-aak

> comments, leaving the Subject: line intact.  Thank you.

--------------------------------------------------------------------------------

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

---

From: Glen Zorn <[email-masked]>
Date: Sun, 15 May 2011 13:28:14 +0700

>    This document specifies the extensions necessary to enable AAK

Actually, I don't think that the Abstract is too long at all.

>  [Qin]: Suggest to change "optimization" as "extension".

Agree, & also change "uses key" to "uses a key"

> The hierarchy relationship is illustrated in Figure 2 shown below.

Why?

...

>    [Qin]: Remove the last sentence since we can resue the extisting AAA message.

What message did you have in mind?  I can't think of any that do what is
necessary.

...

---

From: Qin Wu <[email-masked]>
Date: Mon, 16 May 2011 11:08:56 +0800

Hi,
----- Original Message ----- 
From: "Glen Zorn" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Sunday, May 15, 2011 2:28 PM
Subject: Re: [HOKEY] WGLC on draft-ietf-hokey-erp-aak

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

[Qin]: I just assume all the people who read this document are all familiar with EAP and ERP.
Maybe I am wrong.

> Agree, & also change "uses key" to "uses a key"

[Qin]: Yes. Good catch.

>> The hierarchy relationship is illustrated in Figure 2 shown below.

[Qin]: I agree existing text is identical to proposed change, maybe not necessary to take new.

> What message did you have in mind?  I can't think of any that do what is

[Qin]: I think Diameter DEA/DER message can be reused. You don't think so?

> ...
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iQEcBAEBAgAGBQJNz3J+AAoJEG4XtfZZU7RfheYIAIFhMJ6tP0cf+WZLzMeZML2b
> AO9yhaqbouCCxpCdXUGHLwrTOtyKEyXrXA62ZUHfh2LtKbR1B/K7SCp/nW3e2hEk
> ewItOuyfGEgQN4KoPQhL9FakfVPQFezEKse3TdwV4x7v9/foASV8U5CW0wFXI5sj
> UZColU5PtvKEGRK7/yUcxDie9kA0xwCPsrLzxdRfdnQjMBGuOmexwK4fpe9i4K7d
> ZVyVs9ey7DEgujFmOJ7OnBIiTC6OnarXkWelN3cvliGtjNekc/VM55J7tqUWqcRl
> 6R0RvRe/ok20X8DseuWl2aLFKA8A7QvES0LzecblHSnw8auN/OGUIpFqRhJ2EvA=
> =N0xC
> -----END PGP SIGNATURE-----
>

---

From: Glen Zorn <[email-masked]>
Date: Mon, 16 May 2011 14:32:46 +0700

On 5/16/2011 10:08 AM, Qin Wu wrote:

...

>> [Qin]: I think Diameter DEA/DER message can be reused. You don't think so?

For the response to the SAP (which seems to be missing from the
protocol, BTW: How does the peer know whether or not the domain in which
the CAP resides supports ERP-AAK or not?  It seems like a fair amount of
time could be saved with a confirmation before movement), yes, I think
so.  However a the Diameter peer will not be expecting a DEA containing
the new keying material.  I suppose that we could rework the DER/DEA
messages so that the DER came from the Diameter "server", though.

---

From: Qin Wu <[email-masked]>
Date: Mon, 16 May 2011 16:22:06 +0800

Hi,
----- Original Message ----- 
From: "Glen Zorn" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, May 16, 2011 3:32 PM
Subject: Re: [HOKEY] WGLC on draft-ietf-hokey-erp-aak

> messages so that the DER came from the Diameter "server", though.

[Qin]: I think you are talking about capability negotation.
I assume Diameter Server has the knowledge if the CAP support ERP-AAK.
In this case, the Diameter Server can tell the peer if the CAP support ERP-AAK
by sending EAP-Finish.
If Diameter Server doesn't know if the CAP support ERP-AAK, AAA exchange for 
capablity negotiation between Diameter Server and CAP is required.
Another possible way is through authenticator discovery. The peer can know both CAPs and 
whether these CAPs support ERP-AAK.

---

From: Glen Zorn <[email-masked]>
Date: Tue, 17 May 2011 13:40:26 +0700

The last call period ends at noon (12:00 UTC) on 18 May
2011 (in less than 36 hours).  PLEASE review the document and reply to
this message with any
comments, leaving the Subject: line intact.  Thank you.

---

From: Glen Zorn <[email-masked]>
Date: Wed, 25 May 2011 09:38:25 +0700

On 5/4/2011 6:45 PM, Glen Zorn wrote:

As mentioned below, the Working Group Last Call on the ERP-AAK draft
ended on May 18th.  Unfortunately, I don't believe that it can be
characterized as successful: there were only a couple of comments and
those came from co-authors of the draft.  I guess that we can wait
awhile and try again; maybe people will be more willing to devote a
little time & energy later.