Subject: [TLS] PSK question

From: [email-masked] (Peter Gutmann)
Date: Wed, 08 Dec 2004 21:53:51 +1300

I was reading through the draft again an noticed:

  To help the client in selecting which identity to use, the server can
  provide a "PSK identity hint" in the ServerKeyExchange message (note that if
  no hint is provided, a ServerKeyExchange message is still sent)

I have no idea what an "identity hint" could possibly be (the spec says it's
optional, but I'd have no idea what to put in there in any case).  If the
field is used for something, what's it supposed to be used for?  If not,
perhaps it should be dropped.

(Hmm, and I'll repeat my earlier gripe that apart from its use to convey this
 unknown quantity, there's no need to send the server keyex at all.  In other
 words in 99.99% of cases it's just going to be code and message bloat).

Peter.

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

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 08 Dec 2004 23:18:41 +1300

Another thing I just noticed:

  The premaster secret is formed as follows: if the PSK is N octets long,
  concatenate an uint16 with the value N, N zero octets, a second uint16 with
  the value N, and the PSK itself.

What's the point of the N zero octets?  If other_secret is empty (which it is
for the simplest case where there's no DH, RSA, or other keying material
present) then shouldn't the:

  opaque other_secret<0..2^16-1>;

just be a 16-bit length of zero and no data octets?  Why the unnecessary zero
octets?

Peter.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 30 Dec 2004 14:35:43 -0800 (PST)

I am also concerned about the interoperability of the
client/server identity exchange specified in draft-ietf-tls-psk-05.txt.
In reading the posts by Peter Gutmann, I find the arguments persuasive:

http://www.imc.org/ietf-tls/mail-archive/msg04402.html
http://www.imc.org/ietf-tls/mail-archive/msg04418.html

I'd suggest that this issue needs to be addressed before this
specification can progress.

The following potential problems come to mind:

a. Generality.  On reading the discussion,  it would appear that this
facility was designed for use within 3GPP, where the "hint" refers to
the "bootstrapping" function used to bootstrap the shared key between
client and server.  However, I believe that IETF specifications should
also be able to interoperate widely so that they can be used on the
Internet.  I'm not clear that the current specification will interoperate.
For example, if the spec is going to support multiple ID formats, then
support for various formats should be negotiated.

b. Compatibility with existing specifications. One of the major uses of
this specification is in WLAN authentication.  However, mandating at least
one form for the client identifier, it is not clear how wecan guarantee
conformance to RFC 2486, which standardizes the format of the Network
Access Identifier (NAI).

c. Difficulties in operation with AAA.  Without mandating at least one
form for the server identifier, it is not clear to me how a client can
unambiguously identify what server it is talking to.  It is
quite possible that AAA servers will not be synchronized with respect to
their session caches, or even the pre-shared keys to be utilized (e.g.
LDAP directory synchronization can lag behind), so that this could be a
problem.

d. IPR disclosure. IPR has been filed relating to "hint" mechanisms:
http://www.ietf.org/ietf/IPR/telecom-italia-ipr-wlan-access.txt
I am therefore concerned that making "hints" an integral part of this
specification will create problems with encumbrance.  This problem can be
avoided by clearly mandating support for certain client and serverid
formats.

---

From: [email-masked]
Date: Fri, 31 Dec 2004 15:11:17 +0200

> draft-ietf-tls-psk-05.txt.

Thanks for your comments, Bernard!

> a. Generality.  On reading the discussion, it would appear
> that this facility was designed for use within 3GPP, where the
> "hint" refers to the "bootstrapping" function used to
> bootstrap the shared key between client and server.  However,
> I believe that IETF specifications should also be able to
> interoperate widely so that they can be used on the Internet.
> I'm not clear that the current specification will
> interoperate.  For example, if the spec is going to support
> multiple ID formats, then support for various formats should
> be negotiated.

TLS-PSK alone does not do anything useful, and cannot be used by
itself: it's always a component in a larger system. It is these
systems that either interoperate or don't. So if e.g. 3GPP runs
protocol FOO over TLS (using PSK ciphersuites), there's no need
(or possibility) to interoperate with someone running a
different protocol BAR over TLS. 

The approach so far has been to put only the common parts in 
TLS specs (RFC 2246, 2712, etc.) and application-specific parts 
elsewhere. For some uses of TLS, we have separate documents 
(like RFC 2595 for IMAP/POP-over-TLS, RFC 2818 for HTTP-over-TLS);
others specify TLS details together with the rest of the protocol 
(e.g. RFC 2716 for EAP-TLS, RFC 3788 for SIGTRAN). These TLS 
details include, among other things, what ciphersuites and what 
kind of identifiers (e.g. dNSName SubjectAltName) should be be 
used (and we don't have negotiation for these either).

I think this approach has worked so far with other TLS 
ciphersuites, and I don't see any special reason why it would 
fail especially with PSK ciphersuites...?

> b. Compatibility with existing specifications. One of the
> major uses of this specification is in WLAN authentication.
> However, mandating at least one form for the client
> identifier, it is not clear how we can guarantee conformance to
> RFC 2486, which standardizes the format of the Network Access
> Identifier (NAI).

Agreed; I just think the right place to mandate this is in the
"upper layer protocol" using TLS (in this case, EAP-TLS),
not the TLS specs.

> c. Difficulties in operation with AAA.  Without mandating at
> least one form for the server identifier, it is not clear to
> me how a client can unambiguously identify what server it is
> talking to.  It is quite possible that AAA servers will not be
> synchronized with respect to their session caches, or even the
> pre-shared keys to be utilized (e.g.  LDAP directory
> synchronization can lag behind), so that this could be a
> problem.

This problem also seems related to one specific application
(EAP-TLS) that uses TLS, not TLS itself.

> I am therefore concerned that making "hints" an integral part
> of this specification will create problems with encumbrance.
> This problem can be avoided by clearly mandating support for
> certain client and serverid formats.

The IPR disclosure is related to network discovery and
selection, and does not mention the word "hint" anywhere.

Best regards & Happy New Year,
Pasi