[TLS] Revocation and authentication of raw public key (was: AD review of draft-ietf-tls-oob-pubkey)

[Bert Greevenbosch <[e-mail]>]

Hello Rich,

Thank you for your feedback. Please find my response below.

> Yes, O*CS*P light is a bad name. :)

Right, that should be changed.

> Have you looked at what SSH is doing for key management issues?

Thanks for your hint. Indeed SSH specifies something quite similar to a raw public key in RFC 4716.

I understand that SSH relies on the following methods for authentication:

(1) Pre-shared knowledge of public key. For example, after first registration the client knows the server public key, so if the public key changes in a later session it is suspect.
(2) Manual verification of the hash of the public key, which is delivered through a separate channel.
(3) Password verification -> after session setup the client sends a password to ensure the server it is legitimate.

The SSH specifications (e.g. RFC 4251) explicitly point out that for the sake of easy deployment, authentication of name-to-key association may be omitted, accepting the risk of a man-in-the-middle attack.

RFC 4251 also mentions the possibility to use a trusted certificate authority (CA) for the name-to-key association. It notes that this can be done through Kerberos or a secure DNS lookup.

I think name-to-key association is half of the problem, whereas revocation is the second half. SSH seems to focus on the first half, whereas OCSP-lite focuses mainly on the second half.

How do you envision using SSH for raw public keys?

Thanks and best regards,
Bert


-----Original Message-----
From: Salz, Rich [mailto:[e-mail]] 
Sent: 2013年4月22日 23:15
To: Bert Greevenbosch; Sean Turner; [e-mail]; [e-mail]
Subject: RE: [TLS] AD review of draft-ietf-tls-oob-pubkey

Yes, O*CS*P light is a bad name. :)

Have you looked at what SSH is doing for key management issues?

	/r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA