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

AH-Lite

Hi,

I'm fairly new on this list (unfortunally, because the discussion is
-mostly- very interesting), so I apologize for things I write or ask
that may have been discussed months ago.

First my opinion to the discussion about ESP with or w/o encryption:
Authentication and integrity will be in much broader use than
encryption, I believe. Beside export regulation issues there are much
more nodes on the Net that want to verify authenticity and integrity
of hosts/users/servers than nodes that have to provide privacy.
Privacy is more an end-to-end issue i.e. application to application.
Only in a VPN-construction where a security gateway detects
unencrypted packets it has to use Tunnel-ESP. It's much more important
the GW can use _autheticated_ adresses or -much better- certificates
to make a policy-based decision what to do with that packet. I read
the current I-D so that AH already provides authentication over the
whole packet (except some header fields) - so why we need auth.-only
ESP? (provokative question: why auth. in ESP on the whole? If you need
authenticy / integrity use AH , if you need privacy too, use ESP!; ESP
allone would only work with 'integrity-enabled' encryption mechanism)

Because we won't see public key crypto for auth. purposes very soon, I
see a problem in verifying AH on other systems than dst. system. 
Assuming fragmentation, AH could only be validated on dst. system
(even if we use public key crypto). AH-tunnel would be a way, but I
think thats a lot of overhead. So, is there a way to use AH for
header-authentication only? I could imagine following processing: 
- Sender uses AH to authenticate the whole packet, SA with ultimate
  destination. 
- if there are nodes on the way that want to verify
  packets, the sender has to establish different SAs to this nodes. But: It
  only needs to authenticate appropriate header fields, because a
  concatenation to data portion is given through inclusion of first AH
  in ICV-computation. Extra AHs should be placed _before_ all other AHs.
  Problem: how to find the nodes that need a extra AH? (ICMP-message or 
  special DNS-record - like proposed by Dan Harkins some times ago?).
  Question: Do I need another IP-Header together with extra AH (which
  would be AH-tunnel-mode without authenticating the whole packet
  again); but if the node is a router, packet won't be sent with dst.
  address <router>.. ? 
  Question: how could I maintain a SA without being the addressee of the 
  packet? 
- this solution would also be possible, if gateways / routers on organisation 
  boundaries don't want to verify packets from inside, but working on a VPN. 
  Now the gateway / router has to establish the appropriate SA and inserts the 
  extra AH. But: If there is no AH yet, it has to authenticate the whole packet. 
- every verified AH can be extracted from the packet. 

Any suggestions on this scheme?

Thanks,
Kai