Subject: [Nea] [Technical Errata Reported] RFC5793 (2848)

From: RFC Errata System <[email-masked]>
Date: Tue, 28 Jun 2011 11:43:11 -0700 (PDT)

The following errata report has been submitted for RFC5793,
"PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5793&eid=2848

--------------------------------------
Type: Technical
Reported by: Andreas Steffen <[email-masked]>

Section: 4.8.1

Original Text
-------------
Remediation String (variable length)

      The Remediation String field MUST contain a UTF-8 [6] encoded
      string.  This string contains human-readable instructions for
      remediation that MAY be displayed to the user by the Posture
      Broker Client.  NUL termination MUST NOT be included.  If a
      Posture Broker Client receives a Reason String that does contain a
      NUL termination, it MUST respond with a fatal Invalid Parameter
      error in a CLOSE batch.

Corrected Text
--------------
Remediation String (variable length)

      The Remediation String field MUST contain a UTF-8 [6] encoded
      string.  This string contains human-readable instructions for
      remediation that MAY be displayed to the user by the Posture
      Broker Client.  NUL termination MUST NOT be included.  If a
      Posture Broker Client receives a Remediation String that does contain a
      NUL termination, it MUST respond with a fatal Invalid Parameter
      error in a CLOSE batch.

Notes
-----
Copy-and-paste error: Reason String must be changed to Remediation String.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5793 (draft-ietf-nea-pb-tnc-06)
--------------------------------------
Title               : PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)
Publication Date    : March 2010
Author(s)           : R. Sahita, S. Hanna, R. Hurst, K. Narayan
Category            : PROPOSED STANDARD
Source              : Network Endpoint Assessment
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 30 Jun 2011 10:49:11 -0400

I talked with our ADs about how to handle the errata described
below. We agree that the best thing is to have the NEA WG discuss
it and come to a consensus recommendation on the proper resolution.
If the ADs agree, they'll go ahead and implement our recommendation.

As one of the editors of RFC 5793, I'd say this errata is pretty
obviously correct. The paragraph in question is talking about the
Remediation String. The one occurrence of Reason String in the text
must have been a copy-paste error in the development of the document.

The other thing to consider is whether the errata should be Approved
(and therefore published in the RFC Editor's errata database) or
marked Hold For Document Update (in which case it's simply set aside
for a future revision of this RFC). The criterion to be used here is
whether the issue "could cause implementation or deployment problems
or significant confusion". This is a tougher call but I'd say that
it could cause implementation or deployment problems. If an implementer
reads the erroneous text at face value, he/she would skip the mandatory
NUL terminator check for Remediation String. That could result in
interoperability problems since a NEA Server that sends a NUL
terminator on the Remediation String would work fine with one
NEA Client but not with another. So I think the errata should be
Approved.

Do you agree? Let's see some discussion or simply Agree/Disagree
emails so that we can reach consensus. Susan and I plan to close this
discussion in two weeks (end of July 14) so please respond by then.

BTW, kudos to Andreas for finding and reporting this problem!

Thanks,

Steve

> -----Original Message-----
> From: RFC Errata System [mailto:[email-masked]]
> Sent: Tuesday, June 28, 2011 2:43 PM
> To: [email-masked]; Stephen Hanna; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; Stephen Hanna
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [Technical Errata Reported] RFC5793 (2848)
> 
>

---

From: <[email-masked]>
Date: Thu, 30 Jun 2011 10:10:26 -0500

I agree this is a tougher call on the implementation / deployment issue but this should be made obvious to developers so we remove the potential problem.  I would like to see the errata approved.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee, Inc.
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: Stephen Hanna <[email-masked]<mailto:[email-masked]>>
Date: Thu, 30 Jun 2011 09:49:11 -0500
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Nea] Seeking Consensus on Errata 2848 Against RFC 5793

Thanks,

Steve

-----Original Message-----
From: RFC Errata System [mailto:[email-masked]]
Sent: Tuesday, June 28, 2011 2:43 PM
To: [email-masked]<mailto:[email-masked]>; Stephen Hanna; [email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[email-masked]>; Stephen Hanna
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Technical Errata Reported] RFC5793 (2848)
The following errata report has been submitted for RFC5793,
"PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network
Connect (TNC)".
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5793&eid=2848
--------------------------------------
Type: Technical
Reported by: Andreas Steffen <[email-masked]<mailto:[email-masked]>>
Section: 4.8.1
Original Text
-------------
Remediation String (variable length)
       The Remediation String field MUST contain a UTF-8 [6] encoded
       string.  This string contains human-readable instructions for
       remediation that MAY be displayed to the user by the Posture
       Broker Client.  NUL termination MUST NOT be included.  If a
       Posture Broker Client receives a Reason String that does contain
a
       NUL termination, it MUST respond with a fatal Invalid Parameter
       error in a CLOSE batch.
Corrected Text
--------------
Remediation String (variable length)
       The Remediation String field MUST contain a UTF-8 [6] encoded
       string.  This string contains human-readable instructions for
       remediation that MAY be displayed to the user by the Posture
       Broker Client.  NUL termination MUST NOT be included.  If a
       Posture Broker Client receives a Remediation String that does
contain a
       NUL termination, it MUST respond with a fatal Invalid Parameter
       error in a CLOSE batch.
Notes
-----
Copy-and-paste error: Reason String must be changed to Remediation
String.
Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.
--------------------------------------
RFC5793 (draft-ietf-nea-pb-tnc-06)
--------------------------------------
Title               : PB-TNC: A Posture Broker (PB) Protocol Compatible
with Trusted Network Connect (TNC)
Publication Date    : March 2010
Author(s)           : R. Sahita, S. Hanna, R. Hurst, K. Narayan
Category            : PROPOSED STANDARD
Source              : Network Endpoint Assessment
Area                : Security
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
Nea mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nea

---

From: Ira McDonald <[email-masked]>
Date: Thu, 30 Jun 2011 11:12:00 -0400

Hi,

I agree that the substance of the errata is correct (i.e., a typo
from cut-and-paste).

I agree that it should be Approved - to avoid interoperability
problems.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Chair - TCG Embedded Systems Hardcopy SWG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:[email-masked]
Christmas through April:
  579 Park Place  Saline, MI  48176
  734-944-0094
May to Christmas:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434

On Thu, Jun 30, 2011 at 10:49 AM, Stephen Hanna <[email-masked]> wrote:

> [email-masked]

---

From: Paul Sangster <[email-masked]>
Date: Thu, 30 Jun 2011 08:35:16 -0700

I agree that the proposed change is correct.  I think it is harder to say whether this spec bug would cause interoperability problems if not fixed since its just about how the client handles (errors out) reception of a string without the NUL.

Is there an IETF admin burden to managing the errata database that caused their providing criteria on when something should go into the database vs just holding the comment for update?  I'd personally prefer to see it go into the errata database but don't believe it's clear whether it meets the criteria listed.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stephen Hanna
> Sent: Thursday, June 30, 2011 7:49 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]