[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AH (without ESP) on a secure gateway
Hi Bill and Tom,
>
> Bill
>
> BW> Last month there was a question regarding ESP and AH on a secure
> gateway as in the following model.
>
>
> secure (untrusted) secure
> hostA gatewayA---------------------------gatewayB hostB
> | | | |
> ---------- -----------
> (trusted subnet) (trusted subnet)
>
>
> BW> My question is whether AH on a secure gateway even makes sense at all
> if ESP is not being performed.
>
>
> Consider the case where one gateway is in a country like France which
> does not allow encryption. An organization could still use AH to
> authenticate that the source of the packets was another secure gateway
> belonging to the organization.
This is exactly what I would like AH only support for. It would give us
the extra capabilities of Anti-Spoofing and Integrity checking which
would be a big win over today's infrastructure. There are some instances
where privacy is not a big deal, or where export/import usage
restrictions forbid the use of strong cryptography.
>
> BW> Consider hostA sending a packet to hostB. If gatewayA places an AH on
> the packet, it would appear as if it was authenticated by hostA, not a
> good idea in my mind.
>
> The receiving gateway/host knows (should know) that the AH keying material
> is held by Gateway A and not Host A. If the receiving gateway/host
> does not know which devices it shares keying material with, you have a
> key management problem.
>
> Tom Markham
I don't believe this is the case in some of the gateway products which
are available today. Some of the gateway products transparently proxy
for hosts in the trusted network. This is the fundamental weak spot in
gateway solutions. They assume:
- your trusted network is secure
- you do not have users spoofing the addresses of other users
within the trusted network.
The strength of this approach is you can support legacy devices without
making any changes to them. Gateways are a compromise between security
and medium-term implementation realities.
Does anyone know if there are specific set up messages in the
ISAKMP-OAKLEY protocol to identify which architectural case a pair of
communicating peers is in ? i.e. Host-to-Host, Host-to-Gateway, and
Gateway-to-Gateway.
For example, if one knew the conversation was between two gateways, one
could accept the risks of this architectural model and just negotiate a
pair of SAs for the communication with all traffic between the networks
being multiplexed over a single TCP/IP connection. Much more efficient
for the gateways. However if we do this are we making it easier for
an attacker to perform cryptanalysis on our connection ?
If you implement the reverse situation, where a new SA pair is negotiated
for every IP pair that attempts communication between the networks,
this could quickly bog down the gateways while they authenticate
public keys exchanges, context switch between secret session keys and
encrypt and decrypt packets.
One could argue that this will happen anyway in the Host-to-Gateway
scenario, and one needs to engineer for this case, so why not make
it the general one ? Right now, with gateway solutions, I think
that Host-to-Host is how they operated. I would interested in
finding out if there is a way to identify which model is in use.
Also, if I have made any gross conceptual mistakes in this text,
I would appreciate being helped to understand why. Thanks for your
time.
Sincerely,
Yan
___________________________________________________________________
My views do not necessarily represent those of the Hewlett Packard
Company and should be taken with a large dose of salt or whatever
passes for sodium in your neck of the woods/universe/continuum/etc...
___________________________________________________________________
References: