RFC Errata
Found 7 records.
Status: Verified (1)
RFC 4282, "The Network Access Identifier", December 2005
Note: This RFC has been obsoleted by RFC 7542
Source of RFC: radext (sec)
Errata ID: 757
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Koch
Date Reported: 2005-12-13
Verifier Name: Dan Romascanu
Date Verified: 2009-09-09
Section 2.6 says:
The BNF of the realm portion allows the realm to begin with a digit, which is not permitted by the BNF described in [RFC1035]. This change was made to reflect current practice; although not permitted by the BNF described in [RFC1035], Fully Qualified Domain Names (FQDNs) such as 3com.com are commonly used and accepted by current software.
It should say:
[not supplied]
Notes:
section 2.6 missed the update of the hostname syntax in
RFC 1123, section 2.1.
RFC 1123 (STD 3) 2.1 allows labels starting with a <digit>
in fully qualified domain names of a host, RFC 1035 (STD 13)
2.3.1 still wants labels starting with a <letter>.
Status: Held for Document Update (1)
RFC 4282, "The Network Access Identifier", December 2005
Note: This RFC has been obsoleted by RFC 7542
Source of RFC: radext (sec)
Errata ID: 816
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-12-18
Held for Document Update by: Dan Romascanu
Unfortunately, the text of that RFC does not fully reflect the
established state of the IETF standards, by referring to obsolete
documents (e.g., ex STD 10, RFC 821) and ignoring effective updates,
e.g., STD 3, RFC 1123, and RFC 2821.
In particular, the text of RFC 4282 repeatedly (e.g. in Section
2.6.) emphasizes making a deviation from established standards
for host / domain names.
This is not true!
The pretended deviation in fact reflects the current standards.
The modification to RFC 952, RFC 821, et al. has already been
introduced into the IETF Standards by STD 3, RFC 1123 (Host
Requirements, Part II), published 16 years ago, in October 1989.
Section 2.1 of that RFC, on page 13, says:
"One aspect of host name syntax is hereby changed: the
restriction on the first character is relaxed to allow
either a letter or a digit. Host software MUST support
this more liberal syntax."
and continues saying:
"Host software MUST handle host names of up to 63 characters
and SHOULD handle host names of up to 255 characters."
Therefore, it would have been strongly advisable to point out
on page 6 of RFC 4282, in Section 2.2, first bullet, that the
named rules in RFC 2865 **DO NOT CONFORM** with STD 3 !!!
Note: IMHO, it is a fundamental design flaw of RADIUS and certain
other protocols using TLVs, AVPs, -- or however similar protocol
objects are named -- to specify that the 'length' information
(being stored in a single octet) is to comprise the cumulative
size of the Type, Length and Value fields, instead of just giving
the size of the Value (payload) field; the latter solution would
always allow to fully exhaust the total range of an 8-bit unsigned
Length and thereby allow payload octet strings of size 0..255 !
Similarly, RFC 4282 ignores the standardization state of the
proprietary historic tunnelling protocols that have served as
'precursors with major deficiencies to learn from' for the
development of L2TP, the only comparable protocol named in
RFC 4282 that is on the IETF Standards Track.
o L2F [RFC2341] has been published for information only
as a Historic RFC 'ab initio'.
o PPTP [RFC2637] has purposely been rejected by the IETF --
because of its well known significant security flaws, among
other issues, and the Informational RFC 2637 has been
published with a very clear IESG Note to this end.
I am surprised that a new Standards Track RFC is getting published
that repeatedly refers to obsolete protocols equally as to official
protocols, in a manner that does not make clear the distinction.
The continued unreflected use of PPTP, in particular, is seen by
major security consultants as 'one of the most widespread trojan
horses' in the current Internet. We should do everything to
communicate and emphasize the 1998/1999 decisions of the IETF and
IESG and the reasons behind it, and push the evolved standards!
It should say:
[see above]
Notes:
from pending
Status: Rejected (5)
RFC 4282, "The Network Access Identifier", December 2005
Note: This RFC has been obsoleted by RFC 7542
Source of RFC: radext (sec)
Errata ID: 753
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2006-08-14
Rejected by: Dan Romascanu
Date Rejected: 2010-11-03
Section 2.1 says:
c =/ %x80-FF ; UTF-8-Octet allowed (not in RFC 2486)
; Where UTF-8-octet is any octet in the
; multi-octet UTF-8 representation of a
; unicode codepoint above %x7F.
; Note that c must also satisfy rules in
; Section 2.4, including, for instance,
; checking that no prohibited output is
; used (see also Section 2.3 of
; [RFC4013]).
x = %x00-FF ; all 128 ASCII characters, no exception;
; as well as all UTF-8-octets as defined
; above (this was not allowed in
; RFC 2486). Note that x must nevertheless
; again satisfy the Section 2.4 rules.
It should say:
[see below]
Notes:
Shouldn't that be s/FF/F4/ as in STD 63, or maybe s/FF/FD/ ?
--VERIFIER NOTES--
There is no clear suggested change. The chairs are aware about issues with RFC 4282, and believe that a new document is probably required to address them.
Errata ID: 1623
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2008-12-01
Rejected by: Dan Romascanu
Date Rejected: 2009-02-05
Section 2.1 says:
realm = 1*( label "." ) label
It should say:
realm = *( label "." ) label
Notes:
The ABNF for realm forces the inclusion of two labels, which is not consistent with RFC 1034, which allows just one:
<subdomain> ::= <label> | <subdomain> "." <label>
--VERIFIER NOTES--
Not allowing single-label realms was a deliberate decision (and the examples of invalid NAIs in Section 2.8 also include this case). One of the reasons was that RFC 1034 considers names without dots to be "relative" names of local significance. Such names may be valid DNS names for some other purposes than NAIs, though.
Errata ID: 1848
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2009-09-08
Rejected by: Dan Romascanu
Date Rejected: 2010-05-10
Section 2.4 says:
o Normalization requirements, as specified in Section 2.2 of
[RFC4013], are also designed to assist in comparisons.
It should say:
o Normalization is, in general, a bad idea.
Notes:
Much of RFC 4282 is simply wrong.
Normalization can be done only when both the local and character set information is included with the text. And that information is not included with the username or realm.
In addition, not all systems will treat "User" the same as "user". The decision about how to
compare user names is site specific. User name comparisons SHOULD NOT be performed on
any system other than the final one that performs user authentication.
--VERIFIER NOTES--
The suggested change is rather abrupt and should be discussed with the WG as part of a possible revision of the document.
Errata ID: 1849
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2009-09-08
Rejected by: Dan Romascanu
Date Rejected: 2010-05-10
Section 2.4 says:
o Bidirectional characters are handled as specified in Section 2.4
of [RFC4013].
It should say:
o Bidrectional characters are handled in a site-specific fashion
Notes:
The rules in [4013] have shortcomings. Updates are in:
http://tools.ietf.org/html/draft-ietf-idnabis-bidi-05
--VERIFIER NOTES--
The suggested change is rather abrupt and should be discussed with the WG as part of a possible revision of the document.
Errata ID: 1850
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2009-09-08
Rejected by: Dan Romascanu
Date Rejected: 2010-05-10
Section 2.4 says:
o Unassigned code points are specified in Section 2.5 of [RFC4013].
The use of unassigned code points is prohibited.
It should say:
o Unassigned code points MUST be ignored
Notes:
Unassigned code points sometimes go through a process called "assignment". This means that they suddenly become valid.
Implementations that forbid unassigned code points will not be updated when the standards change to assign them. Therefore, they should ignore unassigned code points.
Happily, this is what all implementations do.
--VERIFIER NOTES--
The suggested change should be discussed with the WG as part of a possible revision of the document.