Subject: [midcom] STUN last call

From: Melinda Shore <[email-masked]>
Date: Mon, 08 Jul 2002 10:19:19 -0400

We are starting working group last call on STUN, ending 
22 July 2002.  Please send any comments to the midcom mailing
list, along with an indication of whether or not you feel the
issue is serious enough to stop last call.

Thanks,

Melinda

>To: IETF-Announce: ;
>Cc: [email-masked]
>From: [email-masked]
>Reply-to: [email-masked]
>Date: Sun, 07 Jul 2002 12:10:15 -0400
>Subject: [midcom] I-D ACTION:draft-ietf-midcom-stun-01.txt
>Sender: [email-masked]
>X-Mailman-Version: 1.0
>List-Id:  <midcom.ietf.org>
>X-BeenThere: [email-masked]
>
>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 IETF.
>
>        Title           : STUN - Simple Traversal of UDP Through Network Address
>                          Translators
>        Author(s)       : J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy
>        Filename        : draft-ietf-midcom-stun-01.txt
>        Pages           : 42
>        Date            : 05-Jul-02
>        
>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. The STUN
>protocol is simple, being almost identical to echo.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-01.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-01.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-01.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.
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-midcom-stun-01.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-midcom-stun-01.txt>

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

---

From: "Pete Cordell" <[email-masked]>
Date: Tue, 23 Jul 2002 14:01:31 +0100

I've only scanned the new draft.  I have some other editorial comments, but
I wanted to present the following first.....

My main concern is that the default security mechanisms require the server
to be stateful.  This is undesirable and I think it can be avoided with only
minor changes.  This would involve the server supplying the TARGET-TID
instead of the client.  The following sequence would result:

1.  Client sends shared secret request over TLS.

2.  Server returns TARGET-TID and corresponding TARGET-OTP to client.
     The server can generate these as:

    TARGET-TID = random;
    TARGET-OTP = HMAC_?( server_secret, TARGET-TID );

Being algorithmically related, a server does not need state.  Because both
are supplied by the server, an attacker can't request the TARGET-OTP
corresponding to a particular TARGET-TID.

These effectively act as a server supplied user-name and password.  In that
spirit I would recommend that the TARGET-TID be entered as a separate
parameter in the Binding Request.  That way the same TARGET-TID / TARGET-OTP
pair can be used for a number of requests (possibly over a number of days).

The Binding requests would then operate something like:

3.  Message = TID + TARGET-TID + ???? + MESSAGE-INTEGRITY using TARGET-OTP.

4.  The server can recompute TARGET-OTP from TARGET-TID and send back:
      Message = TID + ???? + MESSAGE-INTEGRITY using TARGET-OTP.

This seems a minor change.  It looks slightly more secure to me (attackers
can't ask for TARGET-OTP), it's more efficient in that the TARGET-TID and
TARGET-OTP can be used for multiple requests, and the server doesn't require
per client state.

So how about it?

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
[email-masked]
+44 1473 635863
=============================================