when the identity does not reveal any information itself, reusing the
same identity over time may eventually allow an attacker to perform
traffic analysis to identify the parties. It should be noted that
this is no worse than client certificates, since they are also sent
in cleartext.
7.4. Implementation Notes
The implementation notes in [TLS11] about correct implementation and
use of RSA (including Section 7.4.7.1) and Diffie-Hellman (including
Appendix F.1.1.3) apply to the DHE_PSK and RSA_PSK ciphersuites as
well.
8. Acknowledgements
The protocol defined in this document is heavily based on work by Tim
Dierks and Peter Gutmann, and borrows some text from [SHAREDKEYS] and
[AES]. The DHE_PSK and RSA_PSK ciphersuites are based on earlier
work in [KEYEX].
Valuable feedback was also provided by Bernard Aboba, Lakshminath
Dondeti, Philip Ginzboorg, Peter Gutmann, Sam Hartman, Russ Housley,
David Jablon, Nikos Mavroyanopoulos, Bodo Moeller, Eric Rescorla, and
Mika Tervonen.
When the first version of this document was almost ready, the authors
learned that something similar had been proposed already in 1996
[PASSAUTH]. However, this document is not intended for web password
authentication, but rather for other uses of TLS.
9. References
9.1. Normative References
[AES] Chown, P., "Advanced Encryption Standard (AES)
Ciphersuites for Transport Layer Security (TLS)", RFC
3268, June 2002.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RANDOMNESS] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC
4086, June 2005.
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
9.2. Informative References
[DNS] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[KERB] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
Suites to Transport Layer Security (TLS)", RFC 2712,
October 1999.
[KEYEX] Badra, M., Cherkaoui, O., Hajjeh, I. and A. Serhrouchni,
"Pre-Shared-Key key Exchange methods for TLS", Work in
Progress, August 2004.
[KRAWCZYK] Krawczyk, H., "Re: TLS shared keys PRF", message on
ietf-tls@lists.certicom.com mailing list 2004-01-13,
http://www.imc.org/ietf-tls/mail-archive/msg04098.html.
[LDAPDN] Zeilenga, K., "LDAP: String Representation of
Distinguished Names", Work in Progress, February 2005.
[NAMEPREP] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
Profile for Internationalized Domain Names (IDN)", RFC
3491, March 2003.
[PASSAUTH] Simon, D., "Addition of Shared Key Authentication to
Transport Layer Security (TLS)", Work in Progress,
November 1996.
[SASLPREP] Zeilenga, K., "SASLprep: Stringprep Profile for User
Names and Passwords", RFC 4013, February 2005.
[SHAREDKEYS] Gutmann, P., "Use of Shared Keys in the TLS Protocol",
Work in Progress, October 2003.
[SRP] Taylor, D., Wu, T., Mavroyanopoulos, N. and T. Perrin,
"Using SRP for TLS Authentication", Work in Progress,
March 2005.
[STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454,
December 2002.
[TLS11] Dierks, T. and E. Rescorla, "The TLS Protocol Version
1.1", Work in Progress, June 2005.
Authors’ and Contributors’ Addresses
Pasi Eronen
Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland
EMail: pasi.eronen@nokia.com
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
EMail: Hannes.Tschofenig@siemens.com
Mohamad Badra
ENST Paris
46 rue Barrault
75634 Paris
France
EMail: Mohamad.Badra@enst.fr
Omar Cherkaoui
UQAM University
Montreal (Quebec)
Canada
EMail: cherkaoui.omar@uqam.ca
Ibrahim Hajjeh
ESRGroups
17 passage Barrault
75013 Paris
France
EMail: Ibrahim.Hajjeh@esrgroups.org
Ahmed Serhrouchni
ENST Paris
46 rue Barrault
75634 Paris
France
EMail: Ahmed.Serhrouchni@enst.fr
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.