draft-ietf-tls-oob-pubkey-05.txt   draft-ietf-tls-oob-pubkey-06.txt 
skipping to change at page 1, line 16 skipping to change at page 1, line 16
Expires: April 25, 2013 Nokia Siemens Networks Expires: April 25, 2013 Nokia Siemens Networks
J. Gilmore J. Gilmore
S. Weiler S. Weiler
SPARTA, Inc. SPARTA, Inc.
T. Kivinen T. Kivinen
AuthenTec AuthenTec
October 22, 2012 October 22, 2012
Out-of-Band Public Key Validation for Transport Layer Security (TLS) Out-of-Band Public Key Validation for Transport Layer Security (TLS)
draft-ietf-tls-oob-pubkey-05.txt draft-ietf-tls-oob-pubkey-06.txt
Abstract Abstract
This document specifies a new certificate type for exchanging raw This document specifies a new certificate type for exchanging raw
public keys in Transport Layer Security (TLS) and Datagram Transport public keys in Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS) for use with out-of-band public key validation. Layer Security (DTLS) for use with out-of-band public key validation.
Currently, TLS authentication can only occur via X.509-based Public Currently, TLS authentication can only occur via X.509-based Public
Key Infrastructure (PKI) or OpenPGP certificates. By specifying a Key Infrastructure (PKI) or OpenPGP certificates. By specifying a
minimum resource for raw public key exchange, implementations can use minimum resource for raw public key exchange, implementations can use
alternative public key validation methods. alternative public key validation methods.
skipping to change at page 7, line 25 skipping to change at page 7, line 25
select(ClientOrServerExtension) select(ClientOrServerExtension)
case client: case client:
CertificateType certificate_types<1..2^8-1>; CertificateType certificate_types<1..2^8-1>;
case server: case server:
CertificateType certificate_type; CertificateType certificate_type;
} }
} CertTypeExtension; } CertTypeExtension;
Figure 4: CertTypeExtension Structure. Figure 4: CertTypeExtension Structure.
The '-Offer' postfix indicates that a TLS entity is able to send the
indicated certificate type to the other communication partner. The
'-Accept' postfix indicates that a TLS entity is able to receive the
indicated certificate type.
No new cipher suites are required to use raw public keys. All No new cipher suites are required to use raw public keys. All
existing cipher suites that support a key exchange method compatible existing cipher suites that support a key exchange method compatible
with the defined extension can be used. with the defined extension can be used.
4. TLS Handshake Extension 4. TLS Handshake Extension
4.1. Client Hello 4.1. Client Hello
In order to indicate the support of out-of-band raw public keys, In order to indicate the support of out-of-band raw public keys,
clients MUST include an extension of type "certificate_type" to the clients MUST include an extension of type "certificate_type" to the
skipping to change at page 8, line 33 skipping to change at page 8, line 38
specification. specification.
4.5. Client authentication 4.5. Client authentication
Client authentication by the TLS server is supported only through Client authentication by the TLS server is supported only through
authentication of the received client SubjectPublicKeyInfo via an authentication of the received client SubjectPublicKeyInfo via an
out-of-band method out-of-band method
5. Examples 5. Examples
Figure 5, Figure 6, and Figure 7 illustrate example message Figure 5, Figure 6, and Figure 7 illustrate example exchanges.
exchanges.
The first example shows an exchange where the TLS client indicates The first example shows an exchange where the TLS client indicates
its ability to process two certificate types, namely raw public keys its ability to receive raw public keys. This client is quite
and X.509 certificates via the 'certificate_type' extension in [1]. restricted since it is unable to process other certificate types sent
When the TLS server receives the client hello it processes the by the server. It also does not have credentials it could send. The
certificate_type extension and since it also has a raw public key it 'certificate_type' extension indicates this in [1]. When the TLS
indicates in [2] that it had choosen to place the server receives the client hello it processes the certificate_type
SubjectPublicKeyInfo structure into the Certificate payload (see extension. Since it also has a raw public key it indicates in [2]
[3]). The client uses this raw public key in the TLS handshake and that it had choosen to place the SubjectPublicKeyInfo structure into
an out-of-band technique, such as DANE, to verify its validatity. the Certificate payload [3]. The client uses this raw public key in
the TLS handshake and an out-of-band technique, such as DANE, to
verify its validity.
client_hello, client_hello,
certificate_type=(RawPublicKey-Accept) -> // [1] certificate_type=(RawPublicKey-Accept) -> // [1]
<- server_hello, <- server_hello,
certificate_type=(RawPublicKey-Offer), // [2] certificate_type=(RawPublicKey-Offer), // [2]
certificate, // [3] certificate, // [3]
server_key_exchange, server_key_exchange,
server_hello_done server_hello_done
skipping to change at page 9, line 25 skipping to change at page 9, line 25
change_cipher_spec, change_cipher_spec,
finished -> finished ->
<- change_cipher_spec, <- change_cipher_spec,
finished finished
Application Data <-------> Application Data Application Data <-------> Application Data
Figure 5: Example with Raw Public Key provided by the TLS Server Figure 5: Example with Raw Public Key provided by the TLS Server
In our second example both the TLS client and the TLS server use raw In our second example the TLS client as well as the TLS server use
public keys. This is a use case envisioned for smart object raw public keys. This is a use case envisioned for smart object
networking. The TLS client in this case is an embedded device that networking. The TLS client in this case is an embedded device that
only supports raw public keys and therefore it indicates this is configured with a raw public key for use with TLS and is also able
capability via the 'certificate_type' extension in [1]. As in the to process raw public keys sent by the server. Therefore, it
previously shown example the server fulfills the client's request and indicates these capabilities in the 'certificate_type' extension in
provides a raw public key into the Certificate payload back to the [1]. As in the previously shown example the server fulfills the
client (see [3]). The TLS server, however, demands client client's request, indicates this via the 'RawPublicKey-Offer'in the
authentication and therefore a certificate_request is added [4]. The certificate_type payload, and provides a raw public key into the
certificate_type payload indicates the TLS server supported Certificate payload back to the client (see [3]). The TLS server,
certificate types, see [2], and particularly that the TLS server is however, demands client authentication and therefore a
also able to process raw public keys sent by the client. The TLS certificate_request is added [4]. The certificate_type payload in
[2] indicates that the TLS server accepts raw public keys. The TLS
client, who has a raw public key pre-provisioned, returns it in the client, who has a raw public key pre-provisioned, returns it in the
Certificate payload [5] to the server. Certificate payload [5] to the server.
client_hello, client_hello,
certificate_type=(RawPublicKey-Offer, RawPublicKey-Accept) -> // [1] certificate_type=(RawPublicKey-Offer, RawPublicKey-Accept) -> // [1]
<- server_hello, <- server_hello,
certificate_type=(RawPublicKey-Offer, certificate_type=(RawPublicKey-Offer,
RawPublicKey-Accept) // [2] RawPublicKey-Accept) // [2]
certificate, // [3] certificate, // [3]
skipping to change at page 10, line 34 skipping to change at page 10, line 34
Application Data <-------> Application Data Application Data <-------> Application Data
Figure 6: Example with Raw Public Key provided by the TLS Server and Figure 6: Example with Raw Public Key provided by the TLS Server and
the Client the Client
In our last example we illustrate a combination of raw public key and In our last example we illustrate a combination of raw public key and
X.509 usage. The client uses a raw public key for client X.509 usage. The client uses a raw public key for client
authentication but the server provides an X.509 certificate. This authentication but the server provides an X.509 certificate. This
exchange starts with the client indicating its ability to process exchange starts with the client indicating its ability to process
X.509 certificates provided by the server, and the ability to send X.509 certificates provided by the server, and the ability to send
raw public keys. The server provides the X.509 certificate using raw public keys. The server provides the X.509 certificate in [3]
that format in [3] with the indication present in [2]. For client with the indication present in [2]. For client authentication,
authentication, however, the server indicates in [2] that it is able however, the server indicates in [2] that it is able to support raw
to support raw public keys. The TLS client provides a raw public key public keys and requests a certificate from the client in [4]. The
in [5] after receiving and processing the TLS server hello message. TLS client provides a raw public key in [5] after receiving and
processing the TLS server hello message.
client_hello, client_hello,
certificate_type=(X.509 Receive, RawPublicKey-Offer) -> // [1] certificate_type=(X.509-Accept, RawPublicKey-Offer) -> // [1]
<- server_hello, <- server_hello,
certificate_type=(X.509 Send, certificate_type=(X.509-Offer,
RawPublicKey-Accept), // [2] RawPublicKey-Accept), // [2]
certificate, // [3] certificate, // [3]
certificate_request, // [4] certificate_request, // [4]
server_key_exchange, server_key_exchange,
server_hello_done server_hello_done
certificate, // [5] certificate, // [5]
client_key_exchange, client_key_exchange,
change_cipher_spec, change_cipher_spec,
finished -> finished ->
 End of changes. 9 change blocks. 
29 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/