RFC4279 日本語訳
4279 Pre-Shared Key Ciphersuites for Transport Layer Security (TLS).P. Eronen, Ed., H. Tschofenig, Ed.. December 2005. (Format: TXT=32160 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Eronen, Ed.
Request for Comments: 4279 Nokia
Category: Standards Track H. Tschofenig, Ed.
Siemens
December 2005
Network Working Group P. Eronen, Ed. Request for Comments: 4279 Nokia Category: Standards Track H. Tschofenig, Ed. Siemens December 2005
Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
Status of This Memo
Status of This Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2005).
Copyright (C) The Internet Society (2005).
Abstract
Abstract
This document specifies three sets of new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys (PSKs). 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.
This document specifies three sets of new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys (PSKs). 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.
Eronen & Tschofenig Standards Track [Page 1] RFC 4279 PSK Ciphersuites for TLS December 2005
Eronen & Tschofenig Standards Track [Page 1] RFC 4279 PSK Ciphersuites for TLS December 2005
Table of Contents
Table of Contents
1. Introduction ....................................................2
1.1. Applicability Statement ....................................3
1.2. Conventions Used in This Document ..........................4
2. PSK Key Exchange Algorithm ......................................4
3. DHE_PSK Key Exchange Algorithm ..................................6
4. RSA_PSK Key Exchange Algorithm ..................................7
5. Conformance Requirements ........................................8
5.1. PSK Identity Encoding ......................................8
5.2. Identity Hint ..............................................9
5.3. Requirements for TLS Implementations .......................9
5.4. Requirements for Management Interfaces .....................9
6. IANA Considerations ............................................10
7. Security Considerations ........................................10
7.1. Perfect Forward Secrecy (PFS) .............................10
7.2. Brute-Force and Dictionary Attacks ........................10
7.3. Identity Privacy ..........................................11
7.4. Implementation Notes ......................................11
8. Acknowledgements ...............................................11
9. References .....................................................12
9.1. Normative References ......................................12
9.2. Informative References ....................................12
1. Introduction ....................................................2 1.1. Applicability Statement ....................................3 1.2. Conventions Used in This Document ..........................4 2. PSK Key Exchange Algorithm ......................................4 3. DHE_PSK Key Exchange Algorithm ..................................6 4. RSA_PSK Key Exchange Algorithm ..................................7 5. Conformance Requirements ........................................8 5.1. PSK Identity Encoding ......................................8 5.2. Identity Hint ..............................................9 5.3. Requirements for TLS Implementations .......................9 5.4. Requirements for Management Interfaces .....................9 6. IANA Considerations ............................................10 7. Security Considerations ........................................10 7.1. Perfect Forward Secrecy (PFS) .............................10 7.2. Brute-Force and Dictionary Attacks ........................10 7.3. Identity Privacy ..........................................11 7.4. Implementation Notes ......................................11 8. Acknowledgements ...............................................11 9. References .....................................................12 9.1. Normative References ......................................12 9.2. Informative References ....................................12
1. Introduction
1. Introduction
Usually, TLS uses public key certificates [TLS] or Kerberos [KERB] for authentication. This document describes how to use symmetric keys (later called pre-shared keys or PSKs), shared in advance among the communicating parties, to establish a TLS connection.
Usually, TLS uses public key certificates [TLS] or Kerberos [KERB] for authentication. This document describes how to use symmetric keys (later called pre-shared keys or PSKs), shared in advance among the communicating parties, to establish a TLS connection.
There are basically two reasons why one might want to do this:
There are basically two reasons why one might want to do this:
o First, using pre-shared keys can, depending on the ciphersuite,
avoid the need for public key operations. This is useful if TLS
is used in performance-constrained environments with limited CPU
power.
o First, using pre-shared keys can, depending on the ciphersuite, avoid the need for public key operations. This is useful if TLS is used in performance-constrained environments with limited CPU power.
o Second, pre-shared keys may be more convenient from a key
management point of view. For instance, in closed environments
where the connections are mostly configured manually in advance,
it may be easier to configure a PSK than to use certificates.
Another case is when the parties already have a mechanism for
setting up a shared secret key, and that mechanism could be used
to "bootstrap" a key for authenticating a TLS connection.
o Second, pre-shared keys may be more convenient from a key management point of view. For instance, in closed environments where the connections are mostly configured manually in advance, it may be easier to configure a PSK than to use certificates. Another case is when the parties already have a mechanism for setting up a shared secret key, and that mechanism could be used to "bootstrap" a key for authenticating a TLS connection.
Eronen & Tschofenig Standards Track [Page 2] RFC 4279 PSK Ciphersuites for TLS December 2005
Eronen & Tschofenig Standards Track [Page 2] RFC 4279 PSK Ciphersuites for TLS December 2005
This document specifies three sets of new ciphersuites for TLS. These ciphersuites use new key exchange algorithms, and reuse existing cipher and MAC algorithms from [TLS] and [AES]. A summary of these ciphersuites is shown below.
This document specifies three sets of new ciphersuites for TLS. These ciphersuites use new key exchange algorithms, and reuse existing cipher and MAC algorithms from [TLS] and [AES]. A summary of these ciphersuites is shown below.
CipherSuite Key Exchange Cipher Hash
CipherSuite Key Exchange Cipher Hash
TLS_PSK_WITH_RC4_128_SHA PSK RC4_128 SHA
TLS_PSK_WITH_3DES_EDE_CBC_SHA PSK 3DES_EDE_CBC SHA
TLS_PSK_WITH_AES_128_CBC_SHA PSK AES_128_CBC SHA
TLS_PSK_WITH_AES_256_CBC_SHA PSK AES_256_CBC SHA
TLS_DHE_PSK_WITH_RC4_128_SHA DHE_PSK RC4_128 SHA
TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA DHE_PSK 3DES_EDE_CBC SHA
TLS_DHE_PSK_WITH_AES_128_CBC_SHA DHE_PSK AES_128_CBC SHA
TLS_DHE_PSK_WITH_AES_256_CBC_SHA DHE_PSK AES_256_CBC SHA
TLS_RSA_PSK_WITH_RC4_128_SHA RSA_PSK RC4_128 SHA
TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA RSA_PSK 3DES_EDE_CBC SHA
TLS_RSA_PSK_WITH_AES_128_CBC_SHA RSA_PSK AES_128_CBC SHA
TLS_RSA_PSK_WITH_AES_256_CBC_SHA RSA_PSK AES_256_CBC SHA
TLS_PSK_WITH_RC4_128_SHA PSK RC4_128 SHA TLS_PSK_WITH_3DES_EDE_CBC_SHA PSK 3DES_EDE_CBC SHA TLS_PSK_WITH_AES_128_CBC_SHA PSK AES_128_CBC SHA TLS_PSK_WITH_AES_256_CBC_SHA PSK AES_256_CBC SHA TLS_DHE_PSK_WITH_RC4_128_SHA DHE_PSK RC4_128 SHA TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA DHE_PSK 3DES_EDE_CBC SHA TLS_DHE_PSK_WITH_AES_128_CBC_SHA DHE_PSK AES_128_CBC SHA TLS_DHE_PSK_WITH_AES_256_CBC_SHA DHE_PSK AES_256_CBC SHA TLS_RSA_PSK_WITH_RC4_128_SHA RSA_PSK RC4_128 SHA TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA RSA_PSK 3DES_EDE_CBC SHA TLS_RSA_PSK_WITH_AES_128_CBC_SHA RSA_PSK AES_128_CBC SHA TLS_RSA_PSK_WITH_AES_256_CBC_SHA RSA_PSK AES_256_CBC SHA
The ciphersuites in Section 2 (with PSK key exchange algorithm) use only symmetric key algorithms and are thus especially suitable for performance-constrained environments.
The ciphersuites in Section 2 (with PSK key exchange algorithm) use only symmetric key algorithms and are thus especially suitable for performance-constrained environments.
The ciphersuites in Section 3 (with DHE_PSK key exchange algorithm) use a PSK to authenticate a Diffie-Hellman exchange. These ciphersuites protect against dictionary attacks by passive eavesdroppers (but not active attackers) and also provide Perfect Forward Secrecy (PFS).
The ciphersuites in Section 3 (with DHE_PSK key exchange algorithm) use a PSK to authenticate a Diffie-Hellman exchange. These ciphersuites protect against dictionary attacks by passive eavesdroppers (but not active attackers) and also provide Perfect Forward Secrecy (PFS).
The ciphersuites in Section 4 (with RSA_PSK key exchange algorithm) combine public-key-based authentication of the server (using RSA and certificates) with mutual authentication using a PSK.
The ciphersuites in Section 4 (with RSA_PSK key exchange algorithm) combine public-key-based authentication of the server (using RSA and certificates) with mutual authentication using a PSK.
1.1. Applicability Statement
1.1. Applicability Statement
The ciphersuites defined in this document are intended for a rather limited set of applications, usually involving only a very small number of clients and servers. Even in such environments, other alternatives may be more appropriate.
The ciphersuites defined in this document are intended for a rather limited set of applications, usually involving only a very small number of clients and servers. Even in such environments, other alternatives may be more appropriate.
If the main goal is to avoid Public-Key Infrastructures (PKIs), another possibility worth considering is using self-signed certificates with public key fingerprints. Instead of manually configuring a shared secret in, for instance, some configuration file, a fingerprint (hash) of the other party's public key (or certificate) could be placed there instead.
If the main goal is to avoid Public-Key Infrastructures (PKIs), another possibility worth considering is using self-signed certificates with public key fingerprints. Instead of manually configuring a shared secret in, for instance, some configuration file, a fingerprint (hash) of the other party's public key (or certificate) could be placed there instead.
Eronen & Tschofenig Standards Track [Page 3] RFC 4279 PSK Ciphersuites for TLS December 2005
Eronen & Tschofenig Standards Track [Page 3] RFC 4279 PSK Ciphersuites for TLS December 2005
It is also possible to use the SRP (Secure Remote Password) ciphersuites for shared secret authentication [SRP]. SRP was designed to be used with passwords, and it incorporates protection against dictionary attacks. However, it is computationally more expensive than the PSK ciphersuites in Section 2.
It is also possible to use the SRP (Secure Remote Password) ciphersuites for shared secret authentication [SRP]. SRP was designed to be used with passwords, and it incorporates protection against dictionary attacks. However, it is computationally more expensive than the PSK ciphersuites in Section 2.
1.2. Conventions Used in This Document
1.2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
2. PSK Key Exchange Algorithm
2. PSK Key Exchange Algorithm
This section defines the PSK key exchange algorithm and associated ciphersuites. These ciphersuites use only symmetric key algorithms.
This section defines the PSK key exchange algorithm and associated ciphersuites. These ciphersuites use only symmetric key algorithms.
It is assumed that the reader is familiar with the ordinary TLS handshake, shown below. The elements in parenthesis are not included when the PSK key exchange algorithm is used, and "*" indicates a situation-dependent message that is not always sent.
It is assumed that the reader is familiar with the ordinary TLS handshake, shown below. The elements in parenthesis are not included when the PSK key exchange algorithm is used, and "*" indicates a situation-dependent message that is not always sent.
Client Server
------ ------
Client Server ------ ------
ClientHello -------->
ServerHello
(Certificate)
ServerKeyExchange*
(CertificateRequest)
<-------- ServerHelloDone
(Certificate)
ClientKeyExchange
(CertificateVerify)
ChangeCipherSpec
Finished -------->
ChangeCipherSpec
<-------- Finished
Application Data <-------> Application Data
ClientHello --------> ServerHello (Certificate) ServerKeyExchange* (CertificateRequest) <-------- ServerHelloDone (Certificate) ClientKeyExchange (CertificateVerify) ChangeCipherSpec Finished --------> ChangeCipherSpec <-------- Finished Application Data <-------> Application Data
The client indicates its willingness to use pre-shared key authentication by including one or more PSK ciphersuites in the ClientHello message. If the TLS server also wants to use pre-shared keys, it selects one of the PSK ciphersuites, places the selected ciphersuite in the ServerHello message, and includes an appropriate ServerKeyExchange message (see below). The Certificate and CertificateRequest payloads are omitted from the response.
The client indicates its willingness to use pre-shared key authentication by including one or more PSK ciphersuites in the ClientHello message. If the TLS server also wants to use pre-shared keys, it selects one of the PSK ciphersuites, places the selected ciphersuite in the ServerHello message, and includes an appropriate ServerKeyExchange message (see below). The Certificate and CertificateRequest payloads are omitted from the response.
Eronen & Tschofenig Standards Track [Page 4] RFC 4279 PSK Ciphersuites for TLS December 2005
Eronen & Tschofenig Standards Track [Page 4] RFC 4279 PSK Ciphersuites for TLS December 2005
Both clients and servers may have pre-shared keys with several different parties. The client indicates which key to use by including a "PSK identity" in the ClientKeyExchange message (note that unlike in [SHAREDKEYS], the session_id field in ClientHello message keeps its usual meaning). To help the client in selecting which identity to use, the server can provide a "PSK identity hint" in the ServerKeyExchange message. If no hint is provided, the ServerKeyExchange message is omitted. See Section 5 for a more detailed description of these fields.
Both clients and servers may have pre-shared keys with several different parties. The client indicates which key to use by including a "PSK identity" in the ClientKeyExchange message (note that unlike in [SHAREDKEYS], the session_id field in ClientHello message keeps its usual meaning). To help the client in selecting which identity to use, the server can provide a "PSK identity hint" in the ServerKeyExchange message. If no hint is provided, the ServerKeyExchange message is omitted. See Section 5 for a more detailed description of these fields.
The format of the ServerKeyExchange and ClientKeyExchange messages is shown below.
The format of the ServerKeyExchange and ClientKeyExchange messages is shown below.
struct {
select (KeyExchangeAlgorithm) {
/* other cases for rsa, diffie_hellman, etc. */
case psk: /* NEW */
opaque psk_identity_hint<0..2^16-1>;
};
} ServerKeyExchange;
struct { select (KeyExchangeAlgorithm) { /* other cases for rsa, diffie_hellman, etc. */ case psk: /* NEW */ opaque psk_identity_hint<0..2^16-1>; }; } ServerKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
/* other cases for rsa, diffie_hellman, etc. */
case psk: /* NEW */
opaque psk_identity<0..2^16-1>;
} exchange_keys;
} ClientKeyExchange;
struct { select (KeyExchangeAlgorithm) { /* other cases for rsa, diffie_hellman, etc. */ case psk: /* NEW */ opaque psk_identity<0..2^16-1>; } exchange_keys; } ClientKeyExchange;
The premaster secret is formed as follows: if the PSK is N octets long, concatenate a uint16 with the value N, N zero octets, a second uint16 with the value N, and the PSK itself.
The premaster secret is formed as follows: if the PSK is N octets long, concatenate a uint16 with the value N, N zero octets, a second uint16 with the value N, and the PSK itself.
Note 1: All the ciphersuites in this document share the same
general structure for the premaster secret, namely,
Note 1: All the ciphersuites in this document share the same general structure for the premaster secret, namely,
struct {
opaque other_secret<0..2^16-1>;
opaque psk<0..2^16-1>;
};
struct { opaque other_secret<0..2^16-1>; opaque psk<0..2^16-1>; };
Here "other_secret" either is zeroes (plain PSK case) or comes
from the Diffie-Hellman or RSA exchange (DHE_PSK and RSA_PSK,
respectively). See Sections 3 and 4 for a more detailed
description.
Here "other_secret" either is zeroes (plain PSK case) or comes from the Diffie-Hellman or RSA exchange (DHE_PSK and RSA_PSK, respectively). See Sections 3 and 4 for a more detailed description.
Note 2: Using zeroes for "other_secret" effectively means that
only the HMAC-SHA1 part (but not the HMAC-MD5 part) of the TLS PRF
Note 2: Using zeroes for "other_secret" effectively means that only the HMAC-SHA1 part (but not the HMAC-MD5 part) of the TLS PRF
Eronen & Tschofenig Standards Track [Page 5] RFC 4279 PSK Ciphersuites for TLS December 2005
Eronen & Tschofenig Standards Track [Page 5] RFC 4279 PSK Ciphersuites for TLS December 2005
is used when constructing the master secret. This was considered
more elegant from an analytical viewpoint than, for instance,
using the same key for both the HMAC-MD5 and HMAC-SHA1 parts. See
[KRAWCZYK] for a more detailed rationale.
is used when constructing the master secret. This was considered more elegant from an analytical viewpoint than, for instance, using the same key for both the HMAC-MD5 and HMAC-SHA1 parts. See [KRAWCZYK] for a more detailed rationale.
The TLS handshake is authenticated using the Finished messages as usual.
The TLS handshake is authenticated using the Finished messages as usual.
If the server does not recognize the PSK identity, it MAY respond with an "unknown_psk_identity" alert message. Alternatively, if the server wishes to hide the fact that the PSK identity was not known, it MAY continue the protocol as if the PSK identity existed but the key was incorrect: that is, respond with a "decrypt_error" alert.
If the server does not recognize the PSK identity, it MAY respond with an "unknown_psk_identity" alert message. Alternatively, if the server wishes to hide the fact that the PSK identity was not known, it MAY continue the protocol as if the PSK identity existed but the key was incorrect: that is, respond with a "decrypt_error" alert.
3. DHE_PSK Key Exchange Algorithm
3. DHE_PSK Key Exchange Algorithm
This section defines additional ciphersuites that use a PSK to authenticate a Diffie-Hellman exchange. These ciphersuites give some additional protection against dictionary attacks and also provide Perfect Forward Secrecy (PFS). See Section 7 for discussion of related security considerations.
This section defines additional ciphersuites that use a PSK to authenticate a Diffie-Hellman exchange. These ciphersuites give some additional protection against dictionary attacks and also provide Perfect Forward Secrecy (PFS). See Section 7 for discussion of related security considerations.
When these ciphersuites are used, the ServerKeyExchange and ClientKeyExchange messages also include the Diffie-Hellman parameters. The PSK identity and identity hint fields have the same meaning as in the previous section (note that the ServerKeyExchange message is always sent, even if no PSK identity hint is provided).
When these ciphersuites are used, the ServerKeyExchange and ClientKeyExchange messages also include the Diffie-Hellman parameters. The PSK identity and identity hint fields have the same meaning as in the previous section (note that the ServerKeyExchange message is always sent, even if no PSK identity hint is provided).
The format of the ServerKeyExchange and ClientKeyExchange messages is shown below.
The format of the ServerKeyExchange and ClientKeyExchange messages is shown below.
struct {
select (KeyExchangeAlgorithm) {
/* other cases for rsa, diffie_hellman, etc. */
case diffie_hellman_psk: /* NEW */
opaque psk_identity_hint<0..2^16-1>;
ServerDHParams params;
};
} ServerKeyExchange;
struct { select (KeyExchangeAlgorithm) { /* other cases for rsa, diffie_hellman, etc. */ case diffie_hellman_psk: /* NEW */ opaque psk_identity_hint<0..2^16-1>; ServerDHParams params; }; } ServerKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
/* other cases for rsa, diffie_hellman, etc. */
case diffie_hellman_psk: /* NEW */
opaque psk_identity<0..2^16-1>;
ClientDiffieHellmanPublic public;
} exchange_keys;
} ClientKeyExchange;
struct { select (KeyExchangeAlgorithm) { /* other cases for rsa, diffie_hellman, etc. */ case diffie_hellman_psk: /* NEW */ opaque psk_identity<0..2^16-1>; ClientDiffieHellmanPublic public; } exchange_keys; } ClientKeyExchange;
Eronen & Tschofenig Standards Track [Page 6] RFC 4279 PSK Ciphersuites for TLS December 2005
Eronen & Tschofenig Standards Track [Page 6] RFC 4279 PSK Ciphersuites for TLS December 2005
The premaster secret is formed as follows. First, perform the Diffie-Hellman computation in the same way as for other Diffie-Hellman-based ciphersuites in [TLS]. Let Z be the value produced by this computation (with leading zero bytes stripped as in other Diffie-Hellman-based ciphersuites). Concatenate a uint16 containing the length of Z (in octets), Z itself, a uint16 containing the length of the PSK (in octets), and the PSK itself.
The premaster secret is formed as follows. First, perform the Diffie-Hellman computation in the same way as for other Diffie-Hellman-based ciphersuites in [TLS]. Let Z be the value produced by this computation (with leading zero bytes stripped as in other Diffie-Hellman-based ciphersuites). Concatenate a uint16 containing the length of Z (in octets), Z itself, a uint16 containing the length of the PSK (in octets), and the PSK itself.
This corresponds to the general structure for the premaster secrets (see Note 1 in Section 2) in this document, with "other_secret" containing Z.
This corresponds to the general structure for the premaster secrets (see Note 1 in Section 2) in this document, with "other_secret" containing Z.
4. RSA_PSK Key Exchange Algorithm
4. RSA_PSK Key Exchange Algorithm
The ciphersuites in this section use RSA and certificates to authenticate the server, in addition to using a PSK.
The ciphersuites in this section use RSA and certificates to authenticate the server, in addition to using a PSK.
As in normal RSA ciphersuites, the server must send a Certificate message. The format of the ServerKeyExchange and ClientKeyExchange messages is shown below. If no PSK identity hint is provided, the ServerKeyExchange message is omitted.
As in normal RSA ciphersuites, the server must send a Certificate message. The format of the ServerKeyExchange and ClientKeyExchange messages is shown below. If no PSK identity hint is provided, the ServerKeyExchange message is omitted.
struct {
select (KeyExchangeAlgorithm) {
/* other cases for rsa, diffie_hellman, etc. */
case rsa_psk: /* NEW */
opaque psk_identity_hint<0..2^16-1>;
};
} ServerKeyExchange;
struct { select (KeyExchangeAlgorithm) { /* other cases for rsa, diffie_hellman, etc. */ case rsa_psk: /* NEW */ opaque psk_identity_hint<0..2^16-1>; }; } ServerKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
/* other cases for rsa, diffie_hellman, etc. */
case rsa_psk: /* NEW */
opaque psk_identity<0..2^16-1>;
EncryptedPreMasterSecret;
} exchange_keys;
} ClientKeyExchange;
struct { select (KeyExchangeAlgorithm) { /* other cases for rsa, diffie_hellman, etc. */ case rsa_psk: /* NEW */ opaque psk_identity<0..2^16-1>; EncryptedPreMasterSecret; } exchange_keys; } ClientKeyExchange;
The EncryptedPreMasterSecret field sent from the client to the server contains a 2-byte version number and a 46-byte random value, encrypted using the server's RSA public key as described in Section 7.4.7.1 of [TLS]. The actual premaster secret is formed by both parties as follows: concatenate a uint16 with the value 48, the 2-byte version number and the 46-byte random value, a uint16 containing the length of the PSK (in octets), and the PSK itself. (The premaster secret is thus 52 octets longer than the PSK.)
The EncryptedPreMasterSecret field sent from the client to the server contains a 2-byte version number and a 46-byte random value, encrypted using the server's RSA public key as described in Section 7.4.7.1 of [TLS]. The actual premaster secret is formed by both parties as follows: concatenate a uint16 with the value 48, the 2-byte version number and the 46-byte random value, a uint16 containing the length of the PSK (in octets), and the PSK itself. (The premaster secret is thus 52 octets longer than the PSK.)
Eronen & Tschofenig Standards Track [Page 7] RFC 4279 PSK Ciphersuites for TLS December 2005
Eronen & Tschofenig Standards Track [Page 7] RFC 4279 PSK Ciphersuites for TLS December 2005
This corresponds to the general structure for the premaster secrets (see Note 1 in Section 2) in this document, with "other_secret" containing both the 2-byte version number and the 46-byte random value.
This corresponds to the general structure for the premaster secrets (see Note 1 in Section 2) in this document, with "other_secret" containing both the 2-byte version number and the 46-byte random value.
Neither the normal RSA ciphersuites nor these RSA_PSK ciphersuites themselves specify what the certificates contain (in addition to the RSA public key), or how the certificates are to be validated. In particular, it is possible to use the RSA_PSK ciphersuites with unvalidated self-signed certificates to provide somewhat similar protection against dictionary attacks, as the DHE_PSK ciphersuites define in Section 3.
Neither the normal RSA ciphersuites nor these RSA_PSK ciphersuites themselves specify what the certificates contain (in addition to the RSA public key), or how the certificates are to be validated. In particular, it is possible to use the RSA_PSK ciphersuites with unvalidated self-signed certificates to provide somewhat similar protection against dictionary attacks, as the DHE_PSK ciphersuites define in Section 3.
5. Conformance Requirements
5. Conformance Requirements
It is expected that different types of identities are useful for different applications running over TLS. This document does not therefore mandate the use of any particular type of identity (such as IPv4 address or Fully Qualified Domain Name (FQDN)).
It is expected that different types of identities are useful for different applications running over TLS. This document does not therefore mandate the use of any particular type of identity (such as IPv4 address or Fully Qualified Domain Name (FQDN)).
However, the TLS client and server clearly have to agree on the identities and keys to be used. To improve interoperability, this document places requirements on how the identity is encoded in the protocol, and what kinds of identities and keys implementations have to support.
However, the TLS client and server clearly have to agree on the identities and keys to be used. To improve interoperability, this document places requirements on how the identity is encoded in the protocol, and what kinds of identities and keys implementations have to support.
The requirements for implementations are divided into two categories, requirements for TLS implementations and management interfaces. In this context, "TLS implementation" refers to a TLS library or module that is intended to be used for several different purposes, while "management interface" would typically be implemented by a particular application that uses TLS.
The requirements for implementations are divided into two categories, requirements for TLS implementations and management interfaces. In this context, "TLS implementation" refers to a TLS library or module that is intended to be used for several different purposes, while "management interface" would typically be implemented by a particular application that uses TLS.
This document does not specify how the server stores the keys and identities, or how exactly it finds the key corresponding to the identity it receives. For instance, if the identity is a domain name, it might be appropriate to do a case-insensitive lookup. It is RECOMMENDED that before looking up the key, the server processes the PSK identity with a stringprep profile [STRINGPREP] appropriate for the identity in question (such as Nameprep [NAMEPREP] for components of domain names or SASLprep for usernames [SASLPREP]).
This document does not specify how the server stores the keys and identities, or how exactly it finds the key corresponding to the identity it receives. For instance, if the identity is a domain name, it might be appropriate to do a case-insensitive lookup. It is RECOMMENDED that before looking up the key, the server processes the PSK identity with a stringprep profile [STRINGPREP] appropriate for the identity in question (such as Nameprep [NAMEPREP] for components of domain names or SASLprep for usernames [SASLPREP]).
5.1. PSK Identity Encoding
5.1. PSK Identity Encoding
The PSK identity MUST be first converted to a character string, and then encoded to octets using UTF-8 [UTF8]. For instance,
The PSK identity MUST be first converted to a character string, and then encoded to octets using UTF-8 [UTF8]. For instance,
Eronen & Tschofenig Standards Track [Page 8] RFC 4279 PSK Ciphersuites for TLS December 2005
Eronen & Tschofenig Standards Track [Page 8] RFC 4279 PSK Ciphersuites for TLS December 2005
o IPv4 addresses are sent as dotted-decimal strings (e.g.,
"192.0.2.1"), not as 32-bit integers in network byte order.
o IPv4 addresses are sent as dotted-decimal strings (e.g., "192.0.2.1"), not as 32-bit integers in network byte order.
o Domain names are sent in their usual text form [DNS] (e.g.,
"www.example.com" or "embedded\.dot.example.net"), not in DNS
protocol format.
o Domain names are sent in their usual text form [DNS] (e.g., "www.example.com" or "embedded\.dot.example.net"), not in DNS protocol format.
o X.500 Distinguished Names are sent in their string representation
[LDAPDN], not as BER-encoded ASN.1.
o X.500 Distinguished Names are sent in their string representation [LDAPDN], not as BER-encoded ASN.1.
This encoding is clearly not optimal for many types of identities. It was chosen to avoid identity-type-specific parsing and encoding code in implementations where the identity is configured by a person using some kind of management interface. Requiring such identity- type-specific code would also increase the chances for interoperability problems resulting from different implementations supporting different identity types.
This encoding is clearly not optimal for many types of identities. It was chosen to avoid identity-type-specific parsing and encoding code in implementations where the identity is configured by a person using some kind of management interface. Requiring such identity- type-specific code would also increase the chances for interoperability problems resulting from different implementations supporting different identity types.
5.2. Identity Hint
5.2. Identity Hint
In the absence of an application profile specification specifying otherwise, servers SHOULD NOT provide an identity hint and clients MUST ignore the identity hint field. Applications that do use this field MUST specify its contents, how the value is chosen by the TLS server, and what the TLS client is expected to do with the value.
In the absence of an application profile specification specifying otherwise, servers SHOULD NOT provide an identity hint and clients MUST ignore the identity hint field. Applications that do use this field MUST specify its contents, how the value is chosen by the TLS server, and what the TLS client is expected to do with the value.
5.3. Requirements for TLS Implementations
5.3. Requirements for TLS Implementations
TLS implementations supporting these ciphersuites MUST support arbitrary PSK identities up to 128 octets in length, and arbitrary PSKs up to 64 octets in length. Supporting longer identities and keys is RECOMMENDED.
TLS implementations supporting these ciphersuites MUST support arbitrary PSK identities up to 128 octets in length, and arbitrary PSKs up to 64 octets in length. Supporting longer identities and keys is RECOMMENDED.
5.4. Requirements for Management Interfaces
5.4. Requirements for Management Interfaces
In the absence of an application profile specification specifying otherwise, a management interface for entering the PSK and/or PSK identity MUST support the following:
In the absence of an application profile specification specifying otherwise, a management interface for entering the PSK and/or PSK identity MUST support the following:
o Entering PSK identities consisting of up to 128 printable Unicode
characters. Supporting as wide a character repertoire and as long
identities as feasible is RECOMMENDED.
o Entering PSK identities consisting of up to 128 printable Unicode characters. Supporting as wide a character repertoire and as long identities as feasible is RECOMMENDED.
o Entering PSKs up to 64 octets in length as ASCII strings and in
hexadecimal encoding.
o Entering PSKs up to 64 octets in length as ASCII strings and in hexadecimal encoding.
Eronen & Tschofenig Standards Track [Page 9] RFC 4279 PSK Ciphersuites for TLS December 2005
Eronen & Tschofenig Standards Track [Page 9] RFC 4279 PSK Ciphersuites for TLS December 2005
6. IANA Considerations
6. IANA Considerations
IANA does not currently have a registry for TLS ciphersuite or alert numbers, so there are no IANA actions associated with this document.
IANA does not currently have a registry for TLS ciphersuite or alert numbers, so there are no IANA actions associated with this document.
For easier reference in the future, the ciphersuite numbers defined in this document are summarized below.
For easier reference in the future, the ciphersuite numbers defined in this document are summarized below.
CipherSuite TLS_PSK_WITH_RC4_128_SHA = { 0x00, 0x8A };
CipherSuite TLS_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x8B };
CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0x8C };
CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0x8D };
CipherSuite TLS_DHE_PSK_WITH_RC4_128_SHA = { 0x00, 0x8E };
CipherSuite TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x8F };
CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0x90 };
CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0x91 };
CipherSuite TLS_RSA_PSK_WITH_RC4_128_SHA = { 0x00, 0x92 };
CipherSuite TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x93 };
CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0x94 };
CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0x95 };
CipherSuite TLS_PSK_WITH_RC4_128_SHA = { 0x00, 0x8A }; CipherSuite TLS_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x8B }; CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0x8C }; CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0x8D }; CipherSuite TLS_DHE_PSK_WITH_RC4_128_SHA = { 0x00, 0x8E }; CipherSuite TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x8F }; CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0x90 }; CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0x91 }; CipherSuite TLS_RSA_PSK_WITH_RC4_128_SHA = { 0x00, 0x92 }; CipherSuite TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x93 }; CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0x94 }; CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0x95 };
This document also defines a new TLS alert message, unknown_psk_identity(115).
This document also defines a new TLS alert message, unknown_psk_identity(115).
7. Security Considerations
7. Security Considerations
As with all schemes involving shared keys, special care should be taken to protect the shared values and to limit their exposure over time.
As with all schemes involving shared keys, special care should be taken to protect the shared values and to limit their exposure over time.
7.1. Perfect Forward Secrecy (PFS)
7.1. Perfect Forward Secrecy (PFS)
The PSK and RSA_PSK ciphersuites defined in this document do not provide Perfect Forward Secrecy (PFS). That is, if the shared secret key (in PSK ciphersuites), or both the shared secret key and the RSA private key (in RSA_PSK ciphersuites), is somehow compromised, an attacker can decrypt old conversations.
The PSK and RSA_PSK ciphersuites defined in this document do not provide Perfect Forward Secrecy (PFS). That is, if the shared secret key (in PSK ciphersuites), or both the shared secret key and the RSA private key (in RSA_PSK ciphersuites), is somehow compromised, an attacker can decrypt old conversations.
The DHE_PSK ciphersuites provide Perfect Forward Secrecy if a fresh Diffie-Hellman private key is generated for each handshake.
The DHE_PSK ciphersuites provide Perfect Forward Secrecy if a fresh Diffie-Hellman private key is generated for each handshake.
7.2. Brute-Force and Dictionary Attacks
7.2. Brute-Force and Dictionary Attacks
Use of a fixed shared secret of limited entropy (for example, a PSK that is relatively short, or was chosen by a human and thus may contain less entropy than its length would imply) may allow an attacker to perform a brute-force or dictionary attack to recover the secret. This may be either an off-line attack (against a captured
Use of a fixed shared secret of limited entropy (for example, a PSK that is relatively short, or was chosen by a human and thus may contain less entropy than its length would imply) may allow an attacker to perform a brute-force or dictionary attack to recover the secret. This may be either an off-line attack (against a captured
Eronen & Tschofenig Standards Track [Page 10] RFC 4279 PSK Ciphersuites for TLS December 2005
Eronen & Tschofenig Standards Track [Page 10] RFC 4279 PSK Ciphersuites for TLS December 2005
TLS handshake messages) or an on-line attack where the attacker attempts to connect to the server and tries different keys.
TLS handshake messages) or an on-line attack where the attacker attempts to connect to the server and tries different keys.
For the PSK ciphersuites, an attacker can get the information required for an off-line attack by eavesdropping on a TLS handshake, or by getting a valid client to attempt connection with the attacker (by tricking the client to connect to the wrong address, or by intercepting a connection attempt to the correct address, for instance).
For the PSK ciphersuites, an attacker can get the information required for an off-line attack by eavesdropping on a TLS handshake, or by getting a valid client to attempt connection with the attacker (by tricking the client to connect to the wrong address, or by intercepting a connection attempt to the correct address, for instance).
For the DHE_PSK ciphersuites, an attacker can obtain the information by getting a valid client to attempt connection with the attacker. Passive eavesdropping alone is not sufficient.
For the DHE_PSK ciphersuites, an attacker can obtain the information by getting a valid client to attempt connection with the attacker. Passive eavesdropping alone is not sufficient.
For the RSA_PSK ciphersuites, only the server (authenticated using RSA and certificates) can obtain sufficient information for an off-line attack.
For the RSA_PSK ciphersuites, only the server (authenticated using RSA and certificates) can obtain sufficient information for an off-line attack.
It is RECOMMENDED that implementations that allow the administrator to manually configure the PSK also provide a functionality for generating a new random PSK, taking [RANDOMNESS] into account.
It is RECOMMENDED that implementations that allow the administrator to manually configure the PSK also provide a functionality for generating a new random PSK, taking [RANDOMNESS] into account.
7.3. Identity Privacy
7.3. Identity Privacy
The PSK identity is sent in cleartext. Although using a user name or other similar string as the PSK identity is the most straightforward option, it may lead to problems in some environments since an eavesdropper is able to identify the communicating parties. Even 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.
cleartextでPSKのアイデンティティを送ります。 PSKのアイデンティティが最も簡単なオプションであるのでユーザ名か他の同様のストリングを使用しますが、立ち聞きする者が交信パーティーを特定できるので、それはいくつかの環境における問題を引き起こすかもしれません。 アイデンティティが結局少しの情報自体も明らかにしないときさえ、時間がたつにつれて同じアイデンティティを再利用するのに、攻撃者は、パーティーを特定するためにトラヒック分析を実行できるかもしれません。 また、cleartextでそれらを送るので、これがクライアント証明書ほど悪くないのが有名であるべきです。
7.4. Implementation Notes
7.4. 実現注意
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.
実現は[TLS11]でRSAのほとんど正しい実現と使用に注意します。(.1と)ディフィー-ヘルマン(Appendix F.1.1.3を含んでいる)がまた、DHE_PSKとRSA_PSK ciphersuitesに適用するセクション7.4.7を含んでいます。
8. Acknowledgements
8. 承認
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].
本書では定義されたプロトコルは、ティムDierksとピーター・ガットマンによってずっしりと仕事に基礎づけられていて、[SHAREDKEYS]と[AES]から何らかのテキストを借ります。 DHE_PSKとRSA_PSK ciphersuitesは[KEYEX]で以前の仕事に基づいています。
Eronen & Tschofenig Standards Track [Page 11] RFC 4279 PSK Ciphersuites for TLS December 2005
Eronen&Tschofenig規格は2005年12月にTLSのためにRFC4279PSK Ciphersuitesを追跡します[11ページ]。
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.
また、有益なフィードバックはニコスMavroyanopoulos、ボーデのバーナードAboba、Lakshminath Dondeti、フィリップGinzboorg、ピーター・ガットマン、サム・ハートマン、ラスHousley、デヴィッドJablon、メラー、エリック・レスコラ、およびミカ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.
このドキュメントの最初のバージョンがほとんど準備ができていたとき、作者は、何か同様のものが既に1996年[PASSAUTH]に提案されたことを学びました。 しかしながら、このドキュメントはウェブパスワード認証のために意図するのではなく、むしろTLSの他の用途のために意図します。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[AES] Chown, P., "Advanced Encryption Standard (AES)
Ciphersuites for Transport Layer Security (TLS)", RFC
3268, June 2002.
[AES]Chown、2002年6月のP.、「トランスポート層セキュリティ(TLS)のためのエー・イー・エス(AES)Ciphersuites」RFC3268。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RANDOMNESS] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC
4086, June 2005.
[偶発性] イーストレークとD.と3番目、シラー、J.とS.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[TLS] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[UTF8]Yergeau、F.、「UTF-8、ISO10646の変化形式」STD63、RFC3629、11月2003日
9.2. Informative References
9.2. 有益な参照
[DNS] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[DNS]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日
[KERB] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
Suites to Transport Layer Security (TLS)", RFC 2712,
October 1999.
[縁石]Medvinsky、A.、およびM.Hur、「トランスポート層セキュリティ(TLS)へのケルベロス暗号スイートの添加」、RFC2712、1999年10月。
[KEYEX] Badra, M., Cherkaoui, O., Hajjeh, I. and A. Serhrouchni,
"Pre-Shared-Key key Exchange methods for TLS", Work in
Progress, August 2004.
Progress(2004年8月)の[KEYEX]BadraとM.とCherkaouiとO.とHajjehとI.とA.Serhrouchni、「SharedのプレキーのTLSに、主要なExchange方法」、Work。
[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.
[KRAWCZYK] Krawczyk、H.、「Re:」 「TLSの分配しているキーPRF」は ietf-tls@lists.certicom.com メーリングリストで2004年1月13日、 http://www.imc.org/ietf-tls/mail-archive/msg04098.html を通信させます。
Eronen & Tschofenig Standards Track [Page 12] RFC 4279 PSK Ciphersuites for TLS December 2005
Eronen&Tschofenig規格は2005年12月にTLSのためにRFC4279PSK Ciphersuitesを追跡します[12ページ]。
[LDAPDN] Zeilenga, K., "LDAP: String Representation of
Distinguished Names", Work in Progress, February 2005.
[LDAPDN]Zeilenga、K.、「LDAP:」 「分類名のストリング表現」、処理中の作業、2005年2月。
[NAMEPREP] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
Profile for Internationalized Domain Names (IDN)", RFC
3491, March 2003.
[NAMEPREP] ホフマン、P.、およびM.Blanchet、「Nameprep:」 「国際化ドメイン名(IDN)のためのStringprepプロフィール」、RFC3491、2003年3月。
[PASSAUTH] Simon, D., "Addition of Shared Key Authentication to
Transport Layer Security (TLS)", Work in Progress,
November 1996.
[PASSAUTH] サイモン、D.、「トランスポート層セキュリティ(TLS)への共有された主要な認証の添加」、処理中の作業、1996年11月。
[SASLPREP] Zeilenga, K., "SASLprep: Stringprep Profile for User
Names and Passwords", RFC 4013, February 2005.
[SASLPREP]Zeilenga、K.、「SASLprep:」 「ユーザ名とパスワードのためのStringprepプロフィール」、RFC4013、2005年2月。
[SHAREDKEYS] Gutmann, P., "Use of Shared Keys in the TLS Protocol",
Work in Progress, October 2003.
「TLSプロトコルにおける共有されたキーの使用」という[SHAREDKEYS]ガットマン、P.は進歩、2003年10月に働いています。
[SRP] Taylor, D., Wu, T., Mavroyanopoulos, N. and T. Perrin,
"Using SRP for TLS Authentication", Work in Progress,
March 2005.
[SRP] 「TLS認証にSRPを使用し」て、テイラー、D.、ウー、T.、Mavroyanopoulos、N.、およびT.ペランは進歩、2005年3月に働いています。
[STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454,
December 2002.
[STRINGPREP] ホフマンとP.とM.Blanchet、「国際化しているストリング("stringprep")の準備」、RFC3454、2002年12月。
[TLS11] Dierks, T. and E. Rescorla, "The TLS Protocol Version
1.1", Work in Progress, June 2005.
[TLS11] Dierks、T.、およびE.レスコラ、「TLSは2005年6月にバージョン1.1インチ、処理中の作業について議定書の中で述べます」。
Authors' and Contributors' Addresses
作者と貢献者のアドレス
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland
パシEronenノキアリサーチセンター私書箱407フィン-00045Nokia Groupフィンランド
EMail: pasi.eronen@nokia.com
メール: pasi.eronen@nokia.com
Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany
ミュンヘン、ハンネスTschofenigシーメンスオットーハーン一味6バイエルン81739ドイツ
EMail: Hannes.Tschofenig@siemens.com
メール: Hannes.Tschofenig@siemens.com
Eronen & Tschofenig Standards Track [Page 13] RFC 4279 PSK Ciphersuites for TLS December 2005
Eronen&Tschofenig規格は2005年12月にTLSのためにRFC4279PSK Ciphersuitesを追跡します[13ページ]。
Mohamad Badra ENST Paris 46 rue Barrault 75634 Paris France
モハマド・Badra ENSTパリ46はバロー75634・パリフランスを悔悟します。
EMail: Mohamad.Badra@enst.fr
メール: Mohamad.Badra@enst.fr
Omar Cherkaoui UQAM University Montreal (Quebec) Canada
オマー・Cherkaoui UQAM大学モントリオール(ケベック)カナダ
EMail: cherkaoui.omar@uqam.ca
メール: cherkaoui.omar@uqam.ca
Ibrahim Hajjeh ESRGroups 17 passage Barrault 75013 Paris France
イブラヒムHajjeh ESRGroups17通路バロー75013パリフランス
EMail: Ibrahim.Hajjeh@esrgroups.org
メール: Ibrahim.Hajjeh@esrgroups.org
Ahmed Serhrouchni ENST Paris 46 rue Barrault 75634 Paris France
アフマド・Serhrouchni ENSTパリ46はバロー75634・パリフランスを悔悟します。
EMail: Ahmed.Serhrouchni@enst.fr
メール: Ahmed.Serhrouchni@enst.fr
Eronen & Tschofenig Standards Track [Page 14] RFC 4279 PSK Ciphersuites for TLS December 2005
Eronen&Tschofenig規格は2005年12月にTLSのためにRFC4279PSK Ciphersuitesを追跡します[14ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Eronen & Tschofenig Standards Track [Page 15]
Eronen&Tschofenig標準化過程[15ページ]
一覧
スポンサーリンク
