On Tue, Sep 25, 2007 at 11:58:45AM +0200, Steffen DETTMER wrote:
> > No, the challenge is key management. TLS is just fine.
>
> What do you mean, `TLS is just fine'?
TLS is a sound protocol, the problem is not the protocol, the problem
is key management.
> Doesn't it depend on the requirements?
TLS is fine protocol for establishing a secure channel over a reliable
transport. Despite all appearances, TLS is not exclusively tied to a CA
centric X.509v3 trust model with RSA keys and RSA CA signatures.
> I think, for key management itself (like
> transferring secret keys), TLS is not suited.
I am making no claims that TLS is (or is not) suited for key management.
Key management is a pre-requisite for TLS, one model for key management
is X.509v3 CAs issuing certs and revocation lists. This is not the only
key management model compatible with TLS, though it is the one most
commonly found in products that use TLS.
> TLS AFAIK is
> limited to one session key (someone could wish one for
> authentication and a second one for encryption).
This is false.
> > If CAs don't solve key management for you, roll your own key
> > management, but use existing protocols.
>
> If for some application (not meaning only a computer program) the
> "usual" CAs are inappropriate, maybe for this application PKI is
> not suited at all, could happen. Maybe I missunderstand you, but
> I think, when SSL/TLS is not suited then it should not be needed,
> even if with OpenSSL such a nice lib is avialable :)
Don't confuse TLS with PKI.
> > I would like to see GSSAPI support in TLS (so would Microsoft
> > and a few others). This addresses key management, without
> > requiring secondary protocols, and ties into the dominant
> > standard intra-mural authentication system. This would use a
> > certificate-less cipher-suite, but the point remains that
> > authentication should be within TLS, not an add-on.
>
> ohh, now I got so many questions :)
Well, Kerberos is already supported, but only with DES. If TLS is to see
wide-scale use *inside* large organizations where CAs are entirely the
wrong model, and GSSAPI is already prevalent, we need a GSSAPI (X.509v3
certificate-less) cipher-suite for TLS with modern symmetric ciphers
(AES-256, ...). This an IETF issue, not an OpenSSL issue.
> According to Wikipedia, this is an API to standardise how the
> application uses something like e.g. OpenSSL, is that correct? Or
> is it something completely different? You wrote `GSSAPI support
> in TLS' - this would be a standard or would it be an
> implementation?
A new TLS ciphersuite, GSSAPI is both a standard and a protocol.
> How would it help with key management? Do you mean in this can
> you could use any standard GSSAPI-using key management tool?
GSSAPI uses Keberos-5 KDCs for key management.
> You said `without requiring secondary protocols', but wouldn't
> the implementation of that API be nothing else than such a
> secondary protocol (OCSP or so)?
The programmer would not need to develop a secondary authentication
protocol and intergrate it with TLS, it would be correctly used in a
standard fashion inside the TLS protocol. X.509v3 signature verification
is also a protocol, it is just that the KDCs are off-line (which is most
often a bug, not a feature).
> What is meant by certificate-less cipher-suite? A protocol not
> using certificates, such as SSL without X.509 certificates at
> all? How would the authentication work?
Do some homework.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
