[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ISAKMP and SSL



Ibrahim <hajjeh@enst.fr> writes:
> Eric Rescorla wrote:
> 
> > Ibrahim <hajjeh@enst.fr> writes:
> >
> > > 1 – about identity protection new service. I am not convinced with (a) +
> > > (b) solution for SSL. Identity protection can also be the mask of a
> > > number of people using the same IP address. Id. Prot. can be
> > > used when one host has multiple identities and wishes to mask who is
> > > behind a specific handshake. (even with different X509 Cert.).
> > I don't understand what point you're trying to make here.
> 
> You should read the proposed TLS extension draft about authenticating
> TLS server that host multiple virtual servers.
Ibrahim, I'm the editor of the main TLS document. I've read the
extensions draft times. I still don't understand what point
you're trying to make here about identity protection.

> > I don't understand what point you're trying to make here. I
> > don't deny that you can obtain the requested security services
> > using some mechanism other than TLS, but the probability of
> > TLS incorporating ISAKMP key management is approximately zero.
> > Therefore, if you want to use TLS and you want these services,
> > you need to start thinking about a different approach.
> 
> Sure, SSL will not offer these services but ISAKMP can.
Right, but since noone is going to use ISAKMP with SSL, 
if you want these features in the context of SSL you have to think
about how to add them to SSL.

> > > 4 - Interoperability between different security protocols.
> > > Several security protocols could share the same key management code.
> > > This simplifies migration from one protocol to another and reduces the
> > > amount of duplicated functionality within each security protocol.
> > Yes, that's fine, but we live in a world where TLS code
> > is already very widely deployed, so creating a new TLS/ISAKMP hybrid
> > is going to introduce complication, not reduce it.
> >
> 
>  I know that SSL is the most deployed security protocol but this is only
> due to his native integration in web server, client browsers and because
> 80% of the SSL usage is with HTTP. Adapting SSL for new services, the
> deployment of IPv6 arch., IKEv2 design can also introduce complication.
TLS has been quite robust when applied to new application
layer protocols, actually. Very little has had to be done
(the virtual servers stuff being the notable exception)

IPv6 architecture and IKEv2 design have nothing to do with
TLS because TLS sits at a different layer of the stack.

-Ekr


-- 
[Eric Rescorla                                   ekr@rtfm.com]
                http://www.rtfm.com/