Re: Addressless tickets in 0.8.x

[Harald Barth <haba@kth.se>]

> RFC1918 updates RFC1597.

Yeah, and does that make any difference in detecting that one end 
of the connection is inside 
     10.0.0.0        -   10.255.255.255  (10/8 prefix)
     172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
     192.168.0.0     -   192.168.255.255 (192.168/16 prefix)
and the other end is not?

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

> 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?

> 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?

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

> 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?

> > One could change all the krb5_appdefault_*() functions that they do
> > not take a default value, but read a global table containing option,
> > default, max and min value and maybe help string for the option in
> > question. Then a small app can be linked against the same table and
> > print the table in man page format.
> 
> I really don't want to maintain the code in to places, if I needd to  
> do that
> I could just maintain a manfile instead.

I mean you maintain one appdefault_defaults.c file and then you have
all the text that changes in there. To make the manpage you do
a 

cc -o manpagebuilder manpagebuilder.c appdefault_defaults.c && ./manpagebuilder > foo.man

> How about other krb5_config() function ?

Today something like:

#define  KRB5_ADDRESSLESS_DEFAULT TRUE.
#if KRB5_ADDRESSLESS_DEFAULT == TRUE
    something
#endif

Could be replaced with something like:

struct bar { .... KRB5_ADDRESSLESS_DEFAULT, TRUE }
int appdefaults_get_default(char *) /* accesses struct bar */

if ( appdefaults_get_default("no-addesses") ){
   something
}

And if you don't like strings, use enums but then you have to
have enum->string and string->enum functions.

Harald.

PS: Unrelated trivia: Someone in Kalmar uses rfc1918.com. Maybe
someone there reads this. Hi!