EAP Extensions for the EAP Re-authentication Protocol (ERP)
draft-ietf-hokey-rfc5296bis-07

[Ballot comment]
Thank you for addressing the issues in my previous Discuss position.

Figures 9 and 10 contain minor typos, including the capitalization
of "cryptosuite" and missing " " (space characters) that affect
the alignment of the ASCII-art.

[Ballot comment]
[Updated 17 May 2012, to clear my DISCUSS after the posting of -07.]

Glen,
Thanks for including my text for the IANA Considerations; I'm clearing my DISCUSS.

In section 10, I would have thought
  s/insisted/stamped his foot petulantly and insisted/
so thanks for your restraint.  In any case, I'm happy to stand behind what's in section 9.

In section 11, the backhanded compliment to your colleagues, "(mostly)", is quite unnecessary.

[Ballot comment]
You also need to get a correct email address for Yang Shi, or perhaps remove him from the author list (you can put him in a "Contributors" section or in A.2).  Email to the address in the document is bouncing, and this will cause you a problem during AUTH48.  (If you can't fix the address and need/want to leave him in the author list, the AD can handle this during AUTH48, so it's not a disaster.)

And you might want to take a look at A.2 and make sure you think it's complete.  I see at least two mailing-list messages where Qin Wu acknowledges useful comments from Sebastien, for example.  Up to you, of course; I'm just setting a flag.

[Ballot discuss]
[Updated 20 Apr to include suggested text, and to add non-blocking comments below.]

This document says there are no IANA actions.

RFC 5296 did a number of things in the EAP registry
- Registered Packet Codes 5 and 6
- Created the Message Types table
- Created the Initiate and Finish Attributes table
- Created the Re-authentication Cryptosuites table

It also registered two values in the USRK Key Labels registry.
The references in those IANA registries should now all be changed to point to this new RFC, instead of the now-obsolete 5296.  The following text is a suggested change to the IANA Considerations section that will satisfy this.  It changes the references, and also makes it clear where to find the technical documentation for each registered item.

-----------------------------------------
9. IANA Considerations

This document replaces and obsoletes RFC 5296 [RFC5296], and IANA is
asked to change all registered references to that document to point
instead to this document.
[RFC Editor note: please remove the previous paragraph on publication.]

The previous version of this document performed the following IANA
actions:

1. It registered Packet Codes "Initiate" and "Finish" in the EAP
  Registry.  Those are documented throughout this document as
  "EAP-Initiate" and "EAP-Finish".

2. It created a Message Types table in the EAP Registry, and registered
  several items in that table.  Those are documented throughout this
  document as "Re-auth-start" and "Re-auth".

3. It created an EAP Initiate and Finish Attributes table in the EAP
  registry, and registered several items in that table.  Those are
  documented in this document in Section 5.3.4.

4. It created a Re-authentication Cryptosuites table in the EAP
  registry, and registered several items in that table.  Those are
  documented in this document at the end of Section 5.3.2.

5. It registered two items in the USRK Key Labels registry:

  - Re-auth usage label "EAP Re-authentication Root Key@ietf.org",
    documented in this document in Section 4.1

  - DSRK-authorized delivery key "DSRK Delivery Authorized
    Key@ietf.org", documented in this document in the description of
    "Authorization Indication" in Section 5.3.3

[Ballot discuss]
[Updated 20 Apr to include suggested text, and to add non-blocking comments below.]

This document says there are no IANA actions.

RFC 5296 did a number of things in the EAP registry
- Registered Packet Codes 5 and 6
- Created the Message Types table
- Created the Initiate and Finish Attributes table
- Created the Re-authentication Cryptosuites table

It also registered two values in the USRK Key Labels registry.
The references in those IANA registries should now all be changed to point to this new RFC, instead of the now-obsolete 5296.  The following text is a suggested change to the IANA Considerations section that will satisfy this.  It changes the references, and also makes it clear where to find the technical documentation for each registered item.

------------------------------------------------------------------------------
9. IANA Considerations

This document replaces and obsoletes RFC 5296 [RFC5296], and IANA is asked
to change all registered references to that document to point instead to
this document.
[RFC Editor note: please remove the previous paragraph on publication.]

The previous version of this document performed the following IANA
actions:

1. It registered Packet Codes "Initiate" and "Finish" in the EAP Registry.
  Those are documented throughout this document as "EAP-Initiate" and
  "EAP-Finish".

2. It created a Message Types table in the EAP Registry, and registered
  several items in that table.  Those are documented throughout this
  document as "Re-auth-start" and "Re-auth".

3. It created an EAP Initiate and Finish Attributes table in the EAP registry,
  and registered several items in that table.  Those are documented in this
  document in Section 5.3.4.

4. It created a Re-authentication Cryptosuites table in the EAP registry, and
  registered several items in that table.  Those are documented in this
  document at the end of Section 5.3.2.

5. It registered two items in the USRK Key Labels registry:

  - Re-auth usage label "EAP Re-authentication Root Key@ietf.org", documented
    in this document in Section 4.1

  - DSRK-authorized delivery key "DSRK Delivery Authorized Key@ietf.org",
    documented in this document in the description of "Authorization
    Indication" in Section 5.3.3
------------------------------------------------------------------------------

[Ballot discuss]
This document says there are no IANA actions.

RFC 5296 did a number of things in the EAP registry
- Registered Packet Codes 5 and 6
- Created the Message Types table
- Created the Initiate and Finish Attributes table
- Created the Re-authentication Cryptosuites table

It also registered two values in the USRK Key Labels registry.
The references in those IANA registries should now all be changed to point to this new RFC, instead of the now-obsolete 5296.  The following text is a suggested change to the IANA Considerations section that will satisfy this.  It changes the references, and also makes it clear where to find the technical documentation for each registered item.

------------------------------------------------------------------------------
9. IANA Considerations

This document replaces and obsoletes RFC 5296 [RFC5296], and IANA is asked
to change all registered references to that document to point instead to
this document.
[RFC Editor note: please remove the previous paragraph on publication.]

The previous version of this document performed the following IANA
actions:

1. It registered Packet Codes "Initiate" and "Finish" in the EAP Registry.
  Those are documented throughout this document as "EAP-Initiate" and
  "EAP-Finish".

2. It created a Message Types table in the EAP Registry, and registered
  several items in that table.  Those are documented throughout this
  document as "Re-auth-start" and "Re-auth".

3. It created an EAP Initiate and Finish Attributes table in the EAP registry,
  and registered several items in that table.  Those are documented in this
  document in Section 5.3.4.

4. It created a Re-authentication Cryptosuites table in the EAP registry, and
  registered several items in that table.  Those are documented in this
  document at the end of Section 5.3.2.

5. It registered two items in the USRK Key Labels registry:

  - Re-auth usage label "EAP Re-authentication Root Key@ietf.org", documented
    in this document in Section 4.1

  - DSRK-authorized delivery key "DSRK Delivery Authorized Key@ietf.org",
    documented in this document in the description of "Authorization
    Indication" in Section 5.3.3
------------------------------------------------------------------------------

[Ballot comment]
You also need to get a correct email address for Yang Shi, or perhaps remove him from the author list (you can put him in a "Contributors" section or in A.2).  Email to the address in the document is bouncing, and this will cause you a problem during AUTH48.  (If you can't fix the address and need/want to leave him in the author list, the AD can handle this during AUTH48, so it's not a disaster.)

You also might want to take a look at A.2 and make sure you think it's complete.  I see at least two mailing-list messages when Qin Wu acknowledges useful comments from Sebastien, for example.  Up to you, of course; I'm just setting a flag.

[Ballot discuss]
This DISCUSS is raised against the publication status of the
document.  No action is required from the authors until it is
resolved.  I expect to clear this DISCUSS after the telechat
discussion of the document.

The relationship between this document and RFC 5296, and the exact
status of RFC 5296 should be clarified before this document is
published.  I've given an editorial example of the nature of the
problem in my COMMENTs. 

Adrian has entered a COMMENT that I will expand to a DISCUSS to
request a couple of sentences explaining why this document was
written to accompany the summary of changes Adrian requested.  This
issue might be addressed by the RFC Editor note.

[Ballot comment]
There are at least two instances of references to "new EAP codes" or
"New EAP Packets" that should be updated to reflect that the
EAP-Initiate and EAP-Finish Packet Codes are already defined, and add
a citation to the appropriate IANA registry.

This typo (missing " " in the line containing "cryptosuite") was
copied forward from RFC 5296 (best read with fixed-width font):

    0                  1                  2                  3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    Code      |  Identifier  |            Length            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    Type      |R|B|L| Reserved|            SEQ              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                1 or more TVs or TLVs                        ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | cryptosuite  |        Authentication Tag                    ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[Ballot comment]
Pedantic nits:

4.1 (and similarly in 4.3 and 4.6):

  The rIK Label is the 8-bit ASCII string:

What is an "8-bit ASCII string"? Do you mean "the following string of US-ASCII characters encoded in octets" or something like that?

5.2 (also 5.3.2 and 5.3.3):

      a 16-bit sequence number

Any issue about byte order or sign/unsigned with these?

5.3.3:

        The value
        field is a 32-bit field and contains the lifetime of the [...] in
        seconds.
       
Again, any issue with byte order or sign/unsigned with these?

[Ballot discuss]
This document says there are no IANA actions.

RFC 5296 did a number of things in the EAP registry
- Registered Packet Codes 5 and 6
- Created the Message Types table
- Created the Initiate and Finish Attributes table
- Created the Re-authentication Cryptosuites table

It also registered two values in the USRK Key Labels registry.
Shouldn't the references in those IANA registries now all be changed to point to this new RFC, instead of the now-obsolete 5296?

[Ballot comment]
I have no objection to thepublication of this document.

Please supply a short section "Changes from RFC 5296"

Pleasecheck that all Erratahave also been applied to this revision
http://www.rfc-editor.org/errata_search.php?rfc=5296

State changed to In Last Call from Last Call Requested

The following Last Call Announcement was sent out:

From: The IESG

To: IETF-Announce

CC:

Reply-To: ietf@ietf.org

Subject: Last Call:  (EAP Extensions for EAP Re-authentication Protocol (ERP)) to Proposed Standard





The IESG has received a request from the Handover Keying WG (hokey) to

consider the following document:

- 'EAP Extensions for EAP Re-authentication Protocol (ERP)'

  as a Proposed Standard



The IESG plans to make a decision in the next few weeks, and solicits

final comments on this action. Please send substantive comments to the

ietf@ietf.org mailing lists by 2012-03-12. Exceptionally, comments may be

sent to iesg@ietf.org instead. In either case, please retain the

beginning of the Subject line to allow automated sorting.



Abstract





  The Extensible Authentication Protocol (EAP) is a generic framework

  supporting multiple types of authentication methods.  In systems

  where EAP is used for authentication, it is desirable to avoid

  repeating the entire EAP exchange with another authenticator.  This

  document 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.  The re-authentication server may be in

  the home network or in the local network to which the peer is

  connecting.



  This memo obsoletes RFC 5296.







The file can be obtained via

http://datatracker.ietf.org/doc/draft-ietf-hokey-rfc5296bis/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-hokey-rfc5296bis/ballot/



This draft will be updated to actually include a reference to

RFC 5296 (its sort of, but not quite, there now) and fix a

couple of outdated references.



The following IPR Declarations may be related to this I-D:



  http://datatracker.ietf.org/ipr/1694/