Subject: [BEHAVE] RFC3489bis-07 now available

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 09 Jul 2007 16:45:08 -0400

RFC3489bis-07 is now available:
http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-07.txt

Firstly, I'd like to thank Philip Matthews and Dan Wing for taking up 
much of the editing and administrative tasks required in incorporating 
the huge number of comments that were made during the previous WGLC. 
Philip has been added as a co-author for his work on this document.

We *think* we captured all of the comments, both nits and more 
substantive issues, raised during WGLC.

There are lots of changes in this draft, most of them around structure, 
organization and terminology. On-the-wire only a little has changed. A 
big part of the changes were an attempt to simplify a document which 
really seemed too long for a protocol that actually does very little. We 
eliminated 15 pages, going from 61 in bis-06 to 46 here.

Changes to note are:

* completely redefined what a usage is. THis was the source of a lot of 
fluff in the text. Now, a usage is just a protocol that makes use of 
STUN for nat traversal. ICE is a usage. So is sip-outbound. THere are no 
longer formal requirements for definition of a usage; the usage just 
says how to use STUN, which these drafts already do. STUN can have 
extensions - these are new attributes, methods, and error codes. ICE 
uses STUN and also defines a few extensions.

* security considerations is pared down; really the job of defining 
security lies with the usage. STUN by itself has security problems, but 
when used with ICE they are mitigated. Since we are not ever 
recommending stun by itself, no need to treat security of a pure stun system

* removed IAB consideartions - per above this is ICE's job now

* removed shared secret request and response. This is just way too 
complex. It had already been relegated to a usage. Now its gone. THe 
main driving need has evaporated with ICE.

* simplified the authentication sections, splitting them out into two 
separte subsections which clearly explain how short term works and how 
long term works. We no longer support dynamically switching from one to 
the other. Rather a usage states which one is used.

* removal of several error codes that could only happen in 
implementation errors.

* split IANA registry for attributes and methods into one that is done 
by IETF, and a vendor first-come first-served space

* defined length limits on all free-form fields

Dan or Philip - others you'd like to add?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Tue, 10 Jul 2007 16:30:17 -0400

I think it is worthwhile talking a bit more about the organizational  
changes.

The document now has a section (section 7) called "Basic Protocol  
Procedures" which defines all the basic rules for STUN message  
formation and processing. This section also defines the Binding  
method, which is the only method now defined in 3489bis.

After this comes a bunch of sections that define optional  
"mechanisms". Each mechanism represents an extension to STUN that a  
usage can elect to use or not use as it sees fit. The mechanisms  
defined so far include:
* The FINGERPRINT mechanism
* DNS Discovery of a STUN Server
* The two authentication and message-integrity mechanisms
* The ALTERNATE-SERVER mechanism
* Backward compatibility with RFC 3489.
TURN is also envisioned as such a mechanism.

So, for example, ICE chooses to use the FINGERPRINT mechanism, but  
SIP-Outbound might not.

As Jonathan said, there were lots of other more minor changes made,  
most of them as a result of the WGLC comments.

- Philip

On 9-Jul-07, at 16:45 , Jonathan Rosenberg wrote:

> Firstly, I'd like to thank Philip Matthews and Dan Wing for taking  
> up much of the editing and administrative tasks required in  
> incorporating the huge number of comments that were made during the  
> previous WGLC. Philip has been added as a co-author for his work on  
> this document.
>
> There are lots of changes in this draft, most of them around  
> structure, organization and terminology. On-the-wire only a little  
> has changed. A big part of the changes were an attempt to simplify  
> a document which really seemed too long for a protocol that  
> actually does very little. We eliminated 15 pages, going from 61 in  
> bis-06 to 46 here.
>
> Changes to note are:
>
> * completely redefined what a usage is. THis was the source of a  
> lot of fluff in the text. Now, a usage is just a protocol that  
> makes use of STUN for nat traversal. ICE is a usage. So is sip- 
> outbound. THere are no longer formal requirements for definition of  
> a usage; the usage just says how to use STUN, which these drafts  
> already do. STUN can have extensions - these are new attributes,  
> methods, and error codes. ICE uses STUN and also defines a few  
> extensions.
>
> security lies with the usage. STUN by itself has security problems,  
> but when used with ICE they are mitigated. Since we are not ever  
> complex. It had already been relegated to a usage. Now its gone.  
> THe main driving need has evaporated with ICE.
>
> * simplified the authentication sections, splitting them out into  
> two separte subsections which clearly explain how short term works  
> and how long term works. We no longer support dynamically switching  
> from one to the other. Rather a usage states which one is used.
>
> * split IANA registry for attributes and methods into one that is  
> done by IETF, and a vendor first-come first-served space
>

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Fri, 13 Jul 2007 23:52:49 +0200

Hi

Great work guys!

It could be added that the REFRESH-INTERVAL attribute is also removed.

please see my comments attached

/alfred

> Dan or Philip - others you'd like to add?

Comments on draft-ietf-behave-rfc3489bis-07

by Alfred E. Heggestad <[email-masked]>
13. July 2007

> Section 1
>
>   authentication mechanism is to be used.  Interactive Connectivity
>   Establishment (ICE) [I-D.ietf-mmusic-ice] is one usage of ICE.  SIP
                                                     ^^^^^^^^^^^^
should be "usage of STUN" ?

>   Outbound [I-D.ietf-sip-outbound] is another usage of ICE.  In some
                                                ^^^^^^^^^^^^

should be "usage of STUN"? I guess outbound is not a usage of ICE ..

> Section 6. 8th paragraph:
>
>   The magic cookie field MUST contain the fixed value 0x2112A442 in
>   network byte order.  In RFC 3489 [RFC3489], this field was part of...
>
> and Section 14.2
>
>   For example, using the "^" character to indicate exclusive or, if the
>   IP address is 192.168.1.1 (0xc0a80101) and the port is 5555 (0x15B3),
>   the X-Port would be 0x15B3 ^ 0x2112 = 0x34A1, and the X-Address would
>   be 0xc0a80101 ^ 0x2112A442 = 0xe1baa543.
>

I am still confused with the endianess of the magic cookie. I have always
believed that any numeric values in the spec are in host order, and encoded
to network byte order when put on the wire. Consider the following C code
to encode a STUN header and send the buffer on the wire:

  #define STUN_MAGIC_COOKIE 0x2112A442

  uint32_t hdr[5], *p = hdr;

  *p++ = /* STUN Type and Length */
  *p++ = htonl(STUN_MAGIC_COOKIE);

Here is magic cookie is converted from host order to network byte order.
Is this wrong?

> Section 10.1.2
>
>      *  If the message is a request, the server MUST reject the request
>         with an error response.  This response MUST use an error code
>         of 431.

the 431 error code was deleted in -07. Either we must use a different
error code here, or put back the definition of 431.

some deleted error codes are referenced by turn-04:

   "Response with an appropriate error response code, such as a 431
    (Integrity Failure) or 436 (Unknown User)."

NITS:

> Section 6.  4th paragraph
>
>   a response message), and indication transactions (which consists a
>   single indication message).  Response classes are split into error

add "of" between "consists" and "a" -> "...(which consists of a single..."
                                                           ^^

> Section 6.  6th paragraph
>
>   method, Binding.  The method and class are orthogonal, so that four
>   each method, a request, success response, error response and
                                                                   ^^^^

-> should be "for"

> Section 7.2.1
>
>   the 3s recommended in RFC 2988).  In fixed- line access links, a
                                         ^^^^^^^^^^^

could be "fixed-line"

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 17 Jul 2007 15:42:19 +0300

> http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-07.txt
(...)
> * removal of several error codes that could only happen in

By the way, why then does TURN define a "TCP-only operation error"? I might be 
mistaken, but it feels strongly like it can only happen with a broken client 
implementation.

> * defined length limits on all free-form fields

That's really appreciable! But but, the limit should most likely be expressed 
in bytes rather than in characters. Otherwise, it is pretty ambiguous whether 
the limit is in code points or bytes.

Regards,

-- 
Rémi Denis-Courmont

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 17 Jul 2007 16:07:41 +0300

> * removal of several error codes that could only happen in

Looks like 431 has been unduly removed. It is still used in section 10, but is 
not defined anymore.

By the way, I am not the kind of security expert to determine whether this 
applies to STUN: Many protocols and applications are now purposedly returning 
the same error code whether the username or the password/shared-secret is 
wrong. I suppose that's meant to harden against brute-forcing.

Perhaps 431 should be returned instead of 401 when the username is wrong. In 
any case, the client application will handle both cases the same way, since 
it could be that the user mistyped his/her username so that it ends up being 
that of someone else.

-- 
Rémi Denis-Courmont

---

From: Philip Matthews <[email-masked]>
Date: Tue, 17 Jul 2007 14:24:30 -0400

> mistaken, but it feels strongly like it can only happen with a  

I'll let Rohan comment on this one.

> the limit is in code points or bytes.

I don't  really see this.
For the username, it says
    It MUST contain a
    UTF-8 encoded sequence of less than 128 characters.
How is this ambiguous?

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Tue, 17 Jul 2007 14:27:47 -0400

> Looks like 431 has been unduly removed. It is still used in section  

Thanks!
There were some last minute changes in this area, and a couple of  
small errors crept in.

> it could be that the user mistyped his/her username so that it ends  

Or perhaps both should return a 401.
Anyway, we will look at this.

- Philip

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 18 Jul 2007 09:45:45 +0300

>     UTF-8 encoded sequence of less than 128 characters.

To re-iterate the question, does "character" mean "code point" or "byte"? It 
is totally ambiguous.

To me, a UTF-8 encoded sequence of less than 128 characters is up to 
(128-1)*6+1=763 bytes, counting the terminating nul (and that's a bit big, 
IMHO). To most implementors it's going to be 127(+1) bytes.

I would much rather have:

	It MUST contain a valid UTF-8 encoded sequence of less than 128 bytes.

-- 
Rémi Denis-Courmont

---

From: Philip Matthews <[email-masked]>
Date: Wed, 18 Jul 2007 12:13:24 -0400

> 	It MUST contain a valid UTF-8 encoded sequence of less than 128  

OK. I see your point now, and think your proposed wording is fine.

- Philip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 27 Jul 2007 08:21:54 -0400

I'm OK to change to bytes, but wiould prefer 763. The intent really was 
128 characters, to support long names that could have 128 characters. 
128 bytes is like 20 characters which is not long enough. I'll clarify 
its 128 characters (which can be up to 763 bytes).

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 27 Jul 2007 08:27:46 -0400

> Looks like 431 has been unduly removed. It is still used in section 10, but is 

Actually, this is because of the issue below. The 431 here should say 
401 (note that 401 is used for long term in both cases).

> it could be that the user mistyped his/her username so that it ends up being 

401 is returned in both cases.

Thanks,
Jonathan R.