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

Re: ISAKMP and SSL



Ibrahim <hajjeh@enst.fr> writes:
> Most key management protocols (ISAKMP, TLS Handshake, Oakley, SKEME, SKIP…)
> even in SSH are based on Diffie-Hellman.
> This can be an additional reason to this issue if we saw that we develop the
> same key management protocols but every time with a little bit change.
> what i want to say is why every security protocol should propose his own key
> management schemes if we can unify all this work? I think the first ISAKMP
> proposition was in this road.
That's reasonable sounding. I'm just telling you that it's not 
practical to retrofit it to TLS.

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

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

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

-Ekr