RFC Errata
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).