[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.