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

Re: Reliable delete notifies

I'm somewhat divided on the aggressive mode issue.

While I'm all for a full-fledged roll-out of PKI, it hasn't happened yet. As
I've argued internally here at cisco, it's primarily the fact that we keep
coming up with (sometimes ingenious, sometimes insecure) hacks so that we
don't have to use PKI (Like group pre-shared keys. YIKES), because most
customers are still very much afraid of PKI (for a myriad of reasons).

So until PKI rolls out, aggressive mode is still very much needed, especially
in the VPN space, which HAS to work through firewalls and (tadaa!!) NAT.

Counterview: Maybe getting rid of aggressive mode will speed up the need for
a concerted effort on PKI.

On the other hand, if we simply deprecate aggressive mode, then I'm afraid
we're pusihing a lot of people towards SSL solutions to the above VPN through
NAT problem. And that's NOT something I like, personally.

Using aggressive mode and picking your shared secret based on the ID is the
only thing that's keeping a lot of VPN still on the verge of usability. Let's
face it: IKE and IPSec through firewalls and NAT is still very fragile (in
part because firewalls and NAT vendors can't seem to get it right).

If we deprecate Aggressive mode, then we're going to have to take a LONG hard
look at what it'll take to make ike and ipsec work robustly in scenarios
involving firewalls and NAT. Think especially about older firewalls, and the
fact that you may not be able to get rid of them (they may not be in your
control). I assume we all want ipsec to survive, and there's still a lot of
NAT devices and firewalls through which ipsec simply doesn't work. Assume
that these will not go away or be replaced in the near future. Getting rid of
aggressive mode means we need to make it work. I'm not sure how.

One might argue that we could get rid of aggressive mode, and let IPSRA
figure out the above problem. But that's really shirking our responsibility.

My 2c, anyway.

jan



On Sat, 7 Oct 2000, Sandy Harris wrote:

> Dan Harkins wrote:
> 
> > ... So let's
> > start a discussion. Does the Working Group want to keep
> > Aggressive Mode? Is Aggressive Mode "standards bloat" or
> > is it a necessary addition to do what Ben wants to do?
> 
> Here's something I posted on the linux-ipsec list a few weeks back. The whole
> thread might be of interest. See archives at:
> 
> http://www.sandelman.ottawa.on.ca/linux-ipsec/
> http://www.nexial.com/mailinglists/
> 
> The outcome of the thread was Linux FreeS/WAN dropping support for DH Group one.
> We dropped DES support some time back.
> 
> ---- forwarded message ------------
> 
> Subject: Re: linux-ipsec: Diffie-Hellman groups
>    Date: Thu, 14 Sep 2000 20:05:18 -0400
>    From: Sandy Harris <sandy@storm.ca>
> 
> Svenning Soerensen wrote:
>  
> > In the spirit of strong security in FreeS/WAN, I wondered
> > if it is reasonable for pluto to propose DH group 1.
> > 
> > To quote from draft-ietf-ipsec-ike-01.txt:
> > 
> >   "The strength supplied by group one may not be sufficient for the
> >    mandatory-to-implement encryption algorithm and is here for historic
> >    reasons."
> > 
> > In the lights of the team's decision not to support single-DES, I
> > think DH group 1 should be abandoned too.
>  
> There's been some discussion of a "best current practices" draft
> that could aim at becoming an RFC.
> 
> Things I think such a draft should deprecate:
>         DES
>         Group 1
>         Aggressive mode (reveals identities to eavesdropper)
>         Phase two connections without PFS
>         MD5 (Dobbertin's published attack casts doubt here)
> 
> A BCP draft should recommend for these:
>         these must not be used in the default configuration for
>            any implementation
>         implementers are permitted to drop support for them.
>         if they are supported, they are not used unless explicitly
>            enabled by the administrator
>         using any of them is an auditable event; it should
>            generate warnings
> 
> I'd like to see all the above removed from the standard, perhaps
> along with some of the things the Schneier/Ferguson critique
> suggested dropping. However, I don't think that will happen.
> I think a BCP RFC that only recommends the above might fly, though.
> 
> Currently single DES is the only cipher marked MUST in the RFCs.
> 3DES is a SHOULD. Efforts to upgrade 3DES to MUST and deprecate DES
> have been blocked.
> 
> I think the right thing to do in a BCP draft is to add the AES winner,
> due to be announced this month:
> http://csrc.nist.gov/encryption/aes/
> as a MUST. Alternately, make 3DES a MUST and AES a SHOULD.
> 
> Not a BCP issue, but I'm inclined to think it would be useful
> to add the Tiger hash from:
> 
> http://www.uni-mannheim.de/studorg/gahg/rweis/rgp/tiger/tiger.html
> 
> This is a SHOULD in the RFCs and becomes more important if MD5
> is deprecated. Designers are very credible folk, and it is faster
> on 64-bit CPUs than MD5 or SHA. It is not a priority for the team.
> Volunteers?
> 

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847
Follow-Ups: References: