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

Re: [IPSECKEY] Security Considerations (pass 2)



On Thu, May 22, 2003 at 03:43:15PM -0400, Michael Richardson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> 
> >>>>> "Rob" == Rob Austein <sra+ipseckey@hactrn.net> writes:
>     Rob> So perhaps something like the following would do (keyboarded, might
>     Rob> need wordsmithing):
> 
>     Rob>   Note that the danger here only applies to cases where the gateway
>     Rob>   field of the IPSECKEY RR indicates a different entity than the owner
>     Rob>   name of the IPSECKEY RR.  In cases where the end-to-end integrity of
>     Rob>   the IPSECKEY RR is suspect, the end client MUST[*] restrict its use
>     Rob>   of the IPSECKEY RR to cases where the RR owner name matches the
>     Rob>   content of the gateway field.
> 
>   I don't find anything wrong with your text, and I agree about the MUST.

Question: what do you mean by: "In cases where the end-to-end integrity
of the IPSECKEY RR is suspect" ?

	Do you mean:
		a) Implementation detected (how ?) or expects with a
		reasonnable probability that an active attack is under way. Then I
		agree the end client MUST restrict the use of the record.
	or:
		b) When there is no end-to-end integrity, (or when a gateway cannot
		know surely about that), the end client MUST restrict the use of
		the record.

	In case b), the end client does not know whether he is the victim of
	an active attack or not. Therefore, our choice here will affect
	implementations behaviour in networks in which only passive attacks
	may happen. From Mr Austein:

> [*] Open MAY/SHOULD/MUST question here here.  I've written it as MUST
> because that's my own preference, but others may disagree.  Reasoning,
> such as it is: the context of this whole subsection assumes an
> environment in which we are worried about MitM attacks, so I think
> we've already handled Hugh's "passive attacks only" context elsewhere,
> and I suspect that anything weaker than a MUST in this context here is
> going to cause delays during IETF Last Call, etcetera.

I would like to be sure that Mr Daniel has no further arguments about
the interest of the gateway field to be different from the RR owner in
the "passive attacks only context".

In the context of active attack, I agree on a MUST, but how the
implementation would know in which context it is ? Is it a choice from
the administrator ?

I think we can state it this way:

In an environment in which only passive attacks are likely to happen,
both key information and gateway option are to be trusted, and no specific
end-to-end integrity protection is required.

In an environment in which active attacks are likely to happen, both key
information and gateway option are extremely vulnerable without the
use of end-to-end integrity protection. Thus, in such an environment,
the dns client MUST refuse any gateway field different from the RR owner
name. Note that this implies coherence of types between RR owner name
and gateway field (both IPv4 or both FQDN or both IPv6 etc), thus the
use of self "." is recommanded for ease of use.

Clients using IPSECKEY RR MAY provide a way to choose that no protection
against active attacks is required. In this latter case, the client
MAY restrict its use of the IPSECKEY RR to cases where the RR owner
name matches.

I'm really sorry to mess around with these problems of MAY/SHOULD/MUST,
but I fear current statements let opened too many questions or may lead
to restrict too much.

--
Jean-Jacques Puig
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.