Re: [tram] [Technical Errata Reported] RFC8489 (6268)

[Magnus Westerlund <[e-mail]>]

Hi,

A question here. Is the key used in the MESSAGE-INTEGRITY-SHA256 the MD5 derived
one, or one derived using SHA256? If it is the former, then fine the lets just
add a sentence of clarification as the option exist. But, Jared's previous
comments appear to indicate the the key for the HMAC-SHA256 used in the
intergrity was derived using SHA256. If it is the later, then I don't see any
option than to include the password algorithm attribute and its algorithm
indicator as it is a necessary component to correctly derive the key and thus
being able to verify the MESSAGE-INTEGRITY. 

I am just trying to ensure that the necessary information to be able to take
this as test vector for this specific purpose actually works. But I think it
needs to follow the updated version of STUN this RFC actually describe, not the
old one.

Cheers

Magnus


On Mon, 2020-09-28 at 03:22 -0700, Marc Petit-Huguenin wrote:
> I do not concur.
> 
> Appendix B clearly states that this test vector augments the ones in RFC 5769,
> and RFC 5769 also clearly states in its abstract that "[t]he content of some
> of these [attributes] --  FINGERPRINT, MESSAGE-INTEGRITY, and XOR-MAPPED-
> ADDRESS -- involve binary-logical operations (hashing, xor).  This document
> provides test vectors for those attributes."
> 
> In other words this is not an example of STUN message, but an example of
> attributes encoding, namely USERHASH and MESSAGE-INTEGRITY-SHA256.
> 
> So it does not matter if the message is incorrect, it still fulfills the
> reason it was created which is to show a correct encoding of these
> attributes.  Even the message length errata is not really necessary, as the
> MESSAGE-INTEGRITY-SHA256 was still correct.
> 
> Now there may be a need for a separate document that contains STUN and STUN
> usages call flows, with correctly encoded messages, but that's a completely
> different topic.
> 
> On 9/25/20 12:56 AM, Magnus Westerlund wrote:
> > Hi Jared,
> > 
> > Thanks for the clarification. Section 9.2.3.2. (Subsequent Requests) states
> > 
> > When the client sends a subsequent
> >    request, it MUST include either the USERNAME or USERHASH, REALM,
> >    NONCE, and PASSWORD-ALGORITHM attributes with these cached values.
> > 
> > So my interpretation is that this Binding Request (sub sequent) is lacking
> > the
> > PASSWORD-ALGORITHM attribute. In Section 9.2.4 also states:
> > 
> >       *  If the request contains neither the PASSWORD-ALGORITHMS nor the
> >          PASSWORD-ALGORITHM algorithm, then the request is processed as
> >          though PASSWORD-ALGORITHM were MD5.
> > 
> > I think the discrepancy between the requirement on sending and what to do
> > when
> > receiving the request comes from backwards compatibility. But there are no
> > reason that the B.1 should not contain the mandated PASSWORD-ALGORITHM
> > attribute.
> > 
> > Thus, it looks like the Appendix B.2 initial text should be clarified with:
> > 
> > 1. That this is a subsequent binding request (for context setting). 
> > 2. Make it clear that it is using SHA-256 as password alrgorithm, and thus
> > PASSWORD-ALGORITH: Algorithm = 0x0002 (SHA-256)
> > 3. Update the message and its integrity to contain a PASSWORD-ALGORITHM
> > 
> > Authors, are you concurring?
> > 
> > Cheers
> > 
> > Magnus
> > 
> > 
> > On Wed, 2020-09-23 at 17:58 +0100, RenThraysk wrote:
> > > Hi
> > > 
> > > Apologies for the delay. 
> > > 
> > > Yes, MESSAGE-INTEGRITY-SHA256 and USERHASH both explicitly specify using
> > > SHA256.
> > > However this RFC adds some agility to computing the long term HMAC key
> > > used to
> > > compute the MESSAGE-INTEGRITY-SHA256.
> > > See https://tools.ietf.org/html/rfc8489#section-18.5
> > > 
> > > If using MESSAGE-INTEGRITY-SHA256 implies that the SHA-256 algorithm ( 
> > > https://tools.ietf.org/html/rfc8489#section-18.5.1.2 ) then it's not clear
> > > in
> > > the RFC.
> > > If it doesn't imply how the key is generated then suggest adding following
> > > line to the test vector parameters  
> > > 
> > > "MESSAGE-INTEGRITY-SHA256 long term key algorithm: SHA-256"
> > > 
> > > Jared.
> > > 
> > > 
> > > On Wed, Sep 23, 2020 at 3:18 PM Magnus Westerlund <
> > > [e-mail]> wrote:
> > > > Jared,
> > > > 
> > > > Any follow up on the the below question? I would like to conclude on
> > > > this
> > > > Errata.
> > > > 
> > > > /Magnus
> > > > 
> > > > On Mon, 2020-09-14 at 15:53 +0000, Magnus Westerlund wrote:
> > > > > Hi,
> > > > > 
> > > > > Thanks Marc for the new test vector. 
> > > > > 
> > > > > Thanks Jared for verifying it.
> > > > > 
> > > > > I have updated the Errata with Marc latest test vector. 
> > > > > 
> > 
> > 
https://protect2.fireeye.com/v1/url?k=c2b8810a-9c18434c-c2b8c191-86fc6812c361-deb1c6e569244be5&q=1&e=1eef972f-1e6d-4430-97e5-2b968535970d&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata_search.php%3Feid%3D6268
> > > > > 
> > > > > Please check this.
> > > > > 
> > > > > Jared, I don't understand your request about noting SHA-256 password
> > > > > algorithm.
> > > > > To me it appears very clear in this section and in the message exactly
> > > > 
> > > > what
> > > > > protocol elements are being used. USERHASH and MESSAGE-INTEGRITY-
> > > > > SHA256
> > > > 
> > > > are
> > > > > both
> > > > > clear that they use SHA256. So if you want any change to the note, can
> > > > > you
> > > > > provide what text you propse? 
> > > > > 
> > > > > 
> > > > > B.1.  Sample Request with Long-Term Authentication with MESSAGE-
> > > > >       INTEGRITY-SHA256 and USERHASH
> > > > > 
> > > > >    This request uses the following parameters:
> > > > > 
> > > > >    Username: "<U+30DE><U+30C8><U+30EA><U+30C3><U+30AF><U+30B9>"
> > > > > (without
> > > > >    quotes) unaffected by OpaqueString [RFC8265] processing
> > > > > 
> > > > >    Password: "The<U+00AD>M<U+00AA>tr<U+2168>" and "TheMatrIX" (without
> > > > >    quotes) respectively before and after OpaqueString [RFC8265]
> > > > >    processing
> > > > > 
> > > > >    Nonce: "obMatJos2AAACf//499k954d6OL34oL9FSTvy64sA" (without quotes)
> > > > > 
> > > > >    Realm: "example.org" (without quotes)
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > On Mon, 2020-09-14 at 15:47 +0100, RenThraysk wrote:
> > > > > > Hi
> > > > > > 
> > > > > > Ok, this is using the SHA256 Password Algorithm, so I suggest that
> > > > 
> > > > should be
> > > > > > noted in the errata as part of the parameters listed in B.1
> > > > > > But can now successfully create the test vector from my code.
> > > > > > 
> > > > > > Will open the other 
> > > > > > errata proposing to strike the line about the right to left bit
> > > > 
> > > > ordering.
> > > > > > 
> > > > > > Jared
> > > > > > 
> > > > > > On Mon, Sep 14, 2020 at 2:15 PM Marc Petit-Huguenin <
> > > > 
> > > > [e-mail]
> > > > > > > 
> > > > > > 
> > > > > > wrote:
> > > > > > > After looking at the emails exchanged at that time, the reason the
> > > > > > > userhash
> > > > > > > was different was because we tentatively changed the username
> > > > > > > during
> > > > > > > AUTH48,
> > > > > > > then decided to use the original one, but my code got stuck with
> > > > > > > the
> > > > 
> > > > new
> > > > > > > username.  I updated the code and the test-vector is now:
> > > > > > > 
> > > > > > >       00 01 00 88      Request type and message length
> > > > > > >       21 12 a4 42      Magic cookie
> > > > > > >       78 ad 34 33   }
> > > > > > >       c6 ad 72 c0   }  Transaction ID
> > > > > > >       29 da 41 2e   }
> > > > > > >       00 1e 00 20      USERHASH attribute header
> > > > > > >       4a 3c f3 8f   }
> > > > > > >       ef 69 92 bd   }
> > > > > > >       a9 52 c6 78   }
> > > > > > >       04 17 da 0f   }  Userhash value (32 bytes)
> > > > > > >       24 81 94 15   }
> > > > > > >       56 9e 60 b2   }
> > > > > > >       05 c4 6e 41   }
> > > > > > >       40 7f 17 04   }
> > > > > > >       00 15 00 29      NONCE attribute header
> > > > > > >       6f 62 4d 61   }
> > > > > > >       74 4a 6f 73   }
> > > > > > >       32 41 41 41   }
> > > > > > >       43 66 2f 2f   }
> > > > > > >       34 39 39 6b   }  Nonce value and padding (3 bytes)
> > > > > > >       39 35 34 64   }
> > > > > > >       36 4f 4c 33   }
> > > > > > >       34 6f 4c 39   }
> > > > > > >       46 53 54 76   }
> > > > > > >       79 36 34 73   }
> > > > > > >       41 00 00 00   }
> > > > > > >       00 14 00 0b      REALM attribute header
> > > > > > >       65 78 61 6d   }
> > > > > > >       70 6c 65 2e   }  Realm value (11 bytes) and padding (1 byte)
> > > > > > >       6f 72 67 00   }
> > > > > > >       00 1c 00 20      MESSAGE-INTEGRITY-SHA256 attribute header
> > > > > > >       23 41 12 fb   }
> > > > > > >       d4 e2 7f 98   }
> > > > > > >       3e b4 03 28   }
> > > > > > >       36 f9 98 21   }  HMAC-SHA256 value
> > > > > > >       6f 5b 23 f8   }
> > > > > > >       d9 27 75 3f   }
> > > > > > >       bc 4f 88 2b   }
> > > > > > >       fb df 0d ec   }
> > > > > > > 
> > > > > > > 
> > > > > > > I think that the note in the errata is fine (after updating the
> > > > > > > test-
> > > > > > > vector).
> > > > > > > 
> > > > > > > Let's open a separate errata for the other issue.
> > > > > > > 
> > > > > > > Thanks.
> > > > > > > 
> > > > > > > 
> > > > > > > On 9/7/20 9:21 AM, Marc Petit-Huguenin wrote:
> > > > > > > > Yes, I will provide text.
> > > > > > > > 
> > > > > > > > On 9/7/20 9:13 AM, Magnus Westerlund wrote:
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > I will hold, but please consider if you directly have any text
> > > > > > > > > proposal
> > > > > > > 
> > > > > > > for 
> > > > > > > > > the note part of the errata to explain the changes that are in
> > > > 
> > > > there
> > > > > > > > > and
> > > > > > > 
> > > > > > > if we 
> > > > > > > > > need to change the text above the message itself to clarify
> > > > 
> > > > thingS?
> > > > > > > > > 
> > > > > > > > > Cheers
> > > > > > > > > 
> > > > > > > > > Magnus
> > > > > > > > > 
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Marc Petit-Huguenin <[e-mail]>
> > > > > > > > > > Sent: den 7 september 2020 18:11
> > > > > > > > > > To: RenThraysk <[e-mail]>
> > > > > > > > > > Cc: Magnus Westerlund <[e-mail]>;
> > > > > > > > > > [e-mail]; [e-mail];
> > > > > > > > > > [e-mail]; [e-mail]; Gonzalo
> > > > 
> > > > Camarillo
> > > > > > > > > > <[e-mail]>; [e-mail];
> > > > > > > > > > dwing-
> > > > > > > > > > [e-mail]; [e-mail]; [e-mail]
> > > > > > > > > > Subject: Re: [Technical Errata Reported] RFC8489 (6268)
> > > > > > > > > > 
> > > > > > > > > > That's a good question.  We changed the username after we
> > > > 
> > > > discovered
> > > > > > > 
> > > > > > > that
> > > > > > > > > > the one I used previously was in fact invalid with the new
> > > > 
> > > > PRECIS
> > > > > > > > > > rules,
> > > > > > > 
> > > > > > > but 
> > > > > > > > > > I
> > > > > > > > > > am not sure why the one in the RFC is different.  I'll have
> > > > > > > > > > to
> > > > 
> > > > look
> > > > > > > > > > into
> > > > > > > 
> > > > > > > my
> > > > > > > > > > archives to find exactly what is what, but that will have to
> > > > 
> > > > wait
> > > > > > > > > > until
> > > > > > > 
> > > > > > > next
> > > > > > > > > > Monday morning.
> > > > > > > > > > 
> > > > > > > > > > Meanwhile, Magnus, please hold on the errata modification.
> > > > > > > > > > 
> > > > > > > > > > Thanks.
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > On 9/7/20 8:22 AM, RenThraysk wrote:
> > > > > > > > > > > Hi
> > > > > > > > > > > 
> > > > > > > > > > > Why has the Userhash value changed from the original test
> > > > 
> > > > vector?
> > > > > > > > > > > 
> > > > > > > > > > > Jared
> > > > > > > > > > > 
> > > > > > > > > > > On Mon, Sep 7, 2020 at 3:21 PM Marc Petit-Huguenin
> > > > > > > > > > > <[e-mail]>
> > > > > > > > > > > wrote:
> > > > > > > > > > > 
> > > > > > > > > > > > Hi Magnus,
> > > > > > > > > > > > 
> > > > > > > > > > > > Here's the corrected test-vector:
> > > > > > > > > > > > 
> > > > > > > > > > > > <begins>
> > > > > > > > > > > >       00 01 00 88      Request type and message length
> > > > > > > > > > > >       21 12 a4 42      Magic cookie
> > > > > > > > > > > >       78 ad 34 33   }
> > > > > > > > > > > >       c6 ad 72 c0   }  Transaction ID
> > > > > > > > > > > >       29 da 41 2e   }
> > > > > > > > > > > >       00 1e 00 20      USERHASH attribute header
> > > > > > > > > > > >       63 aa 09 fc   }
> > > > > > > > > > > >       23 81 0a 46   }
> > > > > > > > > > > >       c9 76 e9 59   }
> > > > > > > > > > > >       23 10 ee 1e   }  Userhash value (32 bytes)
> > > > > > > > > > > >       59 b7 06 e1   }
> > > > > > > > > > > >       9d e1 bd 21   }
> > > > > > > > > > > >       a9 f6 f7 40   }
> > > > > > > > > > > >       28 d5 ba 71   }
> > > > > > > > > > > >       00 15 00 29      NONCE attribute header
> > > > > > > > > > > >       6f 62 4d 61   }
> > > > > > > > > > > >       74 4a 6f 73   }
> > > > > > > > > > > >       32 41 41 41   }
> > > > > > > > > > > >       43 66 2f 2f   }
> > > > > > > > > > > >       34 39 39 6b   }  Nonce value and padding (3 bytes)
> > > > > > > > > > > >       39 35 34 64   }
> > > > > > > > > > > >       36 4f 4c 33   }
> > > > > > > > > > > >       34 6f 4c 39   }
> > > > > > > > > > > >       46 53 54 76   }
> > > > > > > > > > > >       79 36 34 73   }
> > > > > > > > > > > >       41 00 00 00   }
> > > > > > > > > > > >       00 14 00 0b      REALM attribute header
> > > > > > > > > > > >       65 78 61 6d   }
> > > > > > > > > > > >       70 6c 65 2e   }  Realm value (11 bytes) and
> > > > > > > > > > > > padding (1
> > > > > > > > > > > > byte)
> > > > > > > > > > > >       6f 72 67 00   }
> > > > > > > > > > > >       00 1c 00 20      MESSAGE-INTEGRITY-SHA256
> > > > > > > > > > > > attribute
> > > > 
> > > > header
> > > > > > > > > > > >       8e 57 3d 97   }
> > > > > > > > > > > >       75 33 21 ae   }
> > > > > > > > > > > >       47 8c b6 a2   }
> > > > > > > > > > > >       7b 8a 6b 3a   }  HMAC-SHA256 value
> > > > > > > > > > > >       89 08 9e e1   }
> > > > > > > > > > > >       5f 62 6b 38   }
> > > > > > > > > > > >       40 9f 48 ed   }
> > > > > > > > > > > >       47 a5 df 57   }
> > > > > > > > > > > > <ends>
> > > > > > > > > > > > 
> > > > > > > > > > > > Thanks.
> > > > > > > > > > > > 
> > > > > > > > > > > > On 9/1/20 4:04 AM, Magnus Westerlund wrote:
> > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I think it is reasonable that we do an RFC Errata for
> > > > > > > > > > > > > this
> > > > > > > > > > > > > error to
> > > > > > > > > > > > 
> > > > > > > > > > > > provide a
> > > > > > > > > > > > > corrected test vector.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I can edit the Errata request to have a different
> > > > > > > > > > > > > text. So
> > > > 
> > > > if
> > > > > > > > > > > > > you
> > > > > > > > > > > > 
> > > > > > > > > > > > authors could
> > > > > > > > > > > > > prepare and review a proposal that fixes this I will
> > > > > > > > > > > > > edit
> > > > 
> > > > and
> > > > > > > 
> > > > > > > approve 
> > > > > > > > > > > > > it.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > So if you can provide the text that goes into the
> > > > > > > > > > > > > three
> > > > 
> > > > parts:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Original Text: (I assume the full message from B.1
> > > > > > > > > > > > > here)
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Corrected Text: Full message with corrected message
> > > > > > > > > > > > > length
> > > > 
> > > > and
> > > > > > > > > > > > 
> > > > > > > > > > > > recomputed Hash
> > > > > > > > > > > > > value.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Notes: If there are any additional that was already
> > > > 
> > > > written
> > > > > > > > > > > > > that you
> > > > > > > > > > > > 
> > > > > > > > > > > > like to
> > > > > > > > > > > > > remark about this error?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Cheers
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Magnus
> > > > > > > > > > > > > 
> > > > > > > > > > > > > On Mon, 2020-08-31 at 17:00 +0000, Gonzalo Salgueiro
> > > > > > > > > > > > > (gsalguei)
> > > > > > > 
> > > > > > > wrote:
> > > > > > > > > > > > > > Hi Magnus -
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Marc responded earlier so you may have missed it.
> > > > > > > > > > > > > > Below
> > > > 
> > > > is
> > > > > > > > > > > > > > his
> > > > > > > > > > 
> > > > > > > > > > response:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > +++++++++++
> > > > > > > > > > > > > > This errata is correct, and there is nobody to blame
> > > > > > > > > > > > > > for
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > mistake
> > > > > > > > > > > > 
> > > > > > > > > > > > but me.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Magnus, how to you want to proceed for the
> > > > > > > > > > > > > > recomputed
> > > > 
> > > > test
> > > > > > > > > > > > > > vector?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Thanks.
> > > > > > > > > > > > > > +++++++++++
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Cheers,
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Gonzalo
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > On Aug 31, 2020, at 11:08 AM, Magnus Westerlund <
> > > > > > > > > > > > > > > [e-mail]> wrote:
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Author's can you please confirm if this is correct
> > > > > > > > > > > > > > > or
> > > > 
> > > > not?
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Cheers
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Magnus
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > On Sun, 2020-08-30 at 08:22 -0700, RFC Errata
> > > > > > > > > > > > > > > System
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > The following errata report has been submitted
> > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > RFC8489,
> > > > > > > > > > > > > > > > "Session Traversal Utilities for NAT (STUN)".
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > --------------------------------------
> > > > > > > > > > > > > > > > You may review the report below and at:
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > 
> > > > https://protect2.fireeye.com/v1/url?k=99260d6d-c786cf2b-99264df6-86fc
> > > > > > > > > > > > 6812c361-2320f3daa9544fe5&q=1&e=c28eb099-e321-4447-80c3-
> > > > > > > > > > 
> > > > > > > > > > 942509fe0974&
> > > > > > > > > > > > u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6268
> > > > > > > > > > > > > > > > --------------------------------------
> > > > > > > > > > > > > > > > Type: Technical
> > > > > > > > > > > > > > > > Reported by: Jared Williams <
> > > > > > > > > > > > > > > > [e-mail]>
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Section: Appendix B.1
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Original Text
> > > > > > > > > > > > > > > > -------------
> > > > > > > > > > > > > > > > 00 01 00 9c      Request type and message length
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Corrected Text
> > > > > > > > > > > > > > > > --------------
> > > > > > > > > > > > > > > > 00 01 00 88      Request type and message length
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Notes
> > > > > > > > > > > > > > > > -----
> > > > > > > > > > > > > > > > The message length in the test vector (9c) is
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > absolute length
> > > > > > > > > > > > > > > > of
> > > > > > > > > > > > 
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > whole
> > > > > > > > > > > > > > > > test vector. However from section 5. STUN
> > > > > > > > > > > > > > > > Message
> > > > > > > > > > > > > > > > Structure
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > "The message length MUST contain the size of the
> > > > 
> > > > message
> > > > > > > > > > > > > > > > in bytes,
> > > > > > > > > > 
> > > > > > > > > > not
> > > > > > > > > > > > > > > >   including the 20-byte STUN header."
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > So the message length in the header should be 20
> > > > 
> > > > less
> > > > > > > > > > > > > > > > than
> > > > > > > > > > > > > > > > absolute
> > > > > > > > > > > > 
> > > > > > > > > > > > length
> > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > the whole message.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > 0x9C - 20, 0x88.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Also the MESSAGE-INTEGRITY-SHA256 HMAC-SHA256
> > > > > > > > > > > > > > > > value
> > > > 
> > > > of
> > > > > > > > > > > > > > > > the
> > > > > > > > > > 
> > > > > > > > > > Test
> > > > > > > > > > > > > > > > Vector will need recomputing.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Instructions:
> > > > > > > > > > > > > > > > -------------
> > > > > > > > > > > > > > > > This erratum 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 can
> > > > > > > > > > > > > > > > log in to change the status and edit the report,
> > > > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > > necessary.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > --------------------------------------
> > > > > > > > > > > > > > > > RFC8489 (draft-ietf-tram-stunbis-21)
> > > > > > > > > > > > > > > > --------------------------------------
> > > > > > > > > > > > > > > > Title               : Session Traversal
> > > > > > > > > > > > > > > > Utilities
> > > > 
> > > > for
> > > > > > > > > > > > > > > > NAT (STUN)
> > > > > > > > > > > > > > > > Publication Date    : February 2020
> > > > > > > > > > > > > > > > Author(s)           : M. Petit-Huguenin, G.
> > > > 
> > > > Salgueiro,
> > > > > > > > > > > > > > > > J.
> > > > > > > 
> > > > > > > Rosenberg,
> > > > > > > > > > > > D.
> > > > > > > > > > > > > > > > Wing,
> > > > > > > > > > > > > > > > R. Mahy, P. Matthews
> > > > > > > > > > > > > > > > Category            : PROPOSED STANDARD
> > > > > > > > > > > > > > > > Source              : TURN Revised and
> > > > > > > > > > > > > > > > Modernized
> > > > > > > > > > > > > > > > Area                : Transport
> > > > > > > > > > > > > > > > Stream              : IETF
> > > > > > > > > > > > > > > > Verifying Party     : IESG
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >  --
> > > > > > > > > > > > > > > Cheers
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Magnus Westerlund
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > > 
> 
> 
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Mobile [phone]
Torshamnsgatan 23           |
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------