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

Re: ISAKMP and SSL



Mark, I totally agree with you
The idea of extending the work of ISAKMP to other security protocols began in 1996
by Cisco corp. J.  Smith has also talk about it in the
ietf-tls mailing list.
But i think that the work and effort involved in this WG during all last period in
defining a robust key exchange mechanism should be used and
gained in other WG.
Centralizing ISAKMP usage to IPsec (IKEv2) remove all the advantage of  this
“generic” key exchange protocol. We should not forget that ISAKMP
was designed as an application layer protocol so normally it benefit of all the
advantage of this layer and can especially establish a secure connection
for all network security protocols so why we don’t try to implement it outside
IPsec?

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.

>
> > 2 - Modularity of SSL Protocol.
> > SSL is a module security protocol. Any ISAKMP integration requires
> > changing only the Handshake part.
> In theory perhaps. In practice the TLS key management and record protocol
> are relatively tightly coupled. Moreover, like 75% of the TLS code
> is key management so it's not clear why you'd want to gut it,
> shove in ISAKMP, but retain the record layer.
>
> > 3 – TLS extension proposes to extend the work of TLS protocol in new
> > environment (..) and to add some new mechanism in authentication
> > (Sending URL certificate, authentication with attribute …) All these
> > mechanisms are even implemented in ISAKMP or can be quickly done. For
> > ISAKMP the new environment can be multi-cast diffusion, MAP protocol for
> > UMTS...
> 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.

>
> > 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.

Ibrahim
____________________________________________________
Ibrahim HAJJEH
Ecole Nationale Supérieure des Télécommunications
Departement Informatique et Réseaux
Tél.:+33 01 45 81 71 06     Fax.: +33 01 45 81 31 19
46 rue Barrault, 75634 PARIS cedex 13