BCP195]. Implementations and deployments of a STUN Usage using the long-term credential mechanism (Section 9.2) MUST follow the recommendations in Section 5 of [RFC7616]. Section 13, STUN Usages describe when authentication and message integrity are needed.
Since STUN uses the HMAC of a shared secret for authentication and integrity protection, it is subject to offline dictionary attacks. When authentication is utilized, it SHOULD be with a strong password that is not readily subject to offline dictionary attacks. Protection of the channel itself, using TLS or DTLS, mitigates these attacks. STUN supports both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256, which makes STUN subject to bid-down attacks by an on-path attacker. An attacker could strip the MESSAGE-INTEGRITY-SHA256 attribute, leaving only the MESSAGE-INTEGRITY attribute and thus exploiting a potential vulnerability. Protection of the channel itself, using TLS or DTLS, mitigates these attacks. Timely removal of the support of MESSAGE-INTEGRITY in a future version of STUN is necessary. Note: The use of SHA-256 for password hashing does not meet modern standards, which are aimed at slowing down exhaustive password searches by providing a relatively slow minimum time to compute the hash. Although better algorithms such as Argon2 [Argon2] are available, SHA-256 was chosen for consistency with [RFC7616].
ensuring compatibility with MD5, which was the algorithm used in [RFC5389]. This selection works by having the server send to the client the list of algorithms supported in a PASSWORD-ALGORITHMS attribute and having the client send back a PASSWORD-ALGORITHM attribute containing the algorithm selected. Because the PASSWORD-ALGORITHMS attribute has to be sent in an unauthenticated response, an on-path attacker wanting to exploit an eventual vulnerability in MD5 can just strip the PASSWORD-ALGORITHMS attribute from the unprotected response, thus making the server subsequently act as if the client was implementing the version of this protocol defined in [RFC5389]. To protect against this attack and other similar bid-down attacks, the nonce is enriched with a set of security bits that indicates which security features are in use. In the case of the selection of the password algorithm, the matching bit is set in the nonce returned by the server in the same response that contains the PASSWORD- ALGORITHMS attribute. Because the nonce used in subsequent authenticated transactions is verified by the server to be identical to what was originally sent, it cannot be modified by an on-path attacker. Additionally, the client is mandated to copy the received PASSWORD-ALGORITHMS attribute in the next authenticated transaction to that server. An on-path attack that removes the PASSWORD-ALGORITHMS will be detected because the client will not be able to send it back to the server in the next authenticated transaction. The client will detect that attack because the security bit is set but the matching attribute is missing; this will end the session. A client using an older version of this protocol will not send the PASSWORD-ALGORITHMS back but can only use MD5 anyway, so the attack is inconsequential. The on-path attack may also try to remove the security bit together with the PASSWORD-ALGORITHMS attribute, but the server will discover that when the next authenticated transaction contains an invalid nonce. An on-path attack that removes some algorithms from the PASSWORD- ALGORITHMS attribute will be equally defeated because that attribute will be different from the original one when the server verifies it in the subsequent authenticated transaction. Note that the bid-down protection mechanism introduced in this document is inherently limited by the fact that it is not possible to detect an attack until the server receives the second request after the 401 (Unauthenticated) response.
SHA-256 was chosen as the new default for password hashing for its compatibility with [RFC7616], but because SHA-256 (like MD5) is a comparatively fast algorithm, it does little to deter brute-force attacks. Specifically, this means that if the user has a weak password, an attacker that captures a single exchange can use a brute-force attack to learn the user's password and then potentially impersonate the user to the server and to other servers where the same password was used. Note that such an attacker can impersonate the user to the server itself without any brute-force attack. A stronger (which is to say, slower) algorithm, like Argon2 [Argon2], would help both of these cases; however, in the first case, it would only help after the database entry for this user is updated to exclusively use that stronger mechanism. The bid-down defenses in this protocol prevent an attacker from forcing the client and server to complete a handshake using weaker algorithms than they jointly support, but only if the weakest joint algorithm is strong enough that it cannot be compromised by a brute- force attack. However, this does not defend against many attacks on those algorithms; specifically, an on-path attacker might perform a bid-down attack on a client that supports both Argon2 [Argon2] and SHA-256 for password hashing and use that to collect a MESSAGE- INTEGRITY-SHA256 value that it can then use for an offline brute- force attack. This would be detected when the server receives the second request, but that does not prevent the attacker from obtaining the MESSAGE-INTEGRITY-SHA256 value. Similarly, an attack against the USERHASH mechanism will not succeed in establishing a session as the server will detect that the feature was discarded on path, but the client would still have been convinced to send its username in the clear in the USERNAME attribute, thus disclosing it to the attacker. Finally, when the bid-down protection mechanism is employed for a future upgrade of the HMAC algorithm used to protect messages, it will offer only a limited protection if the current HMAC algorithm is already compromised.
reflexive address is a function of the usage, the applicability and remediation of these attacks are usage-specific. In common situations, modification of the reflexive address by an on-path attacker is easy to do. Consider, for example, the common situation where STUN is run directly over UDP. In this case, an on-path attacker can modify the source IP address of the Binding request before it arrives at the STUN server. The STUN server will then return this IP address in the XOR-MAPPED-ADDRESS attribute to the client and send the response back to that (falsified) IP address and port. If the attacker can also intercept this response, it can direct it back towards the client. Protecting against this attack by using a message-integrity check is impossible, since a message- integrity value cannot cover the source IP address and the intervening NAT must be able to modify this value. Instead, one solution to prevent the attacks listed below is for the client to verify the reflexive address learned, as is done in ICE [RFC8445]. Other usages may use other means to prevent these attacks. Section 16.2.1, this attack is only possible when the attacker is on path for packets sent from the STUN server towards this unused IP address.
after a transition period, a new document updating this one will assign a new STUN Security Feature bit for deprecating HMAC-SHA1. When used, this bit will signal that HMAC-SHA1 is deprecated and should no longer be used. Similarly, if HMAC-SHA256 is found to be compromised, a new userhash attribute and a new STUN Security Feature bit will be allocated in a Standards Track document. The new userhash attribute will have its value computed using a new hash. The STUN Security Feature bit will be used to simultaneously 1) signal to a STUN client using the long- term credential mechanism that this server supports this new hash algorithm for the userhash attribute and 2) prevent bid-down attacks on the new userhash attribute. RFC3424]. STUN can be used to perform this function using a Binding request/ response transaction if one agent is behind a NAT and the other is on the public side of the NAT. The IAB has suggested that protocols developed for this purpose document a specific set of considerations. Because some STUN Usages provide UNSAF functions (such as ICE [RFC8445]) and others do not (such as SIP Outbound [RFC5626]), answers to these considerations need to be addressed by the usages themselves. Section 9.2.1. The initial STUN Security Features are: Bit 0: Password algorithms Bit 1: Username anonymity Bit 2-23: Unassigned
Bits are assigned starting from the most significant side of the bit set, so Bit 0 is the leftmost bit and Bit 23 is the rightmost bit. New Security Features are assigned by Standards Action [RFC8126]. Section 5. STUN methods in the range 0x000-0x07F are assigned by IETF Review [RFC8126]. STUN methods in the range 0x080-0x0FF are assigned by Expert Review [RFC8126]. The responsibility of the expert is to verify that the selected codepoint(s) is not in use and that the request is not for an abnormally large number of codepoints. Technical review of the extension itself is outside the scope of the designated expert responsibility. IANA has updated the name for method 0x002 as described below as well as updated the reference from RFC 5389 to RFC 8489 for the following STUN methods: 0x000: Reserved 0x001: Binding 0x002: Reserved; was SharedSecret prior to [RFC5389] RFC8126]. STUN attribute types in the second half of the comprehension-required range (0x4000-0x7FFF) and in the second half of the comprehension- optional range (0xC000-0xFFFF) are assigned by Expert Review [RFC8126]. The responsibility of the expert is to verify that the selected codepoint(s) are not in use and that the request is not for an abnormally large number of codepoints. Technical review of the extension itself is outside the scope of the designated expert responsibility.
RFC 5389 to RFC 8489 for each the following STUN methods. In addition, [RFC5389] introduced a mistake in the name of attribute 0x0003; [RFC5389] called it CHANGE-ADDRESS when it was actually previously called CHANGE-REQUEST. Thus, IANA has updated the description for 0x0003 to read "Reserved; was CHANGE-REQUEST prior to [RFC5389]". Comprehension-required range (0x0000-0x7FFF): 0x0000: Reserved 0x0001: MAPPED-ADDRESS 0x0002: Reserved; was RESPONSE-ADDRESS prior to [RFC5389] 0x0003: Reserved; was CHANGE-REQUEST prior to [RFC5389] 0x0004: Reserved; was SOURCE-ADDRESS prior to [RFC5389] 0x0005: Reserved; was CHANGED-ADDRESS prior to [RFC5389] 0x0006: USERNAME 0x0007: Reserved; was PASSWORD prior to [RFC5389] 0x0008: MESSAGE-INTEGRITY 0x0009: ERROR-CODE 0x000A: UNKNOWN-ATTRIBUTES 0x000B: Reserved; was REFLECTED-FROM prior to [RFC5389] 0x0014: REALM 0x0015: NONCE 0x0020: XOR-MAPPED-ADDRESS Comprehension-optional range (0x8000-0xFFFF) 0x8022: SOFTWARE 0x8023: ALTERNATE-SERVER 0x8028: FINGERPRINT
RFC3629] that is intended only for human consumption and can be anything appropriate; this document proposes only suggested values. STUN error codes are consistent in codepoint assignments and semantics with SIP [RFC3261] and HTTP [RFC7231]. New STUN error codes are assigned based on IETF Review [RFC8126]. The specification must carefully consider how clients that do not understand this error code will process it before granting the request. See the rules in Section 6.3.4. IANA has updated the reference from RFC 5389 to RFC 8489 for the error codes defined in Section 14.8. IANA has changed the name of the 401 error code from "Unauthorized" to "Unauthenticated". RFC8126]. Password algorithms in the second half of the range (0x8000-0xFFFF) are assigned by Expert Review [RFC8126].
RFC1321]. The key length is 16 bytes, and the parameters value is empty. Note: This algorithm MUST only be used for compatibility with legacy systems. key = MD5(username ":" OpaqueString(realm) ":" OpaqueString(password)) RFC7616]. The key length is 32 bytes, and the parameters value is empty. key = SHA-256(username ":" OpaqueString(realm) ":" OpaqueString(password)) RFC 5389 to RFC 8489 for the following ports in the "Service Name and Transport Protocol Port Number Registry". stun 3478/tcp Session Traversal Utilities for NAT (STUN) port stun 3478/udp Session Traversal Utilities for NAT (STUN) port stuns 5349/tcp Session Traversal Utilities for NAT (STUN) port RFC5389]. This specification differs from RFC 5389 in the following ways: o Added support for DTLS-over-UDP [RFC6347]. o Made clear that the RTO is considered stale if there are no transactions with the server. o Aligned the RTO calculation with [RFC6298]. o Updated the ciphersuites for TLS. o Added support for STUN URI [RFC7064].
o Added support for SHA256 message integrity. o Updated the Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS) support to [RFC8265]. o Added protocol and registry to choose the password encryption algorithm. o Added support for anonymous username. o Added protocol and registry for preventing bid-down attacks. o Specified that sharing a NONCE is no longer permitted. o Added the possibility of using a domain name in the alternate server mechanism. o Added more C snippets. o Added test vector. [ITU.V42.2002] International Telecommunication Union, "Error-correcting procedures for DCEs using asynchronous-to-synchronous conversion", ITU-T Recommendation V.42, March 2002. [KARN87] Karn, P. and C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", SIGCOMM '87, Proceedings of the ACM workshop on Frontiers in computer communications technology, Pages 2-7, DOI 10.1145/55483.55484, August 1987. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>. [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <https://www.rfc-editor.org/info/rfc1123>. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, <https://www.rfc-editor.org/info/rfc1321>. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <https://www.rfc-editor.org/info/rfc2782>. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>. [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/info/rfc5890>. [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>. [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011, <https://www.rfc-editor.org/info/rfc6151>.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-editor.org/info/rfc6298>. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>. [RFC7064] Nandakumar, S., Salgueiro, G., Jones, P., and M. Petit- Huguenin, "URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol", RFC 7064, DOI 10.17487/RFC7064, November 2013, <https://www.rfc-editor.org/info/rfc7064>. [RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350, August 2014, <https://www.rfc-editor.org/info/rfc7350>. [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <https://www.rfc-editor.org/info/rfc7616>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>. [RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", RFC 8265, DOI 10.17487/RFC8265, October 2017, <https://www.rfc-editor.org/info/rfc8265>. [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, <https://www.rfc-editor.org/info/rfc8305>.
[Argon2] Biryukov, A., Dinu, D., Khovratovich, D., and S. Josefsson, "The memory-hard Argon2 password hash and proof-of-work function", Work in Progress, draft-irtf- cfrg-argon2-09, November 2019. [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, May 2015, <https://www.rfc-editor.org/info/bcp195>. [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996, <https://www.rfc-editor.org/info/rfc1952>. [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, DOI 10.17487/RFC2279, January 1998, <https://www.rfc-editor.org/info/rfc2279>. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>. [RFC3424] Daigle, L., Ed. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, DOI 10.17487/RFC3424, November 2002, <https://www.rfc-editor.org/info/rfc3424>. [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, DOI 10.17487/RFC3454, December 2002, <https://www.rfc-editor.org/info/rfc3454>. [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, DOI 10.17487/RFC3489, March 2003, <https://www.rfc-editor.org/info/rfc3489>. [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, DOI 10.17487/RFC4013, February 2005, <https://www.rfc-editor.org/info/rfc4013>.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, June 2005, <https://www.rfc-editor.org/info/rfc4107>. [RFC5090] Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D., and W. Beck, "RADIUS Extension for Digest Authentication", RFC 5090, DOI 10.17487/RFC5090, February 2008, <https://www.rfc-editor.org/info/rfc5090>. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <https://www.rfc-editor.org/info/rfc5389>. [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, DOI 10.17487/RFC5626, October 2009, <https://www.rfc-editor.org/info/rfc5626>. [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, DOI 10.17487/RFC5766, April 2010, <https://www.rfc-editor.org/info/rfc5766>. [RFC5769] Denis-Courmont, R., "Test Vectors for Session Traversal Utilities for NAT (STUN)", RFC 5769, DOI 10.17487/RFC5769, April 2010, <https://www.rfc-editor.org/info/rfc5769>. [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)", RFC 5780, DOI 10.17487/RFC5780, May 2010, <https://www.rfc-editor.org/info/rfc5780>. [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, March 2012, <https://www.rfc-editor.org/info/rfc6544>. [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>. [RFC8264] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols", RFC 8264, DOI 10.17487/RFC8264, October 2017, <https://www.rfc-editor.org/info/rfc8264>. [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, <https://www.rfc-editor.org/info/rfc8445>. [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>. [STUN-PMTUD] Petit-Huguenin, M., Salgueiro, G., and F. Garrido, "Packetization Layer Path MTU Discovery (PLMTUD) For UDP Transports Using Session Traversal Utilities for NAT (STUN)", Work in Progress, draft-ietf-tram-stun-pmtud-15, December 2019. [UAX15] Unicode Standard Annex #15, "Unicode Normalization Forms", edited by Mark Davis and Ken Whistler. An integral part of The Unicode Standard, <http://unicode.org/reports/tr15/>.
RFC5769] with MESSAGE-INTEGRITY-SHA256. All the formats and definitions listed in Section 2 of [RFC5769] apply here. 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) 00 01 00 9c 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 e4 68 6c 8f } 0e de b5 90 } 13 e0 70 90 } 01 0a 93 ef } HMAC-SHA256 value cc bc cc 54 } 4c 0a 45 d9 } f8 30 aa 6d } 6f 73 5a 01 } RFC 5389 appeared as follows: The authors would like to thank Cedric Aoun, Pete Cordell, Cullen Jennings, Bob Penfield, Xavier Marjou, Magnus Westerlund, Miguel Garcia, Bruce Lowekamp, and Chris Sullivan for their comments, and Baruch Sterman and Alan Hawrylyshen for initial implementations. Thanks for Leslie Daigle, Allison Mankin, Eric Rescorla, and Henning Schulzrinne for IESG and IAB input on this work. RFC 3489.
http://www.jdrosen.net Dan Wing Citrix Systems, Inc. United States of America Email: email@example.com Rohan Mahy Unaffiliated Email: firstname.lastname@example.org Philip Matthews Nokia 600 March Road Ottawa, Ontario K2K 2T6 Canada Phone: 613-784-3139 Email: email@example.com