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

RE: Getting the features chart going



>The only meaningful drawback I've heard of
>so far pertains to the additional overhead required for the extra SA,
>and this is really more of an optimization issue than anything else.

The creation and deletion of SAs that will result from this could limit
scalability, so I think that a decent case has been made for allowing
ISAKMP-cfg to assign IP addresses. However, that's *all* that I think
it should do. Everything else should be handled by DHCP INFORM. That's
the conclusion we came to in the PPP working group back in the early
90s. 

>It's not clear that isakmp-cfg is simple, and it's also not at all clear
>that the additional challenges it presents in terms of analyzability,
>reliability, etc. with respect to security are worth the overhead gains
>over the dhcp approach.

There are security risks associated with assignment of IP addresses;
these threats are detailed in the authenticated DHCP draft. However,
those threats mostly have to do with unauthenticated clients making
large numbers of resource requests, or unauthenticated servers handing
out bogus parameters. In this particular case, ISAKMP-cfg is only
invoked *after* mutual authentication so that both sides know who
they are talking to. That doesn't mean that the initiator or
responder can't act badly, but it does imply that you'll know who
is doing it. This is about as much assurance as you get with
authenticated DHCP.  

>Isamkp-cfg vs. dhcp is one issue, and xauth vs (???) is another. >

I would agree. I think that there is a decent case for ISAKMP-CFG,
provided that functionality is very strictly limited. XAUTH is a
much weaker proposal, primarily because it does not leverage
existing IETF authentication frameworks such as SASL, GSS_API (useful
when the initiator has obtained initial credentials) and 
EAP (useful as an initial authentication mechanism). One good
thing about XAUTH is that it occurs after IKE phase 1 so that
you have a protected channel in place and are already mutually
authenticated. This means that any extended authentication
negotiation will be protected against downlevel attacks, which
has been a concern about naked SASL or EAP negotiations 
(GSS_API with SPNEGO is protected as long as the finally
agreed upon method supports integrity protection). Given that
existing frameworks already support most of the methods 
described in XAUTH, going with standard frameworks would not
remove functionality while considerably increasing the
ease of implementation and compatibility with existing
IETF architecture. 





Follow-Ups: References: