[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [IPSECKEY] Security Considerations (pass 2)
[Sorry for the delay, took yesterday off]
At Wed, 21 May 2003 11:45:36 -0400, Michael Richardson wrote:
>
> >> A protocol which permits the gateway field to delegate to a different
> >> host MAY want to restrict this feature when end-to-end integrity is
> >> not available.
>
> Rob> Er, from what is the gateway field different? The RR owner name? How
> Rob> should this test be applied when:
>
> Rob> a) the RR owner name is an encoded address (reverse tree) and the
> Rob> gateway field is a DNS name, or
>
> Rob> b) the RR owner name is a "normal" DNS name and the gateway field is
> Rob> one of the address forms?
>
> Rob> Bit of a slippery slope.
>
> Without integrity protection, one *might* want to permit only the situation
> where "No gateway is present", or IP an IP address is present that it is ==
> to the thing that one looked up originally. The first example is shows a node
> that has delegate to self.
So perhaps something like the following would do (keyboarded, might
need wordsmithing):
Note that the danger here only applies to cases where the gateway
field of the IPSECKEY RR indicates a different entity than the owner
name of the IPSECKEY RR. In cases where the end-to-end integrity of
the IPSECKEY RR is suspect, the end client MUST[*] restrict its use
of the IPSECKEY RR to cases where the RR owner name matches the
content of the gateway field.
[*] 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.
If anybone thinks that MUST is wrong here, please speak up.
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.