Subject: [email-masked]: [midcom] I-D ACTION:draft-ietf-midcom-stun-02.txt

From: Melinda Shore <[email-masked]>
Date: Wed, 28 Aug 2002 09:41:50 -0400

We're not taking this document through last call again, but
because there were some small changes as a result of WG last
call I'd like to give you all 24 hours to review this draft
and make sure that the changes are consistent with what we
discussed before I submit it to the IESG for review.

Thanks,

Melinda

------- Forwarded Message

Date:    Wed, 28 Aug 2002 07:57:34 -0400
From:    [email-masked]
To:      IETF-Announce: ;
cc:      [email-masked]
Subject: [midcom] I-D ACTION:draft-ietf-midcom-stun-02.txt

- --NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Middlebox Communication Working Group of the I
ETF.

	Title		: STUN - Simple Traversal of UDP Through Network Addres
s
                          Translators
       	Author(s)	: J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy
	Filename	: draft-ietf-midcom-stun-02.txt
	Pages		: 42
	Date		: 2002-8-27
	
Simple Traversal of UDP Through NATs (STUN) is a lightweight protocol
that allows applications to discover the presence and types of
Network Address Translators (NATs) and firewalls between them and the
public Internet. It also provides the ability for applications to
determine the public IP addresses allocated to them by the NAT. STUN
works with many existing NATs, and does not require any special
behavior from them. As a result, it allows a wide variety of
applications to work through existing NAT infrastructure

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-midcom-stun-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-midcom-stun-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

- --NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

- --OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-midcom-stun-02.txt

- --OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-midcom-stun-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

- --OtherAccess--

- --NextPart--

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

------- End of Forwarded Message

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

---

From: "Pete Cordell" <[email-masked]>
Date: Wed, 28 Aug 2002 17:01:54 +0100

I haven't had a chance to look at it all, but I have some comments on the
following bits:

   It MUST invalidate the username after 30 minutes. ......

While requiring a 10 minute minimum is useful, specifying a 30 minute
maximum seems to be getting very close to specifying policy.  (Perhaps
worryingly) my bank account details are protected by usernames and passwords
that have much lower entropy than 128bits, and I probably won't update them
for 30 days, let alone 30 minutes.

For a client there is no issue with leaving the maximum period open ended.
It can do a new Shared Secret Request whenever it wants.  The case for the
server is slightly more difficult, but all it requires is a new error code:

    5: The Binding Request contained an unknown or expired USERNAME
        attribute. The client should perform a Shared Secret Request to get
a
        new USERNAME and PASSWORD.

There is enough text in the existing paragraph to say what is recommended
behaviour, so you should be able to safely delete the sentence.  e.g.:

   s/It MUST invalidate the username after 30 minutes.//

On a lesser note:

   The server MUST NOT assign the same password for
   two different usernames, ....

While this is unlikely, it seems an odd requirement.  If a hashed master key
is used to generate PASSWORDs from USERNAMEs  and the master key is
periodically changed, it is conceivable that the same PASSWORD might be
generated for the different USERNAMEs.

This text may be there to cover the case where a server always hands out the
same PASSWORD in any period.  However, the text following the above sentence
("and the passwords MUST be unguessable. In other words, they MUST be a
cryptographically random function of the username.") seems to cover this
case.  If that is not sufficiently strong, maybe something like the
following can be used:

   The algorithm used by the server to generate PASSWORDs MUST
   ensure that the probability that the server allocates the same
   PASSWORD to two different USERNAMEs is vanishingly small.

Also...
when it comes to closing the TLS connection, from the following sentences
there seems to be the chance that the server will be hosting a number of
idle connections:

   The server SHOULD keep the connection open,
   and let the client close it.

   The client SHOULD close the
   connection as soon as it has finished obtaining usernames and
   passwords.

As multiple Binding Requests can use the same shared secret and there's no
real benefit for a client to obtain multiple short term secrets, from a
server perspective it would be nice to be able to clean up resources ASAP
after dishing out a shared secret (makes it more stateless without having to
have timers kick in etc.).  Therefore maybe the sentences should be changed
to:

   Typically the server SHOULD close the connection once the
   Shared Secret Response has been sent, but
   the server MAY keep the connection open,
   and let the client close it.

   The client SHOULD close the
   connection as soon as it has finished obtaining usernames and
   passwords, but it MUST be resilient to the server closing the
   connection immediately after the server has sent a response to
   the first Shared Secret Request.

That's all for now.  I'll try and read some more soon.  It is looking good
though.

Pete.

----- Original Message -----
From: "Melinda Shore" <[email-masked]>
To: <[email-masked]>
Sent: 28 August 2002 14:41
Subject: [email-masked]: [midcom] I-D
ACTION:draft-ietf-midcom-stun-02.txt