Subject: [BEHAVE] [Technical Errata Reported] RFC5389 (3327)

From: RFC Errata System <[email-masked]>
Date: Mon, 20 Aug 2012 11:24:08 -0700 (PDT)

The following errata report has been submitted for RFC5389,
"Session Traversal Utilities for NAT (STUN)".

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

--------------------------------------
Type: Technical
Reported by: Todd Herman <[email-masked]>

Section: 15.3

Original Text
-------------
   The USERNAME attribute is used for message integrity.  It identifies
   the username and password combination used in the message-integrity
   check.

Corrected Text
--------------

Notes
-----
There is no explanation or description as to where this "password" comes from.  The statement indicates that the password is also part of the username field but that may not actually be true according to additional research I conducted and other portions of the specification.

If the password is part of this field than it should be explicitly noted how the two values are concatenated.  If this is not accurate, than the "and password combination" portion should be removed.

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. 

--------------------------------------
RFC5389 (draft-ietf-behave-rfc3489bis-18)
--------------------------------------
Title               : Session Traversal Utilities for NAT (STUN)
Publication Date    : October 2008
Author(s)           : J. Rosenberg, R. Mahy, P. Matthews, D. Wing
Category            : PROPOSED STANDARD
Source              : Behavior Engineering for Hindrance Avoidance
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

---

From: Simon Perreault <[email-masked]>
Date: Mon, 20 Aug 2012 14:30:43 -0400

Isn't it clearly spelled out in section 10?

As an implementer I fail to see what the problem is.

Simon

Le 20/08/2012 2:24 PM, RFC Errata System a écrit :
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 20 Aug 2012 11:43:12 -0700

On 08/20/2012 11:24 AM, RFC Errata System wrote:
> 
> The following errata report has been submitted for RFC5389, "Session 
> Traversal Utilities for NAT (STUN)".
> 
> -------------------------------------- You may review the report below and
>  at: http://www.rfc-editor.org/errata_search.php?rfc=5389&eid=3327
> 
> -------------------------------------- Type: Technical Reported by: Todd 
> Herman <[email-masked]>
> 
> Section: 15.3
> 
> Original Text ------------- The USERNAME attribute is used for message 
> integrity.  It identifies the username and password combination used in the
> message-integrity check.
> 
> Corrected Text --------------
> 
> 
> Notes ----- There is no explanation or description as to where this 
> "password" comes from.  The statement indicates that the password is also 
> part of the username field but that may not actually be true according to 
> additional research I conducted and other portions of the specification.
> 
> If the password is part of this field than it should be explicitly noted 
> how the two values are concatenated.  If this is not accurate, than the 
> "and password combination" portion should be removed.
> 

Why didn't you sent an email to the authors or to the behave mailing-list
before polluting the Errata database?

The statement does *not* indicate that the password is part of the username
field, just that the username field *identifies* the password (as in "querying
a database" or "searching in an hash map").

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 20 Aug 2012 13:46:06 -0700

On 08/20/2012 01:25 PM, Todd Herman wrote:
>> -----Original Message----- From: Marc Petit-Huguenin
>> [mailto:[email-masked]] Sent: Monday, August 20, 2012 2:43 PM To:
>> [email-masked] Cc: [email-masked] Subject: Re: [BEHAVE] [Technical
>> Errata Reported] RFC5389 (3327)
>> 
> 
>>>> -------------------------------------- You may review the report
>>>> below and at:
>>>> -------------------------------------- Type: Technical Reported by: 
>>>> Todd Herman <[email-masked]>
>>>> 
>>>> Section: 15.3
>>>> 
>>>> Original Text ------------- The USERNAME attribute is used for
>>>> message integrity.  It identifies the username and password
>>>> combination used in the message-integrity check.
>>>> 
>>>> "password" comes from.  The statement indicates that the password is 
>>>> also part of the username field but that may not actually be true 
>>>> according to additional research I conducted and other portions of
>>>> the
> specification.
>>>> 
>>>> If the password is part of this field than it should be explicitly 
>>>> noted how the two values are concatenated.  If this is not accurate, 
>>>> than the "and password combination" portion should be removed.
>>>> 
> 
>> My apologies.  I did not intend to pollute the errata database with such
>> a stupid thing.
> 
> field, just that the username field *identifies* the password (as
>> in
> "querying a database" or "searching in an hash map").
> 
>> I would argue that the statement "It identifies the username and
>> password combination used" can be easily read that the attribute contains
>> both username and password information.  If the intention is that the
>> USERNAME attribute contains only the username the I don't think password
>> should be mentioned here at all as it could lead to confusion.

[The Concise Oxford Dictionary, tenth edition] identify v. (-ies, -ied) 3
(identify someone/thing with) associate someone or something closely with.

I am not a native English speaker, and as an implementer I am also known for
insisting in precision in the language used in RFCs, but I see no ambiguity here.

- -- 
Marc Petit-Huguenin

---

From: Philip Matthews <[email-masked]>
Date: Tue, 21 Aug 2012 17:26:30 -0400

Indeed, the USERNAME attribute contains just the username.
What the text is trying to say is that there could be multiple (username,password) combinations, and that each combination is uniquely identified by the username. That is, one cannot have multiple passwords per username. That is why it says
"It identifies the username and password combination".

- Philip

On 2012-08-20, at 16:28 , Todd Herman wrote:

> It is somewhat spelled out in section 10 and I understand that the USERNAME
> attribute contains the user name.  My point is that since it contains only
> the USERNAME then I feel "password" shouldn't be mentioned in 15.3 as it
> could cause confusion.  The statement in 15.3, "It identifies  the username
> and password" seems contradictory to the other portions of the document
> which seem to imply that the password comes from somewhere else and that the
> USERNAME attribute contains just the user name.
> 
> I apologize for causing issues by submitting this errata.  I will refrain
> from doing so in the future.
> 
>> -----Original Message-----
>> From: Simon Perreault [mailto:[email-masked]]
>> Sent: Monday, August 20, 2012 2:31 PM
>> To: RFC Errata System
>> Cc: [email-masked]; [email-masked]; [email-masked];
>> [email-masked]; [email-masked]; [email-masked];
>> [email-masked]; [email-masked]; [email-masked]
>> Subject: Re: [BEHAVE] [Technical Errata Reported] RFC5389 (3327)
>> 
>>> There is no explanation or description as to where this "password" comes
>> from.  The statement indicates that the password is also part of the
>> username field but that may not actually be true according to additional
>> research I conducted and other portions of the specification.
>>> 
> how
>> the two values are concatenated.  If this is not accurate, than the "and
>> password combination" portion should be removed.
>>> 
>>> Instructions:
>>> -------------
>>> 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.
>>>