Subject: [BEHAVE] updated rfc3489bis now available

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 14 Jul 2008 18:10:15 -0400

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

This reflects our conclusions from the discussions on retransmits and 
the CLIENT attribute. Also incorporates some old comments from ekr which 
I had lost in my inbox. Diffs:

* changed SERVER attribute to SOFTWARE and allow its usage by clients

* clarified rules for generating same error response to a previous
   request when a retransmission is received

* clarified that spacing of new transactions to a server only applies
   for UDP not TCP

* clarified that, when TLS is used, the TLS_RSA_WITH_AES_128_CBC_SHA
   is mandatory to implement (previous wording was vague on this)

* provided a firmer definition of 'strong' passwords in the security
   considerations section, covering cases where the passwords are never
   entered by the user, and cases where they are.

* clarified that, transaction IDs are used as keys within the server
   to ID transactions across clients, and added SHOULD strength
   requirement to make crypto-random

* rounding of RTO to nearest 1ms (instead of 1s as defined for TCP) is
   changed from MUST to SHOULD

* added a paragraph in the hash agility section:

	<t>
	  It is also important to note that the HMAC is done using a
	  key which is itself computed using an MD5 of the user's
	  password. The choice of the MD5 hash was made because of the
	  existence of legacy databases which store passwords in that
	  form. If future work finds that an HMAC of an MD5 input is
	  not secure, and a different hash is needed, it can also be
	  changed using this plan. However, this would require
	  administrators to repopulate their databases.
	</t>

-Jonathan R.
-- 
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]
https://www.ietf.org/mailman/listinfo/behave

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 14 Jul 2008 17:10:26 -0700

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

Figure 3 defines 12 bits for the STUN method, which means 4096 different
values (0x000 to 0xFFF), but section 18.1 defines a range of 0x000 to
0x3FF.  What happened to the two missing bits?  Are they reserved?

Thanks.

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 15 Jul 2008 08:51:13 -0400

Gack, this looks like a bug. Should be 0x000 to 0xfff. Good catch. Will 
fix (probably auth48 at this point).

-Jonathan R.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 15 Jul 2008 14:58:45 +0200

This is last call on the changes performed that will run until the end 
of the BEHAVE WG sessions in Dublin. So if you have any issues with 
please raise them now. I expect to be able to approve this document 
after this last call.

Cheers

Magnus

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 15 Jul 2008 09:40:06 -0700

> fix (probably auth48 at this point).

So 0x000-0x7ff will be IETF Review and 0x800-0xFFF Designated Expert?