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

[Qin Wu <[e-mail]>]

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" <[e-mail]>
To: <[e-mail]>rg>; <[e-mail]>
Sent: Wednesday, May 04, 2011 7:45 PM
Subject: [HOKEY] WGLC on draft-ietf-hokey-erp-aak


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


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


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