Re: Addressless tickets in 0.8.x

[Love Hörnquist Åstrand <lha@kth.se>]

>> One problem is that when you forward ticket to another host, you have
>> to know, or guess, what addresses the host have addresses.
>
> If I get a connection to something at the other end, the computer
> I'm on somehow figured out where to connect to.

Yes, you know one address, not all of them. Good, how about the
other addresses the other end has and it didn't tell you about ?

>> In gss-api
>> you don't know the addresses, because the addresses is hidden behind
>> a name, and the name doesn't reflect all addresses a host have.
>
> Asuming correct setup and not NAT, is there a case where we can't
> figure out enough?

No, since not all addresses are published in public databases. Like  
v6 names
for IPv6 enable hosts.

>> I'm
>> pretty sure I've recived a bug-repport from you on this issue, you  
>> can't
>> have the cake and eat it too.
>
> If I remember correctly, the behaviour was that the wrong address of a
> bunch (v6 and v4) was chosen. If there is more than one addr, why not
> issue tickets for all of them - one of them should be the correct and
> can be used later. And at the same time there were endian problems in
> the address forwarding part of the code. I don't think this has to do
> anything with NAT, does it?

But the problem is the host didn't publish a v6 address for the  
hostname and
you ended up with a v4 only ticket. With gss-api there is no binding  
to the
transportlayer, so there is no connection to if the ticket is valid  
to use or not.

It got everything do it with NAT and more. Its about the problem of  
putting
addresses into the ticket. Putting addresses into ticket breaks how  
machines
and software are used in reality. In reality hosts changes addresses,  
don't
publish all addresses and there are NATs/devices that break E2E.


>> Even worse when the host is running ipv6 with privacy-protected
>> addresses
>> and is constantly switching address to make sure its not trackable.
>
> I bought one of these camo-colored pens and now I can't find it again
> in the woods? If someone is using means to be not trackable, it should
> be acceptable for that person to know the implications.

Its just one example of how it breaks, another is a laptop that is  
migrating
from one network to another or host that gets reassigned a new  
addresses.
Thinks like this happen and users expect it still to work.

>> Binding tickets to addresses was a bad idea, it should really be some
>> other permanat identifier, if anything at all.
>
> And why was it bad in general to give tickets an address? Or do you
> mean that the IP-number is a bad choice of address? Do we have a
> better choice?

IP-address is a bad choice since it no longer a stable (over the time  
of a ticket)
identifier that is verifiable by the peer.

All of these addresses problem can be worked around, code that
auto updates tickets to new addresses to included newly assigned
addreses and other intresting hacks.

You still have not told us why its a real security problem there is
no ip-address in the ticket.

Love