draft-ietf-tls-psk-06.txt   draft-ietf-tls-psk-07.txt 
TLS Working Group P. Eronen, Ed. TLS Working Group P. Eronen, Ed.
Internet-Draft Nokia Internet-Draft Nokia
Expires: August 22, 2005 H. Tschofenig, Ed. Expires: September 12, 2005 H. Tschofenig, Ed.
Siemens Siemens
February 21, 2005 March 14, 2005
Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
draft-ietf-tls-psk-06.txt draft-ietf-tls-psk-07.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 8, line 14 skipping to change at page 8, line 14
5. Conformance requirements 5. Conformance requirements
It is expected that different types of identities are useful for It is expected that different types of identities are useful for
different applications running over TLS. This document does not different applications running over TLS. This document does not
therefore mandate the use of any particular type of identity (such as therefore mandate the use of any particular type of identity (such as
IPv4 address or FQDN). IPv4 address or FQDN).
However, the TLS client and server clearly have to agree on the However, the TLS client and server clearly have to agree on the
identities and keys to be used. To improve interoperability, this identities and keys to be used. To improve interoperability, this
document places requirements on how the identity is encoded on the document places requirements on how the identity is encoded in the
wire, and what kinds of identities and keys implementations have to protocol, and what kinds of identities and keys implementations have
support. to support.
The requirements for implementations are divided to two categories, The requirements for implementations are divided to two categories,
requirements for TLS implementations and management interfaces. In requirements for TLS implementations and management interfaces. In
this context, "TLS implementation" refers to a TLS library or module this context, "TLS implementation" refers to a TLS library or module
that is intended to be used for several different purposes, while that is intended to be used for several different purposes, while
"management interface" would typically be implemented by a particular "management interface" would typically be implemented by a particular
application that uses TLS. application that uses TLS.
5.1 PSK identity encoding 5.1 PSK identity encoding
The PSK identity MUST be first converted to a character string, and The PSK identity MUST be first converted to a character string, and
then encoded to octets using UTF-8 [5]. For instance, then encoded to octets using UTF-8 [5]. For instance,
o IPv4 addresses are sent as dotted-decimal strings (e.g., o IPv4 addresses are sent as dotted-decimal strings (e.g.,
"192.0.1.2"), not as 32-bit integers in network byte order. "192.0.1.2"), not as 32-bit integers in network byte order.
o Domain names are sent in their usual text form (e.g., o Domain names are sent in their usual text form (e.g.,
"www.example.com" or "embedded.dot.example.net"), not in DNS "www.example.com" or "embedded.dot.example.net"), not in DNS
protocol wire format. protocol format.
o X.500 Distinguished Names are sent in their string representation o X.500 Distinguished Names are sent in their string representation
[9], not as BER-encoded ASN.1. [9], not as BER-encoded ASN.1.
This encoding is clearly not optimal for many types of identities. This encoding is clearly not optimal for many types of identities.
It was chosen to avoid identity type specific parsing and encoding It was chosen to avoid identity type specific parsing and encoding
code in implementations where the identity is configured by a person code in implementations where the identity is configured by a person
using some kind of management interface. Requiring such identity using some kind of management interface. Requiring such identity
type specific code would also increase the chances for type specific code would also increase the chances for
interoperability problems resulting from different implementations interoperability problems resulting from different implementations
skipping to change at page 9, line 18 skipping to change at page 9, line 18
TLS implementations supporting these ciphersuites MUST support TLS implementations supporting these ciphersuites MUST support
arbitrary PSK identities up to 128 octets in length, and arbitrary arbitrary PSK identities up to 128 octets in length, and arbitrary
PSKs up to 64 octets in length. Supporting longer identities and PSKs up to 64 octets in length. Supporting longer identities and
keys is RECOMMENDED. keys is RECOMMENDED.
5.4 Requirements for management interfaces 5.4 Requirements for management interfaces
In the absence of an application profile specification specifying In the absence of an application profile specification specifying
otherwise, a management interface for entering the PSK and/or PSK otherwise, a management interface for entering the PSK and/or PSK
identity MUST support entering PSK identities consisting of up to 128 identity MUST support the following:
printable ASCII characters, and MUST support entering PSKs up to 64
octets in length as ASCII strings and in hexadecimal encoding.
Supporting as wide character repertoire and as long identities and o Entering PSK identities consisting of up to 128 printable Unicode
keys as feasible is RECOMMENDED, as is processing the character characters. Supporting as wide character repertoire and as long
string with an appropriate stringprep [10] profile. identities as feasible is RECOMMENDED, as is processing the
character string with an appropriate stringprep [10] profile.
o Entering PSKs up to 64 octets in length as ASCII strings and in
hexadecimal encoding.
6. IANA considerations 6. IANA considerations
IANA does not currently have a registry for TLS-related numbers, so IANA does not currently have a registry for TLS-related numbers, so
there are no IANA actions associated with this document. there are no IANA actions associated with this document.
For easier reference in the future, the ciphersuite numbers defined For easier reference in the future, the ciphersuite numbers defined
in this document are summarized below. in this document are summarized below.
CipherSuite TLS_PSK_WITH_RC4_128_SHA = { 0x00, 0x8A }; CipherSuite TLS_PSK_WITH_RC4_128_SHA = { 0x00, 0x8A };
skipping to change at page 15, line 10 skipping to change at page 15, line 10
46 rue Barrault 46 rue Barrault
75634 Paris 75634 Paris
France France
Email: Ahmed.Serhrouchni@enst.fr Email: Ahmed.Serhrouchni@enst.fr
Appendix A. Changelog Appendix A. Changelog
(This section should be removed by the RFC Editor before (This section should be removed by the RFC Editor before
publication.) publication.)
Changes from -06 to -07:
o Small clarifications to management interface requirements.
Changes from -05 to -06: Changes from -05 to -06:
o Small clarifications to how the premaster secret is formed. o Small clarifications to how the premaster secret is formed.
o Added a section about conformance requirements, and moved existing o Added a section about conformance requirements, and moved existing
text about identity formats there. text about identity formats there.
Changes from -04 to -05: Changes from -04 to -05:
o Omit ServerKeyExchange message (in PSK/RSA_PSK versions) if no o Omit ServerKeyExchange message (in PSK/RSA_PSK versions) if no
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/