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

Re: ISAKMP and SSL



hi Ibrahim,
   In addition to some of the advantages that you cite, another claimed 
benefit of the ISAKMP approach is increased security by having a single key 
establishment entity on the computer rather than several.  Although some of 
us "drank that kool aid," I think that this is not the current direction of 
IPsec (there are some good arguments against it, notably complexity) and 
the matter is probably of little interest to most people on this list.  At 
least that's my impression of the way things stand.

Best regards, Mark
At 12:17 PM 5/1/2003 +0200, Ibrahim wrote:
>Hi all,
>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.
>
>  In addition,
>
>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.).
>
>2 - Modularity of SSL Protocol.
>SSL is a module security protocol. Any ISAKMP integration requires
>changing only the Handshake part.
>
>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...
>
>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.
>
>Ibrahim
>
>
>Eric Rescorla wrote:
>
> > > When I read RFC 2408 they described ISAKMP as a generic key management
> > > protocol for all security protocols but till now the large deployment of
> > > ISAKMP was only with IPSEC
> > > My question is, can we use it with SSL/TLS?
> > > The goal of this issue is to add new services in SSL/TLS (identity
> > > protection, attribute certificate passing for access control schemes,
> > > non-repudiation…).
> >
> > The basic answer here is no.
> >
> > TLS has its own key management scheme and really isn't designed
> > to have pluggable key management. That said, with respect to your
> > specific desired security services:
> >
> > (1) You can get identity protection for TLS in a number of ways,
> >     none quite as good as you would get with IPsec.
> >
> >     (a) do an initial anonymous DH exchange and then do the
> >         ordinary handshake. This still allows an active attacker
> >         to get both identities.
> >
> >     (b) do an initial cert-based exchange (this exposes the
> >         server's identity) and then rehandshake to have the
> >         client identify.
> >
> >     (c) combine the above two techniques :)
> >
> > (2) TLS has an extensions mechanism so you could use that to
> >     pass around attribute certificates.
> >
> > (3) ISAKMP doesn't really offer non-repudiation either, so you
> >     wouldn't get any benefit from melding it with TLS.
> >
> > -Ekr
> >
> > --
> > [Eric Rescorla                                   ekr@rtfm.com]
> >            Web Log: http://www.rtfm.com/movabletype
>
>--
>____________________________________________________
>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