[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: DISCUSS: draft-ietf-radext-rfc3576bis
Discuss:
The RFC 2401 IPsec model does not actually support the concept of a
security policy entry that is "accept protected traffic but don't
require it." Some of the suggested policies in the security
considerations section seem to rely on this.
In large "mixed" deployment, it can be cumbersome to configure IPsec filters
for every NAS.
Since we have no mechanism for an application to find out if traffic is
protected
That is only necessary if the RADIUS shared secret isn't configured when
RADIUS/IPsec is used. Otherwise, the server just checks the incoming
packets using existing RADIUS security -- it doesn't care if the packet was
protected by IPsec or not.
In any case, some shipping products do support "traffic protection"
awareness.
I don't think that you can actually have a secure setup if you sometimes
use IPsec
with a given source and sometimes do not.
If all NASes are known to support IPsec, then the server can configure a
global filter that says "only accept IPsec from these addresses." However,
during a transition period the server may be willing to accept either
conventional RADIUS from some NASes or RADIUS over IPsec. In that case,
all the server has to do is carry out existing RADIUS security checks.
You don't seem to say what IKE authentication modes need to be
supported. You may get a long way by referring to RFC 4945.
This is covered in RFC 3579, so we could reference that.
I'm confused by section 6.2. Does the attack described there actually
happen if the first-hop proxy uses a different secret for each DAS/NAS
and confirms that the right secret is used? I.E. confirms that the NAS
identity matches the expected NAS identity for the secret?
The attack can still happen if different shared secrets are used if the
first hop proxy doesn't check the source address against the NAS-Identifier.
For example, the NAS could claim to be another NAS in the NAS-Identifier,
but use the correct (and different) RADIUS shared secret. When the proxy
forwards the packet, it has now been "laundered" -- the server can't
determine whether it came from a "lying NAS" or not.
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>