RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 5 records.

Status: Verified (3)

RFC 5296, "EAP Extensions for EAP Re-authentication Protocol (ERP)", August 2008

Note: This RFC has been obsoleted by RFC 6696

Source of RFC: hokey (sec)

Errata ID: 1825
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Glen Zorn
Date Reported: 2009-08-10
Verifier Name: Tim Polk
Date Verified: 2010-07-20

Section 5.1 says:

   We identify two types of bootstrapping for ERP: explicit and implicit
   bootstrapping.  In implicit bootstrapping, the local ER server SHOULD
   include its domain name and SHOULD request the DSRK from the home AAA
   server during the initial EAP exchange, in the AAA message
   encapsulating the first EAP Response message sent by the peer.

It should say:

   We identify two types of bootstrapping for ERP: explicit and implicit
   bootstrapping.  In implicit bootstrapping, the local AAA client or agent 
   SHOULD include its domain name and SHOULD request the DSRK from the home AAA
   server in the AAA message encapsulating the first EAP Response message sent
   by the peer during the initial EAP exchange.

Notes:

The local ER server is an ERP entity, incapable of inserting anything into a AAA message; the ER server's purpose is to provide reauthentication services, not to edit AAA messages. Furthermore, the original text requires that the ER server unnecessarily insert itself in the path of EAP messages, slowing the initial authentication.

Errata ID: 1845
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Glen Zorn
Date Reported: 2009-08-31
Verifier Name: Tim Polk
Date Verified: 2010-03-21

Section 2 says:

An ER server is a logical entity; 
the home ER server is located on the same backend authentication 
server as the EAP server in the home domain.  The local ER server 
may not necessarily be a full EAP server.

It should say:

An ER server is a logical entity; 
it may not necessarily be co-located with, or physically part of, 
a full EAP server. 

Notes:

The original text makes two unwarranted assumptions, which the corrected text eliminates. The first assumption is that the EAP server in the home domain is located on a back-end authentication (i.e., AAA) server; the second that the home ERP server is also located there. Neither of these conditions are required and place unnecessary restrictions upon deployment options.

Errata ID: 2856
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Qin Wu
Date Reported: 2011-07-11
Verifier Name: Stephen Farrell
Date Verified: 2011-08-14

Section 5.3.2 says:

The EMSKname is in the username part of the NAI and is encoded in
hexadecimal values.  The EMSKname is 64 bits in length and so the 
username portion takes up 128 octets.

It should say:

The EMSKname is in the username part of the NAI and is encoded in
hexadecimal values.  The EMSKname is 64 bits in length and so the 
username portion takes up 16 octets.

Notes:

Verified after checking with hokey WG.

Status: Held for Document Update (1)

RFC 5296, "EAP Extensions for EAP Re-authentication Protocol (ERP)", August 2008

Note: This RFC has been obsoleted by RFC 6696

Source of RFC: hokey (sec)

Errata ID: 1844
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Glen Zorn
Date Reported: 2009-08-31
Held for Document Update by: Tim Polk

Section 1 says:

The protocol that uses these extensions itself is referred to as 
the EAP Re-authentication Protocol (ERP).  

It should say:

The protocol that uses these extensions is itself referred to as 
the EAP Re-authentication Protocol (ERP).  

Notes:

Original text is awkward.

Status: Rejected (1)

RFC 5296, "EAP Extensions for EAP Re-authentication Protocol (ERP)", August 2008

Note: This RFC has been obsoleted by RFC 6696

Source of RFC: hokey (sec)

Errata ID: 1961
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Glen Zorn
Date Reported: 2009-12-18
Rejected by: Stephen Farrell
Date Rejected: 2012-07-23

Section 10 says:

   Bernard Aboba    , Jari Arkko, Sam Hartman, Russ Housley    , Joe Salowey    ,
   Jesse Walker, Charles Clancy, Michaela Vanderveen, Kedar Gaonkar,
   Parag Agashe, Dinesh Dharmaraju, Pasi Eronen, Dan Harkins    , Yoshi
   Ohba, Glen Zorn, Alan DeKok, Katrin Hoeper, and other participants of
   the HOKEY working group.  The credit for the idea to use EAP-
   Initiate/Re-auth-Start goes to Charles Clancy, and the multiple link-
   layer SAs idea to mitigate the DoS attack goes to Yoshi Ohba.  Katrin
   Hoeper suggested the use of the windowing technique to handle
   multiple simultaneous ER exchanges.  Many thanks to Pasi Eronen for
   the suggestion to use hexadecimal encoding for rIKname when sent as
   part of keyName-NAI field.  Thanks to Bernard Aboba     for suggestions
   in clarifying the EAP lock-step operation, and Joe Salowey     and Glen
   Zorn for help in specifying AAA transport of ERP messages.  Thanks to
   Sam Hartman for the DSRK Authorization Indication mechanism.

It should say:

   Bernard Aboba, Jari Arkko, Sam Hartman, Russ Housley, Joe Salowey,
   Jesse Walker, Charles Clancy, Michaela Vanderveen, Kedar Gaonkar,
   Parag Agashe, Dinesh Dharmaraju, Pasi Eronen, Dan Harkins, Yoshi
   Ohba, Glen Zorn, Alan DeKok, Katrin Hoeper, and other participants of
   the HOKEY working group.  The credit for the idea to use EAP-
   Initiate/Re-auth-Start goes to Charles Clancy, and the multiple link-
   layer SAs idea to mitigate the DoS attack goes to Yoshi Ohba.  Katrin
   Hoeper suggested the use of the windowing technique to handle
   multiple simultaneous ER exchanges.  Many thanks to Pasi Eronen for
   the suggestion to use hexadecimal encoding for rIKname when sent as
   part of keyName-NAI field.  Thanks to Bernard Aboba for suggestions
   in clarifying the EAP lock-step operation, and Joe Salowey and Glen
   Zorn for help in specifying AAA transport of ERP messages.  Thanks to
   Sam Hartman for the DSRK Authorization Indication mechanism.

Notes:

Section is mis-formatted.

--RATIONALE--
The spacing error shown above is not present in the RFC (http://www.rfc-editor.org/rfc/rfc5296.txt).

Report New Errata



Advanced Search