Subject: [TLS] I-D ACTION:draft-ietf-tls-psk-03.txt

From: [email-masked]
Date: Tue, 16 Nov 2004 16:13:53 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security Working Group of the IETF.

	Title		: Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
	Author(s)	: P. Eronen, H. Tschofenig
	Filename	: draft-ietf-tls-psk-03.txt
	Pages		: 16
	Date		: 2004-11-16
	
This document specifies three sets of new ciphersuites for the
   Transport Layer Security (TLS) protocol to support authentication
   based on pre-shared keys.  These pre-shared keys are symmetric keys,
   shared in advance among the communicating parties.  The first set of
   ciphersuites uses only symmetric key operations for authentication.
   The second set uses a Diffie-Hellman exchange authenticated with a
   pre-shared key; and the third set combines public key authentication
   of the server with pre-shared key authentication of the client.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-tls-psk-03.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-tls-psk-03.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.
_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: [email-masked]
Date: Tue, 30 Nov 2004 18:40:46 +0200

Hi,

If we assume the typical scenario would be that a person enters
the identifier and PSK in the TLS client (and server), then IMHO
the current approach (UTF-8 encoding) significantly increases
the chances for interoperability. It also simplifies actual
implementations, since they don't have to implement encoding/
decoding operations for all the different types of identifiers
people might want to use.

If, on the other hand, the identifiers and keys on both
endpoints come from some key distribution system (or something),
and this system actually cares about the type of the identifier
then using e.g. DER for X.500 DNs might make sense... but I
think the former case will be much more common (and many systems
will probably just do strcpy/strcmp for something that a person
entered somewhere, so UTF-8 will work fine).

This way, we also avoid the need to define what exactly is a
user name and what is not (not exactly simple if the "user" 
not a person but a device or a software component), and all
the interoperability issues this would bring up... so IMHO
we should keep it as it is.

Best regards,
Pasi

> -----Original Message-----
> From: Peter Gutmann
> Sent: Friday, November 26, 2004 1:17 PM
> To: [email-masked]
> Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-psk-03.txt
> 
> I've just been going through the -03 draft and I'm not sure
> whether the new requirements for encoding the identity are
> such a good idea.  The older -02 had "UTF-8 everything" which
> admittedly was a bit ambiguous, but I think the current
> requirement to convert things that aren't normally UTF-8 into
> UTF-8 will cause more interop problems than it solves, because
> some of the IDs that could potentially be used have ambiguous
> encodings in text form.  The obvious example is X.500 DNs, not
> only because (even in a perfect world) there are a pile of
> sematically equivalent forms that can't be easily compared
> with a strcmp(), but also because we're in an imperfect world
> where people put latin-1 into T61Strings that can't be
> reliably turned into UTF-8 and have multi-AVA RDNs for which
> some implementations will only see the first AVA and not the
> others, and a pile of other things.  Having to implement X.500
> en/decoding and string comparison rules in a TLS
> implementation is probably asking a bit much.
> 
> IPv6 has somewhat similar problems, there are several ways to
> represent an address, so you'd need to add complex
> en/decode/comparison logic to your code to handle this.
> 
> To resolve this, I think it's necessary to at least provide
> information on a couple of common ID types and their
> encodings, e.g:
> 
>   User names (where the user may be a human or a device, and 
>   which usually correspond to account names on the server being 
>   connected to) are encoded as a UTF-8 character string, without 
>   any terminating null character.
> 
>   IPv4 and IPv6 addresses are encoded as 32-bit and 128-bit 
>   integers in network byte order.
> 
>   URIs are encoded as specified in [RFC2616].
> 
>   Domain names are encoded as specified in [whatever the ref is]
> 
>   X.500 DNs are encoded as DER-encoded ASN.1 as it appears in 
>   the certificate or other object from which it's referenced.
> 
> Having said that, I'm not sure at the moment why you'd need
> something other than a straight user name.  For example, I
> can't see why I'd be connecting to a server and identifying
> myself as an IP address (I can certainly dream up an imaginary
> scenario if given a few minutes, but I can't think of any
> real-world situation where I'd need the ability to do this).
> So another option would be to leave everything but the user
> name unspecified and see if anyone ever needs any of the other
> options, and if so how they want to handle them.
> 
> Peter.