Subject: [BEHAVE] Updated rfc3489bis

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Feb 2008 21:59:30 -0500

I've just submitted an update to rfc3489bis:

http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-14.txt

This update reflects the DISCUSS comments raised by IESG. There were 
many discusses and this took some time to address. Below is the full set 
of changes I made to the document. There are some non-trivial ones, 
particularly the retransmission behaviors, MTU, and 
internationalization. So please take a look:

* fixed bug in MESSAGE-INTEGRITY section which gave inconsistent
   advice on usage of the length field in the STUN header

* security considerations section mentions usage of strong passwords
   is a SHOULD

* make more explicit mention of the security problems in rfc3489 and
   why they are mitigated now

* now mandating the use of SASLPrep (RFC 4013) for conveying username
   and processing of password, to deal with internationalization
   issues.

* maximum STUN message size now set to 576 bytes for v4, 1280 for v6,
   when pmtu is unknown. It was previously 1500 when pmtu is unknown.

* default RTO and minimum RTO changed from 100ms to 500ms. Exceptions
   are provided for non-Internet usages and for cases where rate limits
   are determined through other means (for example, ICE's RTP-rate
   matching algorithm). STUN transaction duration changed to 39500ms in
   the default case as a consequence. Also, the duration that a server
   has to generate the same response it sent previously to a request
   (i.e., retransmissions) is moved to 40s.

* clarified that, STUN over TCP is unframed when talking to a server
   you learned through dns or on the default port. Use of framing is
   only in cases where you have negotiated such as part of the usage -
   i.e., ICE connectivity checks.

* removed text that had servers accept new requests and drop existing
   connections in cases of overload. Now, just recommend following
   industry best practices in this area. Clarified that servers have to
   allow clients to close the connection since the client needs to hold
   the connection open to use the binding.

* ALTERNATE-SERVER mechanism requires clients to remember that they
   sent a request to a server previously and not try it again if they
   just tried it within the last 5 minutes. Basically prevents infinite
   ping-ponging of retry loops.

* ICMP failure cases were fuzzy, citing just 'fatal' ones. THis has
   been clarified to mean hard failure codes as defined in RFC1122.

* added a new section defining a 'basic standalone stun server'. This
   basically describes what was previously called the 'binding
   discovery usage'.

* clarified in the security considerations section that the message
   integrity mechanism is not always needed and the usage needs to
   describe this.

* the TLS ciphersuites described for STUN over TCP/TLS apply only for
   cases where STUN is run by itself. When muxed with other protocols
   the rules of that protocol apply.

* mentioned that usage specifications need to discuss the implications
   of RFC4107, which discusses manual vs. automated key management

* pointed to RFC2617 for guidance on NONCE rotation

* when a client is redirected via alternate-server, the text now says
   that the client should use the same transport protoocl used for the
   previous request.

* changed IANA registry rules for error codes from specification
   required to IETF consensus

* noted that the DNS SRV procedures for TCP and TLS are different than
   they were in RFC 3489

* in the FINGERPRINT section, note that this mechanism is not
   compatible with rfc3489 and cannot be used in environments where
   such interoperability is required

* changed the number of retransmissions of a request from 7 to a value
   called Rc which SHOULD be configurable and SHOULD have a default of
   7

* removed the MAY part of: "servers SHOULD run STUN on the default
   port but MAY use others"

* removed the requirement that STUN over TLS be on a different port
   than plain STUN over TCP. If your server software can demux than go
   for it.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Behave mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/behave

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 17 Feb 2008 12:31:16 -0800

Hi Jonathan,

> http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-14.txt

It seems that between -06 and -07 we lost the text that fixed the second
issue discussed here:

http://www.ietf.org/mail-archive/web/behave/current/msg01218.html

It could be also a good thing to add examples for long-term
authentication in draft-ietf-behave-stun-test-vectors.

Thanks.

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]
_______________________________________________
Behave mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Wed, 20 Feb 2008 09:58:11 -0500

> http://www.ietf.org/mail-archive/web/behave/current/msg01218.html

I will let Jonathan address this issue since he is handling STUN  
right now.
> authentication in draft-ietf-behave-stun-test-vectors.

This sounds like a good idea.

---

From: Bruce Lowekamp <[email-masked]>
Date: Wed, 20 Feb 2008 11:59:30 -0500

>    when pmtu is unknown. It was previously 1500 when pmtu is unknown.

This breaks the PADDING attribute of nat-behavior-discovery that is  
intended to help probe fragment handling.  Can this be changed to a  
SHOULD?  Alternatively, leave it a MUST but include some text to the  
effect that STUN usages MAY specify exceptions to this rule?

>    i.e., ICE connectivity checks.

I like this text better.  I think this text addresses my previous  
concerns on that issue.

Bruce

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 20 Feb 2008 19:07:41 +0200

>    when pmtu is unknown. It was previously 1500 when pmtu is unknown.

Should it not be clarified that this is the IP-layer datagram size, not 
the "STUN message size"? In other words, the maximumem STUN message size is 
548 bytes minus would-be IPv4 options resp. 1232 bytes minus would-be IPv6 
extension headers?

-- 
Rémi Denis-Courmont

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 20 Feb 2008 12:04:10 -0800

> This sounds like a good idea.

So I propose to add the following text:

2.4.  Sample request with long-term authentication

   This request uses the following parameters (without quotes):
   Username:  "username"
   Nonce:     "f//499k954d6OL34oL9FSTvy64sA"
   Realm:     "example.org"
   Password:  "The<U+00AD>M<U+00AA>tr<U+2168>"

00 01 00 54     Request type and message length
21 12 a4 42     Message cookie
57 ca b8 83  }
cd ec 6c 2a  }  Transaction ID
2d 4f 63 68  }
00 06 00 08     USERNAME attribute header
75 73 65 72  }  Username (8 bytes)
6e 61 6d 65  }
00 15 00 1c     NONCE attribute header
66 2f 2f 34  }
39 39 6b 39  }
35 34 64 36  }
4f 4c 33 34  }  Nonce value
6f 4c 39 46  }
53 54 76 79  }
36 34 73 41  }
00 14 00 0b     REALM attribute header
65 78 61 6d  }
70 6c 65 2e  }  Realm value (11 bytes) and padding (1 byte)
6f 72 67 00  }
00 08 00 14     MESSAGE-INTEGRITY attribute header
27 ca 6a b8  }
0f aa f2 67  }
85 b9 dd 0f  }  HMAC-SHA1 value
2e 17 68 0f  }
85 60 98 4b  }

---

From: Philip Matthews <[email-masked]>
Date: Wed, 20 Feb 2008 15:27:51 -0500

How about showing an example with a realm or username that uses  
characters outside the ASCII subset of UTF-8?

- Philip

On Wed, 20-Feb-08, at 15:04 , Marc Petit-Huguenin wrote:

>    Password:  "The <U+00AD>M<U+00AA>tr<U+2168>"
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 20 Feb 2008 13:19:24 -0800

> characters outside the ASCII subset of UTF-8?

OK, what about this (username is "Matorikkusu" - aka The Matrix -  in
katakana):

   This request uses the following parameters (without quotes):
   Username:  "<U+30DE><U+30C8><U+30EA><U+30C3><U+30AF><U+30B9>"
   Nonce:     "f//499k954d6OL34oL9FSTvy64sA"
   Realm:     "example.org"
   Password:  "The<U+00AD>M<U+00AA>tr<U+2168>"

00 01 00 60     Request type and message length
21 12 a4 42     Message cookie
78 ad 34 33  }
c6 ad 72 c0  }  Transaction ID
29 da 41 2e  }
00 06 00 12     USERNAME attribute header
e3 83 9e e3  }
83 88 e3 83  }
aa e3 83 83  }  Username value (18 bytes) and padding (2 bytes)
e3 82 af e3  }
82 b9 00 00  }
00 15 00 1c     NONCE attribute header
66 2f 2f 34  }
39 39 6b 39  }
35 34 64 36  }
4f 4c 33 34  }  Nonce value
6f 4c 39 46  }
53 54 76 79  }
36 34 73 41  }
00 14 00 0b     REALM attribute header
65 78 61 6d  }
70 6c 65 2e  }  Realm value (11 bytes) and padding (1 byte)
6f 72 67 00  }
00 08 00 14     MESSAGE-INTEGRITY attribute header
f6 70 24 65  }
6d d6 4a 3e  }
02 b8 e0 71  }  HMAC-SHA1 value
2e 85 c9 a2  }
8c a8 96 66  }

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 23 Feb 2008 13:50:23 -0500

Yes, I will clarify this.

I'll also change to SHOULD per Bruce's comment, and clarify in the text 
that this is a SHOULD and not a MUST to deal with cases where STUN is 
used explicitly to probe fragment handling.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 23 Feb 2008 13:48:48 -0500

Wow, that is a great catch. I'll submit a -15 with this included.

-Jonathan R.