Errata

Status:

Verified

Type:

Editorial

Reported By:

Lev Novikov

Date Reported:

2010-04-08

Verified by:

Danny McPherson

Date Verified:

2010-09-10

Section 4.5.2.2 says:

   Note that if the client has a certificate than SSL-based client
   authentication can be used.  To make this easier, SASL provides the
   EXTERNAL mechanism, whereby the SASL client can tell the server
   "examine the outer channel for my identity".  Obviously, this is not
   subject to the layering attacks described above.

It should say:

   Note that if the client has a certificate then SSL-based client
   authentication can be used.  To make this easier, SASL provides the
   EXTERNAL mechanism, whereby the SASL client can tell the server
   "examine the outer channel for my identity".  Obviously, this is not
   subject to the layering attacks described above.

Notes:

Changed "than" to "then".

Status:

Verified

Type:

Editorial

Reported By:

Glen Zorn

Date Reported:

2010-05-07

Verified by:

Danny McPherson

Date Verified:

2010-09-10

Section 4.5.1 says:

modifying with the kernel or installing new drivers.  

It should say:

modifying the kernel or installing new drivers.  

Notes:

Correct poor grammar.

Status:

Verified

Type:

Editorial

Reported By:

Eliot Lear

Date Reported:

2013-12-09

Verified by:

RFC Editor

Date Verified:

2014-09-03

Section 5 says:

Part of the purpose of the
Security Considerations section is to explain what attacks are out of
scope and what countermeasures can be applied to defend against them.
In

It should say:

Part of the purpose of the Security Considerations section
is to explain what attacks are in and out of scope and what
countermeasures can be applied to defend against them.

Notes:

Note dangling "In".

Not sure if this is exactly what the authors had in mind, and might suggest a more substantial change in a document update.  For the moment I *think* this covers it.

Status:

Verified

Type:

Editorial

Reported By:

Walter Dolce

Date Reported:

2015-12-13

Verified by:

Andrew Sullivan

Date Verified:

2016-01-07

Section 4.2. says:

This problem exists with any negotiation approach, but 
generic frameworks exacerbate it by encouraging the application 
protocol author to just specify the framework rather than think hard 
about the appropriate underlying mechanisms, particularly since the 
mechanisms can very widely in the degree of security offered.

It should say:

This problem exists with any negotiation approach, but 
generic frameworks exacerbate it by encouraging the application 
protocol author to just specify the framework rather than think hard 
about the appropriate underlying mechanisms, particularly since the 
mechanisms can vary widely in the degree of security offered.

Notes:

At the end of the paragraph, I think "very" should be changed to "vary"

Status:

Verified

Type:

Editorial

Reported By:

Pete Jorgensen

Date Reported:

2023-08-19

Verified by:

Mirja Kühlewind

Date Verified:

2024-01-11

Section 3.3.5 says:

Note that it is only necessary to authenticate one side of the
   transaction in order to prevent man-in-the-middle attacks.  In such a
   situation the the peers can establish an association in which only
   one peer is authenticated.  In such a system, an attacker can
   initiate an association posing as the unauthenticated peer but cannot
   transmit or access data being sent on a legitimate connection.  This
   is an acceptable situation in contexts such as Web e-commerce where
   only the server needs to be authenticated (or the client is
   independently authenticated via some non-cryptographic mechanism such
   as a credit card number).

It should say:

Note that it is only necessary to authenticate one side of the
   transaction in order to prevent man-in-the-middle attacks.  In such a
   situation the peers can establish an association in which only
   one peer is authenticated.  In such a system, an attacker can
   initiate an association posing as the unauthenticated peer but cannot
   transmit or access data being sent on a legitimate connection.  This
   is an acceptable situation in contexts such as Web e-commerce where
   only the server needs to be authenticated (or the client is
   independently authenticated via some non-cryptographic mechanism such
   as a credit card number).

Notes:

2nd sentence fix "the the".

Status:

Reported

Type:

Editorial

Reported By:

Brian Carpenter

Date Reported:

2025-10-17

Throughout the document, when it says:

[In the metadata]
<stream>IAB</stream>

It should say:

<stream>IETF</stream>

Notes:

BCPs, by definition, can only be in the IETF Stream. The fact that the IAB is an *author* of this document seems to have confused the RFC Editor when the "stream" metadata was retrofitted to the RFC index, some years after the RFC was published.

Status:

Held for Document Update

Type:

Editorial

Reported By:

James Abley

Date Reported:

2013-03-22

Held for Document Update by:

Russ Housley

Section 3.3.5 says:

Note that it is only necessary to authenticate one side of the 
transaction in order to prevent man-in-the-middle attacks.  In such a
situation the the peers can establish an association in which only
one peer is authenticated.

It should say:

Note that it is only necessary to authenticate one side of the 
transaction in order to prevent man-in-the-middle attacks.  In such a
situation the peers can establish an association in which only
one peer is authenticated.

Notes:

Remove repetition of "the"