[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Addressless tickets in 0.8.x



> Ehm, is this really necessary? Is this a concession towards all users
> that are behind NAT? But in this case, would it not be good enough to
> have something in between (say called "auto") which uses the
> no-address strategy only when the client is a RFC1597 adrdess and the
> other part is not? (No, I don't feel the urge to make "auto" work for
> folks that use NAT between different RFC1597 nets).

RFC1918 updates RFC1597.

One problem is that when you forward ticket to another host, you have
to know, or guess, what addresses the host have addresses. 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. 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.

Even worse when the host is running ipv6 with privacy-protected  
addresses
and is constantly switching address to make sure its not trackable.

Binding tickets to addresses was a bad idea, it should really be some
other permanat identifier, if anything at all.


>>> Is there any documentation of the defaults of such options (besides
>>> the source)? Manpage?
>>
>> No, but if you figure out a way to generate those automaticly it
>> would be great.
>
> 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.

How about other krb5_config() function ?

Love