Session Traversal Utilities for NAT (STUN)
draft-ietf-tram-stunbis-21
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-02-12
|
21 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-07-29
|
21 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-07-12
|
21 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2019-07-10
|
21 | (System) | RFC Editor state changed to EDIT from AUTH |
2019-05-27
|
21 | (System) | RFC Editor state changed to AUTH from EDIT |
2019-05-08
|
21 | Magnus Westerlund | Shepherding AD changed to Magnus Westerlund |
2019-04-02
|
21 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2019-04-01
|
21 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2019-03-28
|
21 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2019-03-28
|
21 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2019-03-28
|
21 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2019-03-28
|
21 | (System) | IANA Action state changed to In Progress from Waiting on WGC |
2019-03-27
|
21 | (System) | IANA Action state changed to Waiting on WGC from In Progress |
2019-03-25
|
21 | (System) | RFC Editor state changed to EDIT |
2019-03-25
|
21 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-03-25
|
21 | (System) | Announcement was received by RFC Editor |
2019-03-23
|
21 | (System) | IANA Action state changed to In Progress |
2019-03-23
|
21 | Cindy Morgan | IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2019-03-23
|
21 | Cindy Morgan | IESG has approved the document |
2019-03-23
|
21 | Cindy Morgan | Closed "Approve" ballot |
2019-03-23
|
21 | Cindy Morgan | Ballot writeup was changed |
2019-03-23
|
21 | Cindy Morgan | Ballot approval text was generated |
2019-03-22
|
21 | Eric Rescorla | [Ballot comment] Thank you for addressing my DISCUSS |
2019-03-22
|
21 | Eric Rescorla | [Ballot Position Update] Position for Eric Rescorla has been changed to No Objection from Discuss |
2019-03-22
|
21 | Cindy Morgan | New version available: draft-ietf-tram-stunbis-21.txt |
2019-03-22
|
21 | (System) | Secretariat manually posting. Approvals already received |
2019-03-22
|
21 | Cindy Morgan | Uploaded new revision |
2019-03-11
|
20 | Gonzalo Salgueiro | New version available: draft-ietf-tram-stunbis-20.txt |
2019-03-11
|
20 | (System) | New version approved |
2019-03-11
|
20 | (System) | Request for posting confirmation emailed to previous authors: Rohan Mahy , Gonzalo Salgueiro , Dan Wing , Marc Petit-Huguenin , Philip Matthews , Jonathan Rosenberg |
2019-03-11
|
20 | Gonzalo Salgueiro | Uploaded new revision |
2018-10-15
|
19 | Marc Petit-Huguenin | New version available: draft-ietf-tram-stunbis-19.txt |
2018-10-15
|
19 | (System) | New version approved |
2018-10-15
|
19 | (System) | Request for posting confirmation emailed to previous authors: Rohan Mahy , Gonzalo Salgueiro , Dan Wing , Marc Petit-Huguenin , Philip Matthews , Jonathan Rosenberg |
2018-10-15
|
19 | Marc Petit-Huguenin | Uploaded new revision |
2018-10-09
|
18 | Adam Roach | [Ballot comment] [Thanks for addressing my DISCUSS -- the original text of my DISCUSS follows] Thanks to everyone who worked on this revision of the … [Ballot comment] [Thanks for addressing my DISCUSS -- the original text of my DISCUSS follows] Thanks to everyone who worked on this revision of the STUN protocol. Thanks in particular to the ARTART reviewer and to the authors for actively engaging on the points he raised. I have one concern about interoperability and another about the IANA changes that I believe require changes to the document prior to publication. §14.2: > X-Port is computed by taking the mapped port in host byte order, > XOR'ing it with the most significant 16 bits of the magic cookie, and > then the converting the result to network byte order. If the IP > address family is IPv4, X-Address is computed by taking the mapped IP > address in host byte order, XOR'ing it with the magic cookie, and > converting the result to network byte order. If the IP address > family is IPv6, X-Address is computed by taking the mapped IP address > in host byte order, XOR'ing it with the concatenation of the magic > cookie and the 96-bit transaction ID, and converting the result to > network byte order. The discussion of performing operations "in host byte order" is very confusing, and seems likely to cause issues communicating between machines of different endianness. As an implementor, based on this description, I cannot tell whether, given a port of 0x1234 (and operating on a little-endian machine), I'm supposed to do: Port (host order): 34 12 Magic Cookie Prefix: 21 12 Result (host order): 15 00 X-Port (net order): 00 15 or: Port (host order): 34 12 Magic Cookie Prefix: 12 21 Result (host order): 26 33 X-Port (net order): 33 26 One of these is clearly wrong. I think it's the first one, but I *also* think that the first one is the most straightforward interpretation of the quoted paragraph. The following would seem to be a complete description of the operation without introducing possible confusion about the difference between host and network order: X-Port is computed by XOR'ing the mapped port with the most significant 16 bits of the magic cookie. If the IP address family is IPv4, X-Address is computed XOR'ing the mapped IP with the magic cookie. If the IP address family is IPv6, X-Address is computed by XOR'ing the mapped IP address with the concatenation of the magic cookie and the 96-bit transaction ID. In all cases, the XOR operation works on its inputs in network byte order (that is, the order they will be encoded in the message). This makes it clear that the proper operation is: Port: 12 34 Magic Cookie Prefix: 21 12 Result / X-Port: 33 26 --------------------------------------------------------------------------- §17.3.1: > IANA is requested to update the names for attributes 0x0002, 0x0003, > 0x0004, 0x0005, 0x0007, and 0x000B, and the reference from RFC 5389 > to RFC-to-be for the following STUN methods: ... > 0x0003: (Reserved; prior to [RFC5389] this was CHANGE-REQUEST) The attribute 0x0003 is registered by RFC 5780, and should not be removed by this document. --------------------------------------------------------------------------- §3: This is almost, but not quite, the boilerplate defined by RFC 8174. Please update to match the text in RFC 8174. --------------------------------------------------------------------------- §5: > server to detect if the client will understand certain attributes > that were added in this revised specification. This is a *bit* misleading, as these attributes were actually added in RFC 5389. Consider: "...that were added to STUN by [RFC5389]." --------------------------------------------------------------------------- §6.1: > If the agent is sending a request, it SHOULD add a SOFTWARE attribute > to the request. I believe this would benefit from a pointer to the security section; e.g.: "Note that the inclusion of a SOFTWARE attribute may have security implications; see Section 15.1.2 for details." --------------------------------------------------------------------------- §6.2: > STUN may be used > with anycast addresses, but only with UDP and in usages where > authentication is not used. This bit of operational advice seems out of place in the middle of an implementation discussion, and is quite likely to be missed by its intended audience. Consider relocating it to an "Operational Considerations" section. --------------------------------------------------------------------------- §6.2.1: > As with TCP, the usage of Karn's > algorithm is RECOMMENDED [KARN87]. This normative language means that [KARN87] needs to be a normative reference. --------------------------------------------------------------------------- §6.2.3 says: > Alternatively, a > client MAY be configured with a set of IP addresses that are trusted; > if a certificate is received that identifies one of those IP > addresses, the client considers the identity of the server to be > verified. Presumably, this means the server supplies a certificate with SubjectAltName containing an iPAddress? Please add text to clarify whether that's the intention. If that *is* the intended meaning, then this behavior in §8.1 seems unnecessarily restrictive: > A "stuns" URI > containing an IP address MUST be rejected, unless the domain name is > provided by the same mechanism that provided the STUN URI, and that > domain name can be passed to the verification code. Presumably, this is done because certs with iPAddress-form SubjectAltNames are pretty rare (although CAB Forum baseline requirements do explicitly allow their issuance) -- but if the text in §6.2.3 is based on allowing the use of such certs in a TURN deployment, then it seems that URI resolution should be also. --------------------------------------------------------------------------- §9.1.3: > If the MESSAGE- > INTEGRITY-SHA256 attribute is not present, and using the same > password, compute the value for the message integrity as described > in Section 14.5. I can't figure out what is meant by "and using the same password" here. The structure of the sentence would imply that the subject of "using" is "attribute" (the one that is not present), but that doesn't make sense. Is it supposed to be something like this? If the MESSAGE-INTEGRITY-SHA256 attribute is not present, compute the value for the message integrity as described in Section 14.5, using the same password as would have been used for MESSAGE-INTEGRITY-SHA256. --------------------------------------------------------------------------- §9.1.5: > A client sending subsequent requests to the same server MUST send > only the MESSAGE-INTEGRITY-SHA256 or the MESSAGE-INTEGRITY attribute > that matches the attribute that was received in the response to the > initial request. How long does it continue to do so? It seems sensible to do this for the length of validity of the credentials (and no longer) -- and probably even scoped to the credentials -- but the document really should call that out explicitly. --------------------------------------------------------------------------- §9.2.2: > The structure of the key when used with long-term credentials > facilitates deployment in systems that also utilize SIP [RFC3261]. > Typically, SIP systems utilizing SIP's digest authentication > mechanism do not actually store the password in the database. > Rather, they store a value called H(A1), which is equal to the key > defined above. Suggest adding something like: "For example, this mechanism can be used with the authentication extensions defined in [RFC5090]." --------------------------------------------------------------------------- §9.2.3.2: > Once a request/response transaction has completed successfully, the The use of "successfully" here is kind of confusing, since the transaction in question was completed with an Error Response. Suggest dropping "successfully". --------------------------------------------------------------------------- §9.2.4: > o If the NONCE is no longer valid, the server MUST generate an error > response with an error code of 438 (Stale Nonce). This response > MUST include NONCE, REALM, and PASSWORD-ALGORITHMS attributes and > SHOULD NOT include the USERNAME, USERHASH attribute, The NONCE > attribute value MUST be valid. Nit: The comma before the final "The" should be a period. --------------------------------------------------------------------------- §9.2.4: > USERHASH attribute. The response MAY include a MESSAGE-INTEGRITY > or MESSAGE-INTEGRITY-SHA256 attribute, using the previous password > to calculate it. I think this means to say "using the previous key," right? --------------------------------------------------------------------------- §14: > The > padding bits are ignored, and may be any value. This seems to be encouraging implementors to use uninitialized memory for these bits, which could be a security issue. It would be far safer to do the more traditional "must be set to zero on sending, must be ignored by receiver" thing here. --------------------------------------------------------------------------- §14.5: > Petit-Huguenin, et al. Expires September 6, 2018 [Page 40] > > Internet-Draft Session Traversal Utilities for NAT (STUN) March 2018 > Similarly, when validating the MESSAGE-INTEGRITY, the length field in This appears to be an errant header/footer pair. Note that the correctly-formatted footer for page 40 appears several paragraphs later. --------------------------------------------------------------------------- §14.7: > The 32-bit CRC is the one defined in ITU V.42 [ITU.V42.2002], which > has a generator polynomial of > x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1. Please correct the polynomial representation: x^32 + x^26 + x^23 + x^22 + x^16 + x^12 + x^11 + x^10 + x^8 + x^7 + x^5 + x^4 + x^2 + x + 1. --------------------------------------------------------------------------- §14.8: > The reason phrase is meant for user consumption This is a very tricky assertion to maintain, unless you want to start working with language tags and reason phrase localization. I think you're far safer saying something like "The reason phrase is meant for diagnostic purposes." I would not encourage implementations to just display its contents to users without any localization discussion. --------------------------------------------------------------------------- §15.2.4: It's probably worth additionally noting that this attack can be trivially launched by the STUN server itself -- so users of STUN servers should have the same level of trust in them as any other node that can insert themselves into the communication flow. --------------------------------------------------------------------------- §15.3: I'm surprised that there is no plan in here for cryptoagility of the USERHASH TLV. While a practical preimage attack on SHA-256 seems pretty implausible today, it would be nice to know that we have a remedy if we ever decide that we need to change things. |
2018-10-09
|
18 | Adam Roach | [Ballot Position Update] Position for Adam Roach has been changed to No Objection from Discuss |
2018-06-12
|
18 | Gunter Van de Velde | Closed request for Telechat review by OPSDIR with state 'No Response' |
2018-05-14
|
18 | Marc Petit-Huguenin | New version available: draft-ietf-tram-stunbis-18.txt |
2018-05-14
|
18 | (System) | New version approved |
2018-05-14
|
18 | (System) | Request for posting confirmation emailed to previous authors: Rohan Mahy , Gonzalo Salgueiro , Dan Wing , Marc Petit-Huguenin , Philip Matthews , Jonathan Rosenberg |
2018-05-14
|
18 | Marc Petit-Huguenin | Uploaded new revision |
2018-05-04
|
17 | Alexey Melnikov | [Ballot comment] Thank you for addressing my DISCUSS points and comments. |
2018-05-04
|
17 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss |
2018-05-03
|
17 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-05-03
|
17 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-05-03
|
17 | Marc Petit-Huguenin | New version available: draft-ietf-tram-stunbis-17.txt |
2018-05-03
|
17 | (System) | New version approved |
2018-05-03
|
17 | (System) | Request for posting confirmation emailed to previous authors: Rohan Mahy , Gonzalo Salgueiro , Dan Wing , Marc Petit-Huguenin , Philip Matthews , Jonathan Rosenberg |
2018-05-03
|
17 | Marc Petit-Huguenin | Uploaded new revision |
2018-04-19
|
16 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2018-04-19
|
16 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2018-04-19
|
16 | Ignas Bagdonas | [Ballot comment] NO RECORD - ran out of time to review this document in detail. |
2018-04-19
|
16 | Ignas Bagdonas | Ballot comment text updated for Ignas Bagdonas |
2018-04-18
|
16 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-04-18
|
16 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-04-18
|
16 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from No Record |
2018-04-18
|
16 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-04-18
|
16 | Benjamin Kaduk | [Ballot comment] I'm balloting No Objection and not DISCUSS because no individual item rises quite to that level of criticality, but there still are quite … [Ballot comment] I'm balloting No Objection and not DISCUSS because no individual item rises quite to that level of criticality, but there still are quite a number of things that ought to be addressed prior to publication. In addition to the excellent points raised in the secdir review (which are mostly addressed but only in the editor's copy?), I would call out a few more key observations: If I understand correctly, the server's PASSWORD-ALGORITHMS array from the response are echoed back by the client in the subsequent request in order to provide downgrade protection -- the initial response is at least sometimes not authenticated, and by having the client repeat it back under an authenticated scheme, the server can detect if the list was tampered to remove any new, stronger, algorithms. This is probably an important enough concept to be called out explicitly, either where the behavior is described or in Section 9.2.1 ("Bid Down Attack Prevention"). Section 8.1 has some text that could be read as requiring a STUN client to implement dual-stack IPv4/IPv6, which presumably is not the intention: In addition, instead of querying either the A or the AAAA resource records for a domain name, the client MUST query both and try the requests with all the IP addresses received, as specified in [RFC8305]. There are still some places where the text talks about MESSAGE-INTEGRITY when it really means "message integrity protection" (i.e., either the SHA1 or SHA-256 variants, for now); I've attempted to note them in the notes below. There is text in both Sections 9.1 and 9.2 that talks of replay protection being provided, by the time-limited nature of the short-term credentials or the nonce for long-term credentials. This seems to only, strictly speaking, be true if any given password/nonce can only be used once, but for the short-term credentials the password is used for the duration of the "session-equivalent", and for the long-term credentials a nonce can be reused for some amount of time as well. So while these are both replay countermeasures that can limit replay attacks, it seems a stretch to claim that they prevent replay attacks (entirely). The Stale Nonce behavior seems potentially worrisome, in that it opens up a side channel for a distinguishing attack, between a 401 and 438 response. (That is, "password correct" vs. "password incorrect".) The impact seems rather muted, though, since the gain to the attacker is to be able to precompute a bunch of requests using a nonce of the attacker's choosing and blindly replay the precomputed object against (possibly multiple) servers looking for a guess. The realm and username are still in play, so the scope for the attacker to gain from the precomputation seems limited. (The same level of brute-force guessing can be obtained "live" just by computing the trial responses against a live server, using a valid nonce.) So, while it might be nice to give guidance that 438 should only be used when the server can validate that it did generate the nonce and the nonce was valid "recently", and to treat other cases as authentication failures, it's not clear to me that there's enough of a benefit from the change to make it worth doing. Section 6.2.3 Maybe just cite BCP 195/RFC 7525 instead of inlining requirements? Also, the "client SHOULD verify ..." and "client MUST verify ..." are similar enough that some clarification of certificate vs. identity verification would be in order, if both statements are believed accurate. Section 6.3 [...] Known-but-unexpected attributes SHOULD be ignored by the agent. [...] Why is this not an error? Section 6.3.1, 6.3.2, etc. Should the second paragraph start with "Otherwise, "? Presumably once an error response is sent or processing ceases, processing stops... Section 8.1 [...] A "stuns" URI containing an IP address MUST be rejected, unless the domain name is provided by the same mechanism that provided the STUN URI, and that domain name can be passed to the verification code. "the verifcation code" is probably unnecessarily vague; we're just talking about the (D)TLS SNI and certifciate verification code, right? Section 9.2 [...[ The nonce provides the replay protection. It is a cookie, selected by the server, and encoded in such a way as to indicate a duration of validity or client identity from which it is valid. Is this like a TLS cookie, where only the server needs to know about the internal structure (viz. "encoded" in the above)? If so, the text could probably be more clear. When mentioning just "a message-integrity", maybe forward-ref both versions of it to be more clear that we don't mean just the old one? It's unclear why indications can't use a nonce, if one is known from a previous request/response on the same connection. When encoding the value of 0 for the security feature, it may be worth clarifying that it is still encoded as a 24-bit integer and base64-encoded, though the "13 character string" text ought to make this clear to the reader. Section 9.2.4 * If the request contains neither PASSWORD-ALGORITHMS nor PASSWORD- ALGORITHM, then the request is processed as though PASSWORD- ALGORITHM were MD5 (Note that if the original PASSWORD-ALGORITHMS attribute did not contain MD5, this will result in a 400 Bad Request in a later step below). This Note seems a bit odd, since we're predicated on PASSWORD-ALGORITHMS being absent. * Otherwise, unless (1) PASSWORD-ALGORITHM and PASSWORD- ALGORITHMS are both present, (2) PASSWORD-ALGORITHMS matches the value sent in the response that sent this NONCE, and (3) PASSWORD-ALGORITHM matches one of the entries in PASSWORD- ALGORITHMS, the server MUST generate an error response with an error code of 400 (Bad Request). Maybe we could be more clear about "the value of the PASSWORD-ALGORITHMS attribute in the message matches the value of the PASSWORD-ALGORITHMS attribute sent in the response that sent the NONCE used with this message"? Section 9.2.5 If the response contains a PASSWORD-ALGORITHMS attribute, the subsequent request MUST be authenticated using MESSAGE-INTEGRITY- SHA256 only. This means "all subsequent requests to this server"? Maybe the wording could be more clear. (It also means that if we get a new scheme when SHA256 is broken, the document introducing it may need to Update this document to remove the MUST.) Also, I think the Security Feature bit is "Password algorithms" plural (in the next paragraph and maybe multiple locations in the document). Section 10 [...] If the transaction uses TLS or DTLS and if the transaction is authenticated by a MESSAGE-INTEGRITY-SHA256 attribute and if the server wants to redirect to a server that uses a different certificate, then it MUST include an ALTERNATE-DOMAIN attribute containing the subjectAltName of that certificate. The (definite article), implying the entire subjectAltName? Or just one name that is contained as a SAN entry? Section 14.8 Need to not just say MESSAGE-INTEGRITY since the SHA256 variant should be fine as well. Section 14.10 Maybe the nonce cookie should get a shout-out here? Section 14.12 Do we need to talk about the padding, since this is the the sole contents of the attribute and the attribute padding suffices? Also, "derive the long-term password" doesn't seem quite right; we're deriving the key from the long-term password, per Section 17.15.1. Section 15.1.2 There is no amplification of the number of packets with this attack (the STUN server sends one packet for each packet sent by the client), though there is a small increase in the amount of data, since STUN responses are typically larger than requests. I usually hear amplification in terms of bytes or bandwidth, not packets. So maybe just "amplification is modest"? Section 15.3 This specification uses both HMAC-SHA1 and HMAC-SHA256 for computation of the message integrity. Could perhaps be reworded, since the number of situations when both are used on the same message is small, and we try to push SHA256 when we can. o STUN Client and Server using the Short Term Credential Mechanism Clients and Servers, plural. Section 17.32. I'm confused why we have MUST-level requirements about using PASSWORD-ALGORITHMS when it is in the comprehension-optional range (e.g., echoing from response to repeated request as in Section 9.2.5). The server cannot actually enforce this MUST when talking to an old client if we want to retain the comprehension-optional semantics, IIUC. Section 17.6 If we're adding support for DTLS-over-udp (per the next section), should we be registering stuns/udp? "password encryption algorithm" is not quite the right statement to make, since we're hashing, not encrypting. |
2018-04-18
|
16 | Benjamin Kaduk | Ballot comment text updated for Benjamin Kaduk |
2018-04-18
|
16 | Eric Rescorla | [Ballot discuss] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D5132 Can you please indicate how you addressed the points Matt Miller raised in his secdir review … [Ballot discuss] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D5132 Can you please indicate how you addressed the points Matt Miller raised in his secdir review about the use of MD5. DETAIL > by the agent sending the indication. It primarily serves to > correlate requests with responses, though it also plays a small role > in helping to prevent certain types of attacks. The server also uses > the transaction ID as a key to identify each transaction uniquely > across all clients. As such, the transaction ID MUST be uniformly > and randomly chosen from the interval 0 .. 2**96-1, and SHOULD be I didn't realize this was a SHOULD. ICE depends on it as a security condition, so it probably needs to be a MUST. > For a request or indication message, the agent MUST include the > USERNAME, MESSAGE-INTEGRITY-SHA256, and MESSAGE-INTEGRITY attributes > in the message unless the agent knows from an external indication > which message integrity algorithm is supported by both agents. In > this case either MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 MUST > be included in addition to USERNAME. The HMAC for the MESSAGE- This text appears to conflict with S 7.3 of 5245-bis, which says that you must have MESSAGE-INTEGRITY. > STUN Security Feature it is understood that the corresponding STUN > Security Feature bit in the "nonce cookie" is set to 1. > > For example, in Section 9.2.4 discussing the PASSWORD-ALGORITHMS > security feature, it is implied that the "Password algorithms" bit, > as defined in Section 17.1, is set to 1 in the "nonce cookie". I'm not sure I understand the bid down attack here or the proposed defense. Can you please walk through what the assumed attacker capabilities are, what the client and server capabilities are, how the bid down attack works, and how this protects against it? |
2018-04-18
|
16 | Eric Rescorla | Ballot discuss text updated for Eric Rescorla |
2018-04-18
|
16 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-04-18
|
16 | Warren Kumari | [Ballot comment] Balloting NoObj, trusting AD. |
2018-04-18
|
16 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2018-04-18
|
16 | Alexey Melnikov | [Ballot discuss] I would like to discuss several issues with the document (which look easy to fix to me) before recommending its approval for publication … [Ballot discuss] I would like to discuss several issues with the document (which look easy to fix to me) before recommending its approval for publication as an RFC: 1) 14.3. USERNAME The USERNAME attribute is used for message integrity. It identifies the username and password combination used in the message-integrity check. The value of USERNAME is a variable-length value containing the authentication username. It MUST contain a UTF-8 [RFC3629] encoded sequence of less than 509 bytes, and MUST have been processed using the OpaqueString profile [RFC8265]. I am trying to understand if there was a particular reason why you didn't use UsernameCasePreserved (or its case insensitive alternative) profile here which was specifically designed for usernames? A compliant implementation MUST be able to parse UTF-8 encoded sequence of less than 763. I am confused by this statement: you already have 509 bytes above. Is "no" missing above? 14.4. USERHASH The USERHASH attribute is used as a replacement for the USERNAME attribute when username anonymity is supported. The value of USERHASH has a fixed length of 32 bytes. The username and the realm MUST have been processed using the OpaqueString profile [RFC8265] before hashing. As above: why didn't you use UsernameCasePreserved profile which was specifically designed for usernames? 2) 14.9. REALM The REALM attribute may be present in requests and responses. It contains text that meets the grammar for "realm-value" as described in [RFC3261] but without the double quotes and their surrounding whitespace. That is, it is an unquoted realm-value (and is therefore a sequence of qdtext or quoted-pair). It MUST be a UTF-8 [RFC3629] encoded sequence of less than 128 characters (which can be as long as 509 bytes when encoding them and a long as 763 bytes when decoding them), (Here and similar text in several other sections) Can you please elaborate on how you came up with values 509 and 763? And why you need more space for decoding than for encoding of UTF-8. and MUST have been processed using the OpaqueString profile [RFC8265]. 3) 14.16. ALTERNATE-DOMAIN The value of ALTERNATE-DOMAIN is variable length. It MUST be a UTF-8 [RFC3629] encoded sequence of less than 128 characters (which can be Ekr already pointed this out, but I want to expand on this: you need to say whether this allows U-label (which are UTF-8) or A-labels (which are ASCII only). If you only allow Punycode encoded A-labels, this field doesn't need to be UTF-8, it only need to be ASCII. As far as I remember ASCII domain names are limited to 255 bytes. as long as 509 bytes when encoding them and as long as 763 bytes when decoding them). 4) 10. ALTERNATE-SERVER Mechanism If the transport protocol uses TLS or DTLS, then the client looks for an ALTERNATE-DOMAIN attribute. If the attribute is found, the domain MUST be used to validate the certificate using the recommendations in [RFC6125]. When you reference RFC 6125 you need to provide more details: a) Are you expecting support for DNS-ID, CN-ID or both? I assume you don't support SRV-ID/URI-ID (saying so explicitly would be great too). b) Are you expected to allow wildcards in DNS-IDs/CN-IDs? If yes, you need to say so. There is one more reference to RFC 6125 in the document, you should make a similar change there as well. |
2018-04-18
|
16 | Alexey Melnikov | [Ballot comment] I am agreeing with DISCUSS/comments from Adam. Additionally, I have the following comments: 9.2.4. Receiving a Request o If the value of … [Ballot comment] I am agreeing with DISCUSS/comments from Adam. Additionally, I have the following comments: 9.2.4. Receiving a Request o If the value of the USERNAME or USERHASH attribute is not valid, the server MUST generate an error response with an error code of 401 (Unauthenticated). This response MUST include a REALM value. It is RECOMMENDED that the REALM value be the domain name of the provider of the STUN server. You include this sentence here and at the beginning of this section, but not above (in at least 2 other places) where REALM is also mentioned? Just mention the advice once earlier in this section? 14.10. NONCE Note that this means that the NONCE attribute will not contain actual the surrounding quote characters. This doesn't look right. Either drop "actual" or move it after "the"? |
2018-04-18
|
16 | Alexey Melnikov | [Ballot Position Update] New position, Discuss, has been recorded for Alexey Melnikov |
2018-04-17
|
16 | Adam Roach | [Ballot discuss] Thanks to everyone who worked on this revision of the STUN protocol. Thanks in particular to the ARTART reviewer and to the authors … [Ballot discuss] Thanks to everyone who worked on this revision of the STUN protocol. Thanks in particular to the ARTART reviewer and to the authors for actively engaging on the points he raised. I have one concern about interoperability and another about the IANA changes that I believe require changes to the document prior to publication. §14.2: > X-Port is computed by taking the mapped port in host byte order, > XOR'ing it with the most significant 16 bits of the magic cookie, and > then the converting the result to network byte order. If the IP > address family is IPv4, X-Address is computed by taking the mapped IP > address in host byte order, XOR'ing it with the magic cookie, and > converting the result to network byte order. If the IP address > family is IPv6, X-Address is computed by taking the mapped IP address > in host byte order, XOR'ing it with the concatenation of the magic > cookie and the 96-bit transaction ID, and converting the result to > network byte order. The discussion of performing operations "in host byte order" is very confusing, and seems likely to cause issues communicating between machines of different endianness. As an implementor, based on this description, I cannot tell whether, given a port of 0x1234 (and operating on a little-endian machine), I'm supposed to do: Port (host order): 34 12 Magic Cookie Prefix: 21 12 Result (host order): 15 00 X-Port (net order): 00 15 or: Port (host order): 34 12 Magic Cookie Prefix: 12 21 Result (host order): 26 33 X-Port (net order): 33 26 One of these is clearly wrong. I think it's the first one, but I *also* think that the first one is the most straightforward interpretation of the quoted paragraph. The following would seem to be a complete description of the operation without introducing possible confusion about the difference between host and network order: X-Port is computed by XOR'ing the mapped port with the most significant 16 bits of the magic cookie. If the IP address family is IPv4, X-Address is computed XOR'ing the mapped IP with the magic cookie. If the IP address family is IPv6, X-Address is computed by XOR'ing the mapped IP address with the concatenation of the magic cookie and the 96-bit transaction ID. In all cases, the XOR operation works on its inputs in network byte order (that is, the order they will be encoded in the message). This makes it clear that the proper operation is: Port: 12 34 Magic Cookie Prefix: 21 12 Result / X-Port: 33 26 --------------------------------------------------------------------------- §17.3.1: > IANA is requested to update the names for attributes 0x0002, 0x0003, > 0x0004, 0x0005, 0x0007, and 0x000B, and the reference from RFC 5389 > to RFC-to-be for the following STUN methods: ... > 0x0003: (Reserved; prior to [RFC5389] this was CHANGE-REQUEST) The attribute 0x0003 is registered by RFC 5780, and should not be removed by this document. |
2018-04-17
|
16 | Adam Roach | [Ballot comment] §3: This is almost, but not quite, the boilerplate defined by RFC 8174. Please update to match the text in RFC 8174 … [Ballot comment] §3: This is almost, but not quite, the boilerplate defined by RFC 8174. Please update to match the text in RFC 8174. --------------------------------------------------------------------------- §5: > server to detect if the client will understand certain attributes > that were added in this revised specification. This is a *bit* misleading, as these attributes were actually added in RFC 5389. Consider: "...that were added to STUN by [RFC5389]." --------------------------------------------------------------------------- §6.1: > If the agent is sending a request, it SHOULD add a SOFTWARE attribute > to the request. I believe this would benefit from a pointer to the security section; e.g.: "Note that the inclusion of a SOFTWARE attribute may have security implications; see Section 15.1.2 for details." --------------------------------------------------------------------------- §6.2: > STUN may be used > with anycast addresses, but only with UDP and in usages where > authentication is not used. This bit of operational advice seems out of place in the middle of an implementation discussion, and is quite likely to be missed by its intended audience. Consider relocating it to an "Operational Considerations" section. --------------------------------------------------------------------------- §6.2.1: > As with TCP, the usage of Karn's > algorithm is RECOMMENDED [KARN87]. This normative language means that [KARN87] needs to be a normative reference. --------------------------------------------------------------------------- §6.2.3 says: > Alternatively, a > client MAY be configured with a set of IP addresses that are trusted; > if a certificate is received that identifies one of those IP > addresses, the client considers the identity of the server to be > verified. Presumably, this means the server supplies a certificate with SubjectAltName containing an iPAddress? Please add text to clarify whether that's the intention. If that *is* the intended meaning, then this behavior in §8.1 seems unnecessarily restrictive: > A "stuns" URI > containing an IP address MUST be rejected, unless the domain name is > provided by the same mechanism that provided the STUN URI, and that > domain name can be passed to the verification code. Presumably, this is done because certs with iPAddress-form SubjectAltNames are pretty rare (although CAB Forum baseline requirements do explicitly allow their issuance) -- but if the text in §6.2.3 is based on allowing the use of such certs in a TURN deployment, then it seems that URI resolution should be also. --------------------------------------------------------------------------- §9.1.3: > If the MESSAGE- > INTEGRITY-SHA256 attribute is not present, and using the same > password, compute the value for the message integrity as described > in Section 14.5. I can't figure out what is meant by "and using the same password" here. The structure of the sentence would imply that the subject of "using" is "attribute" (the one that is not present), but that doesn't make sense. Is it supposed to be something like this? If the MESSAGE-INTEGRITY-SHA256 attribute is not present, compute the value for the message integrity as described in Section 14.5, using the same password as would have been used for MESSAGE-INTEGRITY-SHA256. --------------------------------------------------------------------------- §9.1.5: > A client sending subsequent requests to the same server MUST send > only the MESSAGE-INTEGRITY-SHA256 or the MESSAGE-INTEGRITY attribute > that matches the attribute that was received in the response to the > initial request. How long does it continue to do so? It seems sensible to do this for the length of validity of the credentials (and no longer) -- and probably even scoped to the credentials -- but the document really should call that out explicitly. --------------------------------------------------------------------------- §9.2.2: > The structure of the key when used with long-term credentials > facilitates deployment in systems that also utilize SIP [RFC3261]. > Typically, SIP systems utilizing SIP's digest authentication > mechanism do not actually store the password in the database. > Rather, they store a value called H(A1), which is equal to the key > defined above. Suggest adding something like: "For example, this mechanism can be used with the authentication extensions defined in [RFC5090]." --------------------------------------------------------------------------- §9.2.3.2: > Once a request/response transaction has completed successfully, the The use of "successfully" here is kind of confusing, since the transaction in question was completed with an Error Response. Suggest dropping "successfully". --------------------------------------------------------------------------- §9.2.4: > o If the NONCE is no longer valid, the server MUST generate an error > response with an error code of 438 (Stale Nonce). This response > MUST include NONCE, REALM, and PASSWORD-ALGORITHMS attributes and > SHOULD NOT include the USERNAME, USERHASH attribute, The NONCE > attribute value MUST be valid. Nit: The comma before the final "The" should be a period. --------------------------------------------------------------------------- §9.2.4: > USERHASH attribute. The response MAY include a MESSAGE-INTEGRITY > or MESSAGE-INTEGRITY-SHA256 attribute, using the previous password > to calculate it. I think this means to say "using the previous key," right? --------------------------------------------------------------------------- §14: > The > padding bits are ignored, and may be any value. This seems to be encouraging implementors to use uninitialized memory for these bits, which could be a security issue. It would be far safer to do the more traditional "must be set to zero on sending, must be ignored by receiver" thing here. --------------------------------------------------------------------------- §14.5: > Petit-Huguenin, et al. Expires September 6, 2018 [Page 40] > > Internet-Draft Session Traversal Utilities for NAT (STUN) March 2018 > Similarly, when validating the MESSAGE-INTEGRITY, the length field in This appears to be an errant header/footer pair. Note that the correctly-formatted footer for page 40 appears several paragraphs later. --------------------------------------------------------------------------- §14.7: > The 32-bit CRC is the one defined in ITU V.42 [ITU.V42.2002], which > has a generator polynomial of > x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1. Please correct the polynomial representation: x^32 + x^26 + x^23 + x^22 + x^16 + x^12 + x^11 + x^10 + x^8 + x^7 + x^5 + x^4 + x^2 + x + 1. --------------------------------------------------------------------------- §14.8: > The reason phrase is meant for user consumption This is a very tricky assertion to maintain, unless you want to start working with language tags and reason phrase localization. I think you're far safer saying something like "The reason phrase is meant for diagnostic purposes." I would not encourage implementations to just display its contents to users without any localization discussion. --------------------------------------------------------------------------- §15.2.4: It's probably worth additionally noting that this attack can be trivially launched by the STUN server itself -- so users of STUN servers should have the same level of trust in them as any other node that can insert themselves into the communication flow. --------------------------------------------------------------------------- §15.3: I'm surprised that there is no plan in here for cryptoagility of the USERHASH TLV. While a practical preimage attack on SHA-256 seems pretty implausible today, it would be nice to know that we have a remedy if we ever decide that we need to change things. |
2018-04-17
|
16 | Adam Roach | [Ballot Position Update] New position, Discuss, has been recorded for Adam Roach |
2018-04-16
|
16 | Ben Campbell | [Ballot comment] Hi, thanks for this work. For the record, I have mainly reviewed the diff. General: I think Peter's ART-ART review has some points … [Ballot comment] Hi, thanks for this work. For the record, I have mainly reviewed the diff. General: I think Peter's ART-ART review has some points worth addressing. §1, last paragraph: This seems out of place. Also, I wonder if it should be stated more strongly, perhaps with a SHOULD or even MUST. §3: RFC 8174 offers it's own recommended boilerplate; is there a reason not to use it? §6.2.1, third paragraph: " The value SHOULD be considered stale and discarded after 10 minutes without any transactions to the same server. " This is a bit ambiguous. I think it means the value is stale if no transactions have occurred in the last 10 minutes, But I think it could be read to say that there should be no transactions to the same server once one considers the value as stale. §9.1.4: Does it make sense to signal that "an attack took place" rather than signaling "integrity protection was violated" and let the human operators decide if that implies an attack? §14.3: "A compliant implementation MUST be able to parse UTF-8 encoded sequence of less than 763." 763 whats? §15.3, 2nd bullet: I'm not sure I understand what is meant by "get an updated external mechanism" |
2018-04-16
|
16 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-04-16
|
16 | Eric Rescorla | [Ballot discuss] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D5132 Can you please indicate how you addressed the points Matt Miller raised in his secdir review … [Ballot discuss] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D5132 Can you please indicate how you addressed the points Matt Miller raised in his secdir review about the use of MD5. DETAIL > by the agent sending the indication. It primarily serves to > correlate requests with responses, though it also plays a small role > in helping to prevent certain types of attacks. The server also uses > the transaction ID as a key to identify each transaction uniquely > across all clients. As such, the transaction ID MUST be uniformly > and randomly chosen from the interval 0 .. 2**96-1, and SHOULD be I didn't realize this was a SHOULD. ICE depends on it as a security condition, so it probably needs to be a MUST. > For a request or indication message, the agent MUST include the > USERNAME, MESSAGE-INTEGRITY-SHA256, and MESSAGE-INTEGRITY attributes > in the message unless the agent knows from an external indication > which message integrity algorithm is supported by both agents. In > this case either MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 MUST > be included in addition to USERNAME. The HMAC for the MESSAGE- This text appears to conflict with S 7.3 of 5245-bis, which says: > STUN Security Feature it is understood that the corresponding STUN > Security Feature bit in the "nonce cookie" is set to 1. > > For example, in Section 9.2.4 discussing the PASSWORD-ALGORITHMS > security feature, it is implied that the "Password algorithms" bit, > as defined in Section 17.1, is set to 1 in the "nonce cookie". I'm not sure I understand the bid down attack here or the proposed defense. Can you please walk through what the assumed attacker capabilities are, what the client and server capabilities are, how the bid down attack works, and how this protects against it? |
2018-04-16
|
16 | Eric Rescorla | [Ballot comment] > > In keeping with its tool nature, this specification defines an > extensible packet format, defines operation over … [Ballot comment] > > In keeping with its tool nature, this specification defines an > extensible packet format, defines operation over several transport > protocols, and provides for two forms of authentication. > > STUN is intended to be used in context of one or more NAT traversal Nit: "in the context" > of [RFC0791]. Unless otherwise noted, numeric constants are in > decimal (base 10). > > All STUN messages comprise a 20-byte header followed by zero or more > Attributes. The STUN header contains a STUN message type, magic > cookie, transaction ID, and message length. You might want to list these in order. > The STUN usage must specify which transport protocol is used, and how > the agent determines the IP address and port of the recipient. > Section 8 describes a DNS-based method of determining the IP address > and port of a server that a usage may elect to use. STUN may be used > with anycast addresses, but only with UDP and in usages where > authentication is not used. Why this restriction? You should be able to use anycast with long-term AUTH for (say) TURN. > First, the initial value for RTO SHOULD be greater than 500 ms. The > exception cases for this "SHOULD" are when other mechanisms are used > to derive congestion thresholds (such as the ones defined in ICE for > fixed rate streams), or when STUN is used in non-Internet > environments with known network capacities. In fixed-line access > links, a value of 500 ms is RECOMMENDED. Second, the value of RTO I note that above you say "greater than 500 ms" but here you say "500 ms". Perhaps you mean greater than equal. > transaction over UDP or DTLS-over-UDP is also considered failed if > there has been a hard ICMP error [RFC1122]. For example, assuming an > RTO of 500ms, requests would be sent at times 0 ms, 500 ms, 1500 ms, > 3500 ms, 7500 ms, 15500 ms, and 31500 ms. If the client has not > received a response after 39500 ms, the client will consider the > transaction to have timed out. I note that these recommendations now seem crazily long. I assume the WG had consensus on this, but I wanted to note it. > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suites MUST be > implemented and other cipher suites MAY be implemented. Perfect > Forward Secrecy (PFS) cipher suites MUST be preferred over non-PFS > cipher suites. Cipher suites with known weaknesses, such as those > based on (single) DES and RC4, MUST NOT be used. Implementations > MUST disable TLS-level compression. Would it be better to just cite to RFC 7525 here? > > o If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the > value for the message integrity as described in Section 14.6, > using the password associated with the username. If the MESSAGE- > INTEGRITY-SHA256 attribute is not present, and using the same > password, compute the value for the message integrity as described This text is a bit unclear. I think you mean "If the MESSAGE- INTEGRITY-SHA256 attribute is not present, then use the same password to compute the..." > a nonce. The nonce provides the replay protection. It is a cookie, > selected by the server, and encoded in such a way as to indicate a > duration of validity or client identity from which it is valid. The > client retries the request, this time including its username and the > realm, and echoing the nonce provided by the server. The client also > includes a message-integrity, which provides an HMAC over the entire Nit: "a message integrity attribute". Also, how do I know which one to use? > ALTERNATE-SERVER where authentication of the response is not possible > or practical. If the transaction uses TLS or DTLS and if the > transaction is authenticated by a MESSAGE-INTEGRITY-SHA256 attribute > and if the server wants to redirect to a server that uses a different > certificate, then it MUST include an ALTERNATE-DOMAIN attribute > containing the subjectAltName of that certificate. 1. Why is MESSAGE-INTEGRITY-SHA256 relevant here? > o What authentication and message-integrity mechanisms are used. > > o The considerations around manual vs. automatic key derivation for > the integrity mechanism, as discussed in [RFC4107]. > > o What mechanisms are used to distinguish STUN messages from other Why is this required? It seems like that's a generic STUN feature. > to the end of the MESSAGE-INTEGRITY-SHA256 attribute prior to > calculating the HMAC over the STUN message, up to and including the > attribute preceding the MESSAGE-INTEGRITY-SHA256 attribute. Such > adjustment is necessary when attributes, such as FINGERPRINT, appear > after MESSAGE-INTEGRITY-SHA256. See also Appendix B.1 for examples > of such calculations. So if M-I-SHA256 and M-I appear together, one includes the other but not vice versa? > transport protocol uses TLS or DTLS. > > The value of ALTERNATE-DOMAIN is variable length. It MUST be a UTF-8 > [RFC3629] encoded sequence of less than 128 characters (which can be > as long as 509 bytes when encoding them and as long as 763 bytes when > decoding them). Is it an A-label or a U-label? > 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 is subject to bid down attacks by an on-path attacker. By an on-path attacker who can forge HMAC-SHA1 in real-time? That's a pretty serious adversary, so you should clarify here |
2018-04-16
|
16 | Eric Rescorla | Ballot comment and discuss text updated for Eric Rescorla |
2018-04-16
|
16 | Eric Rescorla | [Ballot discuss] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D5132 Can you please indicate how you addressed the points Matt Miller raised in his secdir review … [Ballot discuss] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D5132 Can you please indicate how you addressed the points Matt Miller raised in his secdir review about the use of MD5. DETAIL > by the agent sending the indication. It primarily serves to > correlate requests with responses, though it also plays a small role > in helping to prevent certain types of attacks. The server also uses > the transaction ID as a key to identify each transaction uniquely > across all clients. As such, the transaction ID MUST be uniformly > and randomly chosen from the interval 0 .. 2**96-1, and SHOULD be I didn't realize this was a SHOULD. ICE depends on it as a security condition, so it probably needs to be a MUST. > For a request or indication message, the agent MUST include the > USERNAME, MESSAGE-INTEGRITY-SHA256, and MESSAGE-INTEGRITY attributes > in the message unless the agent knows from an external indication > which message integrity algorithm is supported by both agents. In > this case either MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 MUST > be included in addition to USERNAME. The HMAC for the MESSAGE- This text appears to conflict with S 7.3 of 5245-bis, which says: > STUN Security Feature it is understood that the corresponding STUN > Security Feature bit in the "nonce cookie" is set to 1. > > For example, in Section 9.2.4 discussing the PASSWORD-ALGORITHMS > security feature, it is implied that the "Password algorithms" bit, > as defined in Section 17.1, is set to 1 in the "nonce cookie". I'm not sure I understand the bid down attack here or the proposed defense. Can you please walk through what the assumed attacker capabilities are, what the client and server capabilities are, how the bid down attack works, and how this protects against it? |
2018-04-16
|
16 | Eric Rescorla | [Ballot comment] > > In keeping with its tool nature, this specification defines an > extensible packet format, defines operation over … [Ballot comment] > > In keeping with its tool nature, this specification defines an > extensible packet format, defines operation over several transport > protocols, and provides for two forms of authentication. > > STUN is intended to be used in context of one or more NAT traversal Nit: "in the context" > of [RFC0791]. Unless otherwise noted, numeric constants are in > decimal (base 10). > > All STUN messages comprise a 20-byte header followed by zero or more > Attributes. The STUN header contains a STUN message type, magic > cookie, transaction ID, and message length. You might want to list these in order. > The STUN usage must specify which transport protocol is used, and how > the agent determines the IP address and port of the recipient. > Section 8 describes a DNS-based method of determining the IP address > and port of a server that a usage may elect to use. STUN may be used > with anycast addresses, but only with UDP and in usages where > authentication is not used. Why this restriction? You should be able to use anycast with long-term AUTH for (say) TURN. > First, the initial value for RTO SHOULD be greater than 500 ms. The > exception cases for this "SHOULD" are when other mechanisms are used > to derive congestion thresholds (such as the ones defined in ICE for > fixed rate streams), or when STUN is used in non-Internet > environments with known network capacities. In fixed-line access > links, a value of 500 ms is RECOMMENDED. Second, the value of RTO I note that above you say "greater than 500 ms" but here you say "500 ms". Perhaps you mean greater than equal. > transaction over UDP or DTLS-over-UDP is also considered failed if > there has been a hard ICMP error [RFC1122]. For example, assuming an > RTO of 500ms, requests would be sent at times 0 ms, 500 ms, 1500 ms, > 3500 ms, 7500 ms, 15500 ms, and 31500 ms. If the client has not > received a response after 39500 ms, the client will consider the > transaction to have timed out. I note that these recommendations now seem crazily long. I assume the WG had consensus on this, but I wanted to note it. > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suites MUST be > implemented and other cipher suites MAY be implemented. Perfect > Forward Secrecy (PFS) cipher suites MUST be preferred over non-PFS > cipher suites. Cipher suites with known weaknesses, such as those > based on (single) DES and RC4, MUST NOT be used. Implementations > MUST disable TLS-level compression. Would it be better to just cite to RFC 7525 here? > > o If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the > value for the message integrity as described in Section 14.6, > using the password associated with the username. If the MESSAGE- > INTEGRITY-SHA256 attribute is not present, and using the same > password, compute the value for the message integrity as described This text is a bit unclear. I think you mean "If the MESSAGE- INTEGRITY-SHA256 attribute is not present, then use the same password to compute the..." > a nonce. The nonce provides the replay protection. It is a cookie, > selected by the server, and encoded in such a way as to indicate a > duration of validity or client identity from which it is valid. The > client retries the request, this time including its username and the > realm, and echoing the nonce provided by the server. The client also > includes a message-integrity, which provides an HMAC over the entire Nit: "a message integrity attribute". Also, how do I know which one to use? > ALTERNATE-SERVER where authentication of the response is not possible > or practical. If the transaction uses TLS or DTLS and if the > transaction is authenticated by a MESSAGE-INTEGRITY-SHA256 attribute > and if the server wants to redirect to a server that uses a different > certificate, then it MUST include an ALTERNATE-DOMAIN attribute > containing the subjectAltName of that certificate. 1. Why is MESSAGE-INTEGRITY-SHA256 relevant here? > o What authentication and message-integrity mechanisms are used. > > o The considerations around manual vs. automatic key derivation for > the integrity mechanism, as discussed in [RFC4107]. > > o What mechanisms are used to distinguish STUN messages from other Why is this required? It seems like that's a generic STUN feature. > to the end of the MESSAGE-INTEGRITY-SHA256 attribute prior to > calculating the HMAC over the STUN message, up to and including the > attribute preceding the MESSAGE-INTEGRITY-SHA256 attribute. Such > adjustment is necessary when attributes, such as FINGERPRINT, appear > after MESSAGE-INTEGRITY-SHA256. See also Appendix B.1 for examples > of such calculations. So if M-I-SHA256 and M-I appear together, one includes the other but not vice versa? > transport protocol uses TLS or DTLS. > > The value of ALTERNATE-DOMAIN is variable length. It MUST be a UTF-8 > [RFC3629] encoded sequence of less than 128 characters (which can be > as long as 509 bytes when encoding them and as long as 763 bytes when > decoding them). Is it an A-label or a U-label? > 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 is subject to bid down attacks by an on-path attacker. By an on-path attacker who can forge HMAC-SHA1 in real-time? That's a pretty serious adversary, so you should clarify here |
2018-04-16
|
16 | Eric Rescorla | [Ballot Position Update] New position, Discuss, has been recorded for Eric Rescorla |
2018-04-16
|
16 | Mirja Kühlewind | [Ballot comment] 1) Maybe it would make sense to refer informationally to draft-ietf-tram-stun-pmtud in section 6.1? 2) sec 6.2.2: This sentence seems to assume that … [Ballot comment] 1) Maybe it would make sense to refer informationally to draft-ietf-tram-stun-pmtud in section 6.1? 2) sec 6.2.2: This sentence seems to assume that only one request is sent per TCP connection/each request sends out after a new SYN: "However, for a request/response transaction, if the client has not received a response by Ti seconds after it sent the SYN to establish the connection, it considers the transaction to have timed out.“ i don’t think that assumption would be correct. Maybe rephrase this sentence…? 3) Also section 6.2.2: Should the client send keep-alives if a connection is hold open but currently not used? If not, I guess further recommendation is needed to address the case where a transmission fails because an existing idle TCP connection was used that doesn’t work anymore. In this case, I'd say the recommendation would be to send a RST and try to open a new TCP connection. 4) Should section 9.2 maybe provide further guidance on the lifetime of the (server-selected) nonce? 5) I'm sure, I just missed something but how does a server know if a first request intends to use the Long-Term Credential Mechanism or not (see 9.2.3.1. and 9.2.4 I guess). Or is this pre-configured? 6) Section 6.3 says that this doc only specifies the procedures for the new spec in this document and subsequently says: "It checks [...] that the magic cookie field has the correct value..." However, given this spec obsoletes RFC5389, I think that section 11 should provide more guidance on how to handle "old" STUN messages. Or is the intention that an upgraded STUN server does not handle old requests anymore? If so that should be spelled out as well. 7) sec 14.5: "The value of the MESSAGE-INTEGRITY attribute is set to a dummy value." Should the dummy value be further specified? Also it looks like there was a compile problem on page 39. Is there text missing? 8) sec 17.6: Isn't "stuns 5349/upd" used for DTLS? If so, it should be registered! |
2018-04-16
|
16 | Mirja Kühlewind | Ballot comment text updated for Mirja Kühlewind |
2018-04-16
|
16 | Mirja Kühlewind | [Ballot comment] 1) Maybe it would make sense to refer infromationally to draft-ietf-tram-stun-pmtud in section 6.1? 2) sec 6.2.2: This sentence seems to assume that … [Ballot comment] 1) Maybe it would make sense to refer infromationally to draft-ietf-tram-stun-pmtud in section 6.1? 2) sec 6.2.2: This sentence seems to assume that only one request is sent per TCP connection/each request sends out a new SYN: "However, for a request/response transaction, if the client has not received a response by Ti seconds after it sent the SYN to establish the connection, it considers the transaction to have timed out. " 3) Also section 6.2.2: Should the client send keep-alives if a connection is hold open but currently not used? If not, I gues furter recommendation is needed to address the case where a transmission fails because an existing idle TCP connection was used. In this case I'd say the recommendation would be to send a RST and try to open a new TCP connection. 4) Should section 9.2 maybe provide further guidance on the lifetime of the (server-selected) nonce? 5) I'm sure, I just missed something but how does a server now if a first request intends to use the Long-Term Credential Mechanism or not (see 9.2.3.1. and 9.2.4 I guess). Or is this pre-configured? 6) Section 6.3 says that this doc only specifies the procedures for the new spec in this document and subsequently says: "It checks [...] that the magic cookie field has the correct value..." However, given this spec obsoletes RFC5389, I think that section 11 should provide more guidance on how to handle "old" STUN messages. Or is the intention that an upgraded STUN server does not handle old requests anymore? If so that should be spelled out as well. 7) sec 14.5: "The value of the MESSAGE-INTEGRITY attribute is set to a dummy value." Should the dummy value be furtehr specified? Also it looks like there was a complie problem on page 39. Is there text missing? 8) sec 17.6: Isn't "stuns 5349/upd" used for DTLS? If so, it should be registered! |
2018-04-16
|
16 | Mirja Kühlewind | [Ballot Position Update] Position for Mirja Kühlewind has been changed to Yes from No Record |
2018-04-13
|
16 | Mirja Kühlewind | [Ballot comment] 1) Maybe it would make sense to refer infromationally to draft-ietf-tram-stun-pmtud in section 6.1? 2) sec 6.2.2: This sentence seems to assume that … [Ballot comment] 1) Maybe it would make sense to refer infromationally to draft-ietf-tram-stun-pmtud in section 6.1? 2) sec 6.2.2: This sentence seems to assume that only one request is sent per TCP connection/each request sends out a new SYN: "However, for a request/response transaction, if the client has not received a response by Ti seconds after it sent the SYN to establish the connection, it considers the transaction to have timed out. " 3) Also section 6.2.2: Should the client send keep-alives if a connection is hold open but currently not used? If not, I gues furter recommendation is needed to address the case where a transmission fails because an existing idle TCP connection was used. In this case I'd say the recommendation would be to send a RST and try to open a new TCP connection. 4) Should section 9.2 maybe provide further guidance on the lifetime of the (server-selected) nonce? 5) I'm sure, I just missed something but how does a server now if a first request intends to use the Long-Term Credential Mechanism or not (see 9.2.3.1. and 9.2.4 I guess). Or is this pre-configured? 6) Section 6.3 says that this doc only specifies the procedures for the new spec in this document and subsequently says: "It checks [...] that the magic cookie field has the correct value..." However, given this spec obsoletes RFC5389, I think that section 11 should provide more guidance on how to handle "old" STUN messages. Or is the intention that an upgraded STUN server does not handle old requests anymore? If so that should be spelled out as well. |
2018-04-13
|
16 | Mirja Kühlewind | Ballot comment text updated for Mirja Kühlewind |
2018-04-02
|
16 | Peter Saint-Andre | Request for Telechat review by ARTART Completed: Ready with Nits. Reviewer: Peter Saint-Andre. Sent review to list. |
2018-03-29
|
16 | Dale Worley | Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Dale Worley. Sent review to list. |
2018-03-21
|
16 | Spencer Dawkins | Telechat date has been changed to 2018-04-19 from 2018-04-05 |
2018-03-20
|
16 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2018-03-18
|
16 | Suhas Nandakumar | Request for Telechat review by ARTART is assigned to Peter Saint-Andre |
2018-03-18
|
16 | Suhas Nandakumar | Request for Telechat review by ARTART is assigned to Peter Saint-Andre |
2018-03-14
|
16 | Spencer Dawkins | Ballot has been issued |
2018-03-14
|
16 | Spencer Dawkins | Ballot writeup was changed |
2018-03-13
|
16 | Spencer Dawkins | IESG state changed to IESG Evaluation from Waiting for Writeup |
2018-03-13
|
16 | Spencer Dawkins | Ballot has been issued |
2018-03-13
|
16 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2018-03-13
|
16 | Spencer Dawkins | Created "Approve" ballot |
2018-03-13
|
16 | Spencer Dawkins | Ballot writeup was changed |
2018-03-09
|
16 | Matthew Miller | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Matthew Miller. Sent review to list. |
2018-03-08
|
16 | Jean Mahoney | Request for Telechat review by GENART is assigned to Dale Worley |
2018-03-08
|
16 | Jean Mahoney | Request for Telechat review by GENART is assigned to Dale Worley |
2018-03-05
|
16 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-03-05
|
16 | Marc Petit-Huguenin | New version available: draft-ietf-tram-stunbis-16.txt |
2018-03-05
|
16 | (System) | New version approved |
2018-03-05
|
16 | (System) | Request for posting confirmation emailed to previous authors: Rohan Mahy , Gonzalo Salgueiro , Dan Wing , Marc Petit-Huguenin , Philip Matthews , Jonathan Rosenberg |
2018-03-05
|
16 | Marc Petit-Huguenin | Uploaded new revision |
2018-03-02
|
15 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Éric Vyncke |
2018-03-02
|
15 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Éric Vyncke |
2018-02-26
|
15 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2018-02-23
|
15 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events' |
2018-02-21
|
15 | Scott Bradner | Assignment of request for Last Call review by OPSDIR to Scott Bradner was rejected |
2018-02-21
|
15 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events' |
2018-02-21
|
15 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Scott Bradner |
2018-02-21
|
15 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Scott Bradner |
2018-02-20
|
15 | Spencer Dawkins | Placed on agenda for telechat - 2018-04-05 |
2018-02-20
|
15 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-02-19
|
15 | Dale Worley | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Dale Worley. Sent review to list. |
2018-02-17
|
15 | Scott Bradner | Assignment of request for Last Call review by OPSDIR to Scott Bradner was rejected |
2018-02-17
|
15 | Scott Bradner | Assignment of request for Last Call review by OPSDIR to Scott Bradner was rejected |
2018-02-16
|
15 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2018-02-16
|
15 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-tram-stunbis-15. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-tram-stunbis-15. If any part of this review is inaccurate, please let us know. The IANA Services Operator has a question about more than one of the actions requested in the IANA Considerations section of this document. The IANA Services Operator understands that, upon approval of this document, there are seven actions which we must complete. First, a new registry is to be created called the STUN Security Features registry. STUN Security Feature values are 24 bits. IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols? Should it be located on the Session Traversal Utilities for NAT (STUN) Parameters registry page located at: https://www.iana.org/assignments/stun-parameters/ The new registry will be managed via Standards Action as defined in RFC 8126. There are initial registrations in the new registry as follows: Value Description Reference ------------+----------------------------------+-------------- 0x000001 Password algorithms [ RFC-to-be ] 0x000002 Username anonymity [ RFC-to-be ] IANA Question --> is the value 0x000000 unassigned or reserved? IANA Question --? are the remaining values between 0x000003 and 0xFFFFFF unassigned? Second, in the STUN Methods registry on the Session Traversal Utilities for NAT (STUN) Parameters registry page located at: https://www.iana.org/assignments/stun-parameters/ We will update the name for method 0x002 as follows: Value Name Reference ---------+----------------------------------------------------+------------- 0x002 (Reserved; prior to [RFC5389] this was SharedSecret) [ RFC-to-be ] and the references for values 0x000 0x001 0x002 will be changed from RFC5389 to [ RFC-to-be ]. Third, in the STUN Attribute Registry also on the Session Traversal Utilities for NAT (STUN) Parameters registry page located at: https://www.iana.org/assignments/stun-parameters/ the names for attributes 0x0002, 0x0003, 0x0004, 0x0005, 0x0007, and 0x000B, and the reference from RFC 5389 to RFC-to-be for the following STUN methods: Comprehension-required range (0x0000-0x7FFF): 0x0000: (Reserved) 0x0001: MAPPED-ADDRESS 0x0002: (Reserved; prior to [RFC5389] this was RESPONSE-ADDRESS) 0x0003: (Reserved; prior to [RFC5389] this was CHANGE-REQUEST) 0x0004: (Reserved; prior to [RFC5389] this was SOURCE-ADDRESS) 0x0005: (Reserved; prior to [RFC5389] this was CHANGED-ADDRESS) 0x0006: USERNAME 0x0007: (Reserved; prior to [RFC5389] this was PASSWORD) 0x0008: MESSAGE-INTEGRITY 0x0009: ERROR-CODE 0x000A: UNKNOWN-ATTRIBUTES 0x000B: (Reserved; prior to [RFC5389] this was REFLECTED-FROM) 0x0014: REALM 0x0015: NONCE 0x0020: XOR-MAPPED-ADDRESS Comprehension-optional range (0x8000-0xFFFF) 0x8022: SOFTWARE 0x8023: ALTERNATE-SERVER 0x8028: FINGERPRINT Fourth, in the STUN Attributes registry also on the Session Traversal Utilities for NAT (STUN) Parameters registry page located at: https://www.iana.org/assignments/stun-parameters/ In the Comprehension-required range (0x0000-0x7FFF): Value Name Reference -----------------------+------------------------+------------- [ TBD-at-Registration ] MESSAGE-INTEGRITY-SHA256 [ RFC-to-be ] [ TBD-at-Registration ] PASSWORD-ALGORITHM [ RFC-to-be ] [ TBD-at-Registration ] USERHASH [ RFC-to-be ] IANA Question --> Are these to be from the 0x0000-0x3FFF range or the 0x4000-0x7FFF range? In the Comprehensive-optional range (0x8000-0xFFFF): Value Name Reference -----------------------+------------------------+------------- [ TBD-at-Registration ] PASSSORD-ALGORITHMS [ RFC-to-be ] [ TBD-at-Registration ] ALTERNATE-DOMAIN [ RFC-to-be ] Fifth, in the STUN Error Codes registry also on the Session Traversal Utilities for NAT (STUN) Parameters registry page located at: https://www.iana.org/assignments/stun-parameters/ The following error codes are to be updated with their reference changed from RFC 5389 to [ RFC-to-be ]: 300 Try Alternate 400 Bad Request 401 Unauthenticated 420 Unknown Attribute 438 Stale Nonce 500 Server Error Sixth, a new registry is to be created called the Password Algorithm registry. IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols? Should it be located on the Session Traversal Utilities for NAT (STUN) Parameters registry page located at: https://www.iana.org/assignments/stun-parameters/ Password Algorithms range between 0x0000 and 0xFFFF. Password Algorithms in the first half of the range (0x0000 - 0x7FFF) are assigned by IETF Review as defined by RFC 8126. Password Algorithms in the second half of the range (0x8000 - 0xFFFF) are assigned by Designated Expert as defined by RFC 8126. There are initial registrations in the new registry as follows: Value Algorithm Reference -----------+--------------------+-------------- 0x0001 MD5 [ RFC-to-be ] 0x0002 SHA256 [ RFC-to-be ] IANA Question --> is the value 0x0000 unassigned or reserved? IANA Question --? are the remaining values between 0x0003 and 0xFFFF unassigned? Seventh, in the Service Name and Transport Protocol Port Number Registry located at: https://www.iana.org/assignments/service-names-port-numbers/ the following port and service names are to have their reference changed from RFC 5389 to [ RFC-to-be ]: 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 The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2018-02-16
|
15 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Scott Bradner |
2018-02-16
|
15 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Scott Bradner |
2018-02-15
|
15 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Scott Bradner |
2018-02-15
|
15 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Scott Bradner |
2018-02-08
|
15 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Matthew Miller |
2018-02-08
|
15 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Matthew Miller |
2018-02-08
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dale Worley |
2018-02-08
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dale Worley |
2018-02-06
|
15 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2018-02-06
|
15 | Cindy Morgan | The following Last Call announcement was sent out (ends 2018-02-20): From: The IESG To: IETF-Announce CC: tram-chairs@ietf.org, tram@ietf.org, Tolga Asveren , Gonzalo.Camarillo@ericsson.com, … The following Last Call announcement was sent out (ends 2018-02-20): From: The IESG To: IETF-Announce CC: tram-chairs@ietf.org, tram@ietf.org, Tolga Asveren , Gonzalo.Camarillo@ericsson.com, tasveren@rbbn.com, spencerdawkins.ietf@gmail.com, draft-ietf-tram-stunbis@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Session Traversal Utilities for NAT (STUN)) to Proposed Standard The IESG has received a request from the TURN Revised and Modernized WG (tram) to consider the following document: - 'Session Traversal Utilities for NAT (STUN)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-02-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This document obsoletes RFC 5389. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ballot/ No IPR declarations have been submitted directly on this I-D. |
2018-02-06
|
15 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2018-02-06
|
15 | Spencer Dawkins | Last call was requested |
2018-02-06
|
15 | Spencer Dawkins | Ballot approval text was generated |
2018-02-06
|
15 | Spencer Dawkins | Ballot writeup was generated |
2018-02-06
|
15 | Spencer Dawkins | IESG state changed to Last Call Requested from AD Evaluation |
2018-02-06
|
15 | Spencer Dawkins | Last call announcement was generated |
2018-02-06
|
15 | Spencer Dawkins | Last call announcement was generated |
2018-02-05
|
15 | Spencer Dawkins | IESG state changed to AD Evaluation from Publication Requested |
2018-02-02
|
15 | Gonzalo Camarillo | PROTO write up for draft-ietf-tram-stunbis-15: [2018-01-20 Sat] (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? … PROTO write up for draft-ietf-tram-stunbis-15: [2018-01-20 Sat] (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard, as indicated on the front page of the draft. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. In keeping with its tool nature, this specification defines an extensible packet format, defines operation over several transport protocols, and provides for two forms of authentication. This document obsoletes the original STUN specification RFC 5389. Working Group Summary: The working group had a strong consensus around this draft. Document Quality: The document quality is satisfactory. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Tolga Asveren is the document shepherd. Spencer Dawkins is the responsible Area director (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has reviewed version 12 of the draft, provided comments. They have been discussed and satisfactorily addressed by version 13 of the draft. There also have been other reviews and all comments re addressed by version 14 of the draft and version 15 contains changes for nits. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. There have been sufficient discussions in the past and during WGLC timeframe. There is also at least one implementation of the procedures defined in this draft. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. The draft has sections pertaining to security, DNS and those are sufficiently reviewed. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. All draft authors also acknowledged that they are not aware of any IPR associated with the changes introduced by this document. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Strong consensus. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The nits tool reports a few downrefs, which are addressed in the response to question 15 below. Other than that, there no remaining nits. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No additional reviews are needed. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. Yes, and it is intentional. The text using the reference for RFC3489 is for the explicit purpose of explaining the compatibility issues with that precise version of the protocol. That is the reason why RFC3489 instead of RFC5389, which obsoletes it, is used. RFC 1321 and RFC 2104 were already downrefs in RFC 5389, which this draft will obsolete. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. Yes, it will obsolete RFC5389. It defines procedures in addition to the ones defined in RFC5389. RFC5389 is the listed on the title page and abstract as to be obsoleted. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The IANA Considerations section registers new STUN Methods, updates and defines new STUN attributes, updates STUN error codes and updates the reference for STUN UDP/TCP port numbers. It also defines new STUN Security Features Registry/values, Password Algorithm Registry/values. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. New STUN Security Features and Password Algorithm Registries are defined. IANA experts specializing in security aspects would be suitable for reviewing these. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. The document has a C snipped to determine STUN Message Types. The C code has been tried and it functions as intended. |
2018-02-02
|
15 | Gonzalo Camarillo | Responsible AD changed to Spencer Dawkins |
2018-02-02
|
15 | Gonzalo Camarillo | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2018-02-02
|
15 | Gonzalo Camarillo | IESG state changed to Publication Requested |
2018-02-02
|
15 | Gonzalo Camarillo | IESG process started in state Publication Requested |
2018-02-02
|
15 | Gonzalo Camarillo | Changed document writeup |
2018-02-02
|
15 | Gonzalo Camarillo | Notification list changed to Tolga Asveren <tasveren@rbbn.com>, Gonzalo.Camarillo@ericsson.com from Tolga Asveren <tasveren@rbbn.com> |
2018-02-02
|
15 | Gonzalo Camarillo | Notification list changed to Tolga Asveren <tasveren@rbbn.com> |
2018-02-02
|
15 | Gonzalo Camarillo | Document shepherd changed to Tolga Asveren |
2018-02-02
|
15 | Gonzalo Camarillo | Changed consensus to Yes from Unknown |
2018-02-02
|
15 | Gonzalo Camarillo | Intended Status changed to Proposed Standard from None |
2018-01-19
|
15 | Marc Petit-Huguenin | New version available: draft-ietf-tram-stunbis-15.txt |
2018-01-19
|
15 | (System) | New version approved |
2018-01-19
|
15 | (System) | Request for posting confirmation emailed to previous authors: Rohan Mahy , Gonzalo Salgueiro , Dan Wing , Marc Petit-Huguenin , Philip Matthews , Jonathan Rosenberg |
2018-01-19
|
15 | Marc Petit-Huguenin | Uploaded new revision |
2018-01-14
|
14 | Marc Petit-Huguenin | New version available: draft-ietf-tram-stunbis-14.txt |
2018-01-14
|
14 | (System) | New version approved |
2018-01-14
|
14 | (System) | Request for posting confirmation emailed to previous authors: Rohan Mahy , Gonzalo Salgueiro , Dan Wing , Marc Petit-Huguenin , Philip Matthews , Jonathan Rosenberg |
2018-01-14
|
14 | Marc Petit-Huguenin | Uploaded new revision |
2017-12-18
|
13 | Marc Petit-Huguenin | New version available: draft-ietf-tram-stunbis-13.txt |
2017-12-18
|
13 | (System) | New version approved |
2017-12-18
|
13 | (System) | Request for posting confirmation emailed to previous authors: tram-chairs@ietf.org, Rohan Mahy , Gonzalo Salgueiro , Dan Wing , Marc Petit-Huguenin , Philip Matthews , … Request for posting confirmation emailed to previous authors: tram-chairs@ietf.org, Rohan Mahy , Gonzalo Salgueiro , Dan Wing , Marc Petit-Huguenin , Philip Matthews , Jonathan Rosenberg |
2017-12-18
|
13 | Marc Petit-Huguenin | Uploaded new revision |
2017-10-02
|
12 | (System) | Document has expired |
2017-05-01
|
12 | Simon Perreault | IETF WG state changed to In WG Last Call from WG Document |
2017-03-31
|
12 | Marc Petit-Huguenin | New version available: draft-ietf-tram-stunbis-12.txt |
2017-03-31
|
12 | (System) | New version approved |
2017-03-31
|
12 | (System) | Request for posting confirmation emailed to previous authors: Rohan Mahy , Gonzalo Salgueiro , Dan Wing , Jonathan Rosenberg , Philip Matthews , Marc Petit-Huguenin |
2017-03-31
|
12 | Marc Petit-Huguenin | Uploaded new revision |
2017-03-13
|
11 | Marc Petit-Huguenin | New version available: draft-ietf-tram-stunbis-11.txt |
2017-03-13
|
11 | (System) | New version approved |
2017-03-13
|
11 | (System) | Request for posting confirmation emailed to previous authors: tram-chairs@ietf.org, Rohan Mahy , Gonzalo Salgueiro , Jonathan Rosenberg , Philip Matthews , Marc Petit-Huguenin , … Request for posting confirmation emailed to previous authors: tram-chairs@ietf.org, Rohan Mahy , Gonzalo Salgueiro , Jonathan Rosenberg , Philip Matthews , Marc Petit-Huguenin , Dan Wing |
2017-03-13
|
11 | Marc Petit-Huguenin | Uploaded new revision |
2017-02-16
|
10 | Gonzalo Salgueiro | New version available: draft-ietf-tram-stunbis-10.txt |
2017-02-16
|
10 | (System) | New version approved |
2017-02-16
|
10 | (System) | Request for posting confirmation emailed to previous authors: "Dan Wing" , "Jonathan Rosenberg" , "Philip Matthews" , "Rohan Mahy" , "Gonzalo Salgueiro" , "Marc Petit-Huguenin" |
2017-02-16
|
10 | Gonzalo Salgueiro | Uploaded new revision |
2016-12-14
|
09 | Marc Petit-Huguenin | New version available: draft-ietf-tram-stunbis-09.txt |
2016-12-14
|
09 | (System) | New version approved |
2016-12-14
|
09 | (System) | Request for posting confirmation emailed to previous authors: "Dan Wing" , "Jonathan Rosenberg" , "Philip Matthews" , "Rohan Mahy" , "Gonzalo Salgueiro" , "Marc Petit-Huguenin" |
2016-12-14
|
09 | Marc Petit-Huguenin | Uploaded new revision |
2016-06-15
|
08 | Marc Petit-Huguenin | New version available: draft-ietf-tram-stunbis-08.txt |
2016-05-27
|
07 | Marc Petit-Huguenin | New version available: draft-ietf-tram-stunbis-07.txt |
2016-01-28
|
06 | Gonzalo Salgueiro | New version available: draft-ietf-tram-stunbis-06.txt |
2016-01-26
|
05 | Gonzalo Salgueiro | New version available: draft-ietf-tram-stunbis-05.txt |
2015-03-27
|
04 | Marc Petit-Huguenin | New version available: draft-ietf-tram-stunbis-04.txt |
2015-03-26
|
03 | Marc Petit-Huguenin | New version available: draft-ietf-tram-stunbis-03.txt |
2015-03-09
|
02 | Marc Petit-Huguenin | New version available: draft-ietf-tram-stunbis-02.txt |
2015-02-17
|
01 | Marc Petit-Huguenin | New version available: draft-ietf-tram-stunbis-01.txt |
2014-11-13
|
00 | Gonzalo Salgueiro | New version available: draft-ietf-tram-stunbis-00.txt |