Subject: [ietf-tls] I-D ACTION:draft-madhu-tls-spki-00.txt

From: [email-masked]
Date: Thu, 12 Jul 2001 07:06:23 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: SPKI Certificate Integration with Transport Layer 
                          Security (TLS) for Client Authentication and 
                          Authorization
	Author(s)	: H. Madhusudhana, V. Ramachandran
	Filename	: draft-madhu-tls-spki-00.txt
	Pages		: 7
	Date		: 11-Jul-01
	
This document extends version 1.0 of the TLS specification [TLS] to
support client SPKI certificates and associated public key
algorithms, symmetric ciphers, hash algorithms and the appropriate
trust model. The server is required to possess a X.509 certificate
for authentication.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-madhu-tls-spki-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-madhu-tls-spki-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-madhu-tls-spki-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: David Hopwood <[email-masked]>
Date: Fri, 13 Jul 2001 00:30:37 +0100

-----BEGIN PGP SIGNED MESSAGE-----

<http://www.ietf.org/internet-drafts/draft-madhu-tls-spki-00.txt>:

>                                                     H. S. Madhusudhana 
> INTERNET-DRAFT                                      V. R. Ramachandran
> Document: draft-madhu-tls-spki-00.txt                           Novell
> Expires: January 11 2002                                  July 11 2001
> 
>         SPKI Certificate Integration with Transport Layer Security
>         (TLS) for Client Authentication and Authorization
...
> 1.      Abstract

The client certificate type is basically orthogonal to the server
certificate type. New server certificate options may be defined in future,
using new ciphersuites. Therefore, this should say something like "The
type of certificate required by the server is defined by the negotiated
ciphersuite (X.509 for the ciphersuites specified in [TLS])."

>    ... [TLS] supports X.509.v3 certificate based
>    authentication and RFC 2712 [KERB-TLS] shows how to extend TLS to
>    Kerberos based authentication within an organization. [OpenPGP]
>    explains extension of TLS to work with OpenPGP keys.

>    [OpenPGP]    W. Price, M. Elkins, " Extensions to TLS for OpenPGP
>                 keys", INTERNET-DRAFT, March 23 2001.

The text should note that this is an I-D, if it is referenced at all.
It could change significantly, or it could be dropped. It would probably
be better just to say that support for other certificate types, for
example OpenPGP, may be added in future.

...
>    SPKI does not require a server to possess a SPKI certificate. In
>    order to facilitate server authentication, the server MUST have a
>    X.509.v3 server certificate.

Same comment as above: the server must have *some* certificate that is
valid for the ciphersuite.

>    The semantics of ServerKeyExchange is not changed from TLS protocol.
>    If the server accepts a SPKI-based cipher suite from the client, it
>    MUST send the CertificateRequest message to the client.

Note "SPKI-based cipher suite", which is explained here:

> 4.      Cipher Suites
> 
>    The CipherSuite field is extended to indicate type of certificate
>    whether SPKI or X509 or OpenPGP. The CipherSuite of the form {0x00,
>    0xMN} indicates use of  X.509.v3 certificate and 0xMN indicates type
>    of public key encryption, signature, shared key encryption and
>    message digest algorithms employed; The CipherSuite {0x01, 0xYZ} is
>    suggested for TLS extension with OpenPGP [OpenPGP]; The CipherSuite
>    {0x02, 0xYZ} is proposed to denote the employment of SPKI
>    certificates.

I don't agree that it's necessary or desirable to encode the *client*
certificate type in the ciphersuite. That is what the ClientCertificateType
field is for. There is no good reason for negotiating the client certificate
type and the ciphersuite together, and that is not how TLS is currently
designed. Currently, a server can specify any client certificate type
in the list it will accept (with the restriction that the *_fixed_dh types
only work for the DH ciphersuites).

The functionality of this draft can be achieved without any new ciphersuites,
just by adding SPKI client certificate types that can be used with the
existing X.509 ciphersuites. That would be simpler, IMHO. I don't think
there is really any need for the client to be able to announce in advance
which certificate types it has; the current method of client cert type
negotiation works fine. If that is considered necessary, though, a client
hello extension would probably be a better way of implementing it.

>    The second byte of CipherSuite for SPKI takes the same
>    value as defined in CipherSuites for X.509.v3 in [TLS] for
>    indicating types of public key encryption, signature, shared key
>    encryption and message digest algorithms employed.
> 
>    For example, the CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA has a
>    value {0x00, 0x12}.

Ciphersuites with symmetric key length <= 56 bits should preferably
not be used in examples.

>    The corresponding cipher suite for SPKI is
>    {0x02, 0x12}. The interpretation of cipher suite for TLS 1.0 is that
>    key exchange is based on ephemeral DH keys which is signed using DSS
>    algorithm by a X.509.v3 certificate issued by CA, the hash algorithm
>    is SHA and the encryption algorithm is DES in CBC mode.

This is unclear. At no point does TLS sign any ephemeral keys in the
format of an X.509 cert, and nothing can be signed *by* a certificate.
Presumably it's intended to mean:

     In the TLS_DHE_DSS_* ciphersuites, the ephemeral DH parameters and
     public key are signed using the DSS algorithm by the server's long-term
     private key; the corresponding public key is certified by an X.509 v3
     certificate.

>    The interpretation for SPKI based security context remains the same
>    except that a SPKI certificate signs the ephemeral DH key.

This seems rather odd; is it really what was intended? It seems to suggest
using SPKI certs for server authentication, not client authentication,
which contradicts what is said in the abstract. Why would using SPKI
for client authentication make any difference to how the DH parameters
and ephemeral key are signed?

>    This specification extends ClientCertificateType as shown in Figure 2
>    to include the server name and details of applications/services on it
>    and to support different kinds of SPKI certificates.
> 
>    TLS defines several kinds of client certificates to facilitate
>    different methods of key exchange and message authentication. The
>    newly defined SPKI certificate types are semantically same as the
>    corresponding X.509.v3 certificate types except for representation
>    in S-expression format. When X.509.v3 client certificate is used,
>    the DistinguishedName field of CertificateRequest message specifies
>    acceptable CA's distinguished names. When SPKI certificate is used
>    by the client, it is proposed to use the DistinguishedName field to
>    specify server name/application name etc. in order to help the
>    client to select the appropriate SPKI certificate.

How is this encoded? Is it shoehorned into the format of a DistinguishedName
somehow? (Note that clients will try to parse it as a DistinguishedName,
especially if we use the existing X.509 ciphersuites, as I suggest.)
Perhaps a client hello extension meaning "I have at least one SPKI client
cert, and I can understand an extended CertificateRequest format." would
help.

>    This is useful
>    because a client may hold multiple SPKI certificates from many
>    servers/applications.
> 
>    +----------------------------------------------------------+
>    |    enum {                                                |
>    |          rsa_sign(1),   dss_sign(2), rsa_fixed_dh(3),    |
>    |          dss_fixed_dh(4), kerberos(5),                   |
>    |          spki_rsa_sign(6),   spki_dss_sign(7),           |
>    |       spki_rsa_fixed_dh(8), spki_dss_fixed_dh(9),        |
>    |       (255)                                              |
>    |    } ClientCertificateType;                              |

Where did kerberos(5) come from? It is not defined in RFC 2712.

SSL 3.0 (draft-freier-ssl-version3-02.txt, which although expired, is
the only current definition of SSL3) has the following:

     enum {
         rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
         rsa_ephemeral_dh(5), dss_ephemeral_dh(6), fortezza_kea(20),
         (255)
     } ClientCertificateType;

5, 6 and 20 are not defined in TLS, but these numbers should not be
reused arbitrarily. In addition, draft-ietf-tls-ecc-01.txt has

     enum {
         ecdsa_sign(5), rsa_fixed_ecdh(6),
         ecdsa_fixed_ecdh(7), (255)
     } ClientCertificateType;

and draft-ietf-tls-ntru-00.txt has

     enum {
         nss_sign(8), nss_rsa(9), (255)  
     } ClientCertificateType;

I'm rather dubious about adding new *_fixed_dh types; isn't it
correct that the existing *_fixed_dh types are basically never used?
Note that using these types prevents forward secrecy for the DHE
ciphersuites (the same would be true for *_fixed_ecdh and ECDHE).
I therefore suggest:

     enum {
         rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
         ssl3_reserved_5(5), ssl3_reserved_6(6),
         ecdsa_sign(7),
         nss_sign(8), nss_rsa_sign(9),
         spki_rsa_sign(10), spki_dss_sign(11),
         ssl3_reserved_20(20),
         (255)
     } ClientCertificateType;

with ecdsa_sign, nss_sign and nss_rsa_sign only provisionally
assigned for the moment (I don't agree with much of the ECC draft; it
is too complicated).

>    |                                                          |
>    |    opaque  DistinguishedName <1..2^16-1>;                |
>    |                                                          |
>    | struct {                                                 |
>    |   ClientCertificateType certificate_types<1..2^8-1>;     |
>    |   DistinguishedName certificate_authorities <3..2^16-1>; |
>    |} CertificateRequest;                                     |
>    |                                                          |
>    +----------------------------------------------------------+
>
>         FIGURE 2: Extended ClientCertificateType
> 
>    +-----------------------------------------------+
>    |                                               |
>    | opaque Certificate <1..2^24-1>;               |
>    |                                               |
>    +-----------------------------------------------+
>         FIGURE 3: Certificate Message
> 
>    To get server authorization for access/service, the client MUST
>    respond to the server by sending Certificate Message as in Figure 3
>    In case of SPKI, it is to be noted that Certificate is not an array
>    of elementary certificates as in the case of X.509.v3.

... is not a DER SEQUENCE of ...

> A  Tuple-reduction and authorization computation in a SPKI Certificate

Does Appendix A come directly from [SPKI-JUL 1999]? If so, that should
be stated.

In summary, I think the basic idea of the draft is fine, but it could be
simplified quite a bit by using the existing ciphersuites, rather than
trying to define new ones.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---

---

From: "David Taylor" <[email-masked]>
Date: Fri, 13 Jul 2001 18:34:16 +1000

> cert, and I can understand an extended CertificateRequest format." would

What about using a server hello extension (corresponding to the suggested
client hello extension) to advertise this server name/application name data?
Then the certificate request message can still carry the
ClientCertificateType data but not mangle the DistinguishedName element.

If the existing cipher suites are used and the server ignores the client
hello extension, the server hello extension won't be sent so the client will
know it's not going to be able to do SPKI authentication.

This would still allow the existing cipher suites to be used.

Regards,
David Taylor.

---