RFC Errata
RFC 4187, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", January 2006
Source of RFC: IETF - NON WORKING GROUPArea Assignment: int
See Also: RFC 4187 w/ inline errata
Errata ID: 966
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-26
Verifier Name: Henry Haverinen
Date Verified: 2006-12-01
Section 12.7 says:
As described in Section 8, EAP-AKA allows the protocol to be extended by defining new attribute types. When defining such attributes, it should be noted that any extra attributes included in EAP-Request/AKA-Identity or EAP-Response/AKA-Identity packets are not included in the MACs later on, and thus some other precautions must be taken to avoid modifications to them.
It should say:
As described in Section 8, EAP-AKA allows the protocol to be extended by defining new attribute types. When defining such attributes, it should be noted that the AT_CHECKCODE attribute (see Section 10.13) can be used to achieve the protection of extra attributes included in EAP-Request/AKA-Identity or EAP-Response/AKA-Identity packets.
Notes:
This text is too pessimistic. The reader's attention should be
directed to Section 10.13 of the RFC. The (late) introduction of
the AT_CHECKCODE concept, as explained there, has taken care of
this issue; implementations should make use of this attribute.
from pending