Re: identifiers and security

On 28-jun-04, at 13:52, Erik Nordmark wrote:

>> The advantages of not having identifiers are that it's easier to be
>> backward compatible and less new stuff to worry about.

> This is a terminology nit, but I think all approaches to multihoming
> support have some identifier - whether it is a FQDN, or a list of 
> locators.

Sure, there always is an identifier, obviously I was getting at the 
situation where there isn't new/separate value that fulfills this 
function. BTW, I don't consider a _set_ of locators _a_ identifier, as 
membership of the set presumably isn't fixed and having more than one 
way to express the same identity (not the same thing as having more 
than one identity) is a very bad idea. (X.400 anyone?)

> What is interesting is whether there is a new ID name space, as you 
> said in
> the first paragraph,

Yes.

> and whether those IDs are visible to the applications.

Ah, but that's a very different issue. I think by definition the 
identifiers are visible to the application. There are other values that 
may not be visible to the application and relevant, though. (And some 
of you may prefer to call those identifiers, but then we need another 
term for the application-visible values.) There are many places in the 
stack where (currently) the same bit string performs different 
functions. If we make the identifier/locator split this immediately 
begs the question whether that's enough, maybe we need to dig deeper. I 
tried to look at this a while ago in my "9 steps" (or similar) message.

> Taking NOID as an example of with no new ID namespace, the amount of
> work (in the form of DNS lookups in forward and reverse maps)
> will also result in stronger association between FQDNs and locators
> than we have today.

Even if we assume DNSSEC?

> So I think it is inevitable that providing "do no harm" security for
> the multihoming will accidentally improve security a bit in some cases.

Beware of stuff you get for free...

> I've certainly entertained ideas that are a lot weaker than NOID,
> for instance just have the peers exchange their sets of locators
> plus a cleartext cookie/context tag when the setup the state,
> and then do a RR check before sending packets to a new locator,
> but I've received pushback from folks that I wouldn't characterize as
> security geeks, that this would be too weak.

I don't think this is universally true. Certainly, this is too weak for 
TLS or IPsec sessions that can now be broken by an attacker, unlike 
before. But why would this be too weak for talking to Google over 
unprotected TCP/IP?

> But perhaps it is time to writeup something like that and subject it
> to wider scruteny, combined with your suggestion below.

Right.

> I've been trying to layer things so that IPsec and TLS benefit from
> the multihoming support by sitting above the layer that handles the
> multiple locators, and HIP essentially is layered in the same place.
> So perhaps one should explore, taking into account IKEv2 and MOBIKE 
> work,
> an approach which layers the multihoming support above IPsec when IPsec
> is used?

I suppose this wouldn't be much of a problem for IPsec. This could even 
be done today by piping packets through a multihoming mechanism and 
then take the resulting packets and feed them through IPsec. Obviously 
this means more IPsec negotiation and state as now there must be an SA 
for every locator pair used rather than one for the identifier pair.

I wouldn't want to try something like this with TLS, though. I'm 
thinking more along the line of violating layers and modify IPsec/TLS 
such that the wedge or modified IP can obtain keys that are exchanged 
by modified IPsec/TLS. Something like putting the secret instructions 
for the messager in the locked briefcase he's carrying. This works well 
except for the first trip of course...

> Thus something which is quite insecure (weaker than NOID as above) when
> IPsec isn't used, but when IPsec is used it is as strong as with IPsec 
> in
> today's Internet.
> Is anybody interested in exploring these ideas further?

Apart from me, you mean?  (-: