Re: AH is pretty useless and perhaps should be deprecated

[Steven Bellovin <smb () cs columbia edu>]

On Nov 16, 2009, at 9:07 PM, James Hess wrote:

> On Mon, Nov 16, 2009 at 6:23 PM, Jack Kohn <kohn.jack () gmail com> wrote:
> > However, i still dont understand why AH would be preferred over
> > ESP-NULL in case of OSPFv3. The draft speaks of issues with replaying
> > the OSPF packets. One could also do these things with AH.
> > Am i missing something?
>
> Neither protects against replay without additional measures.
> However,  AH  is very close...   consider using  AH-authenticated
> packets with the timestamp option   and  clock synchronization between
> peers.
> Discard packets arriving that are more than 5 minutes old.
>
> In transport mode for security between LAN peers, ESP NULL  verifies
> the integrity of only the data  payload in the packet.  AH  secures
> the header,  the IP header fields and options.
>
> Therefore changing the timestamp to replay would  be detected.
> This evil act would not be detected if you are using ESP NULL,  the
> attacker can potentially replay this packet, while the SPI is still
> good, and you'll never know.
>
>
>
> One of AH's  most visible disadvantages (cannot be used with NAT) is a
> side-effect of the increased security coverage it provides.  Many IPv4
> networks  require NAT,  making  AH  impractical.
>
> However,  matters  could change for  IPv6  networks  with  high
> security requirements,   that need to validate authenticity of more
> than just packet contents...
Except for multicast packets -- the case of interest for OSPFv3, and even there the spec arguably got it wrong -- you 
can check the source IP address against the SPD.  That is, you can't replay my ESP packets in a unicast connection with 
a different source address because packets from your source address on my SPI will be rejected.

ESP does have antireplay protection; admittedly, that's disabled if manual keying is used, but generally speaking, 
manual keying shouldn't be used, per RFC 4107.

The interesting case is multicast.  4552 seems to assume symmetric keys, but that's a bad idea; it lets other members 
of the authorized group impersonate each other.  What you really want is digitally signed packets, where each source 
has a key.  I don't think that the IETF's multicast key management protocols are quite up to the job, though; they 
focus on single source multicast, which isn't what OSPF needs.  (That said, 5374 seems to point in the proper 
direction, but I haven't been following this work.)  It may be that the proper answer for OSPFv3 is its own strong 
multicast security.

                --Steve Bellovin, http://www.cs.columbia.edu/~smb