When a target ends up in the negative authentication cache,
does that imply that the initiator will not contact the target while it's in
the cache, or does it imply that the initiator can contact the target
but should not use IPsec (if IPsec failed)? Or shouldn't use app level
security if app level security failed?
Jonathan
-----Original Message-----
From:
Bernard Aboba [mailto:bernard_aboba@hotmail.com]
Sent: Saturday, June 29, 2002 10:42 PM
To: jtrostle@corp.iready.com; ips@ece.cmu.edu
Subject: RE: IPS-All: Reminder - Security draft last call ends
Monday,
July 1 at 8am EST
>One comment/question on the security draft below:
>
>p. 23: "Where iSNS is used
without security, IP block storage protocol
>implementations MUST support a negative cache for
authentication
>failures."
>
>Is it worth pointing out that when
iSNS is used with security, then a
>negative cache
MUST NOT be used? An attacker can cause authentication >to
>fail through a DoS attack which could result in an entry being
>added to
>the negative cache.
There are two orthogonal issues here -- one is iSNS security,
the other is
IPS protocol security. If iSNS is not
secured, then a peer might receive and
accept an iSNS
packet from a rogue iSNS server. However, if the IPS session
is subsequently secured, and mutually authenticated, the endpoint
specified
in the bogus discovery message will fail to
authenticate. The argument is
that this should result
in a negative cache entry within the iSNS
implementation, so as to prevent continual attempts to authenticate to
bogus
peers.
If iSNS is secured, then presumably this would preclude a
rogue iSNS server,
and the negative cache is
unnecessary.
Do you have an issue with the negative cache in general, or
just its use
where iSNS is secured?
_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com
