Sorry for the late reply.
I suppose your client side program is not in Java? Because in JDK a
service ticker's addresses field is always null.
Thanks
Max
On 03/25/2011 07:53 PM, Szabolcs Pota wrote:
[+ adding back security-dev]
Hi Henry,
Thank you for your reply. My answers are below.
On Fri, Mar 25, 2011 at 1:26 AM, Henry B. Hotz <[email protected]
<mailto:[email protected]>> wrote:
No-list reply since I'm subscribed with an alias which my ISP won't
let me send with.
On Mar 23, 2011, at 5:16 AM, Szabolcs Pota wrote:
> Our global krb5.conf files have 'noaddresses=false' for both client
> and server hence we get this exception. Please correct me if someone
> thinks that setting this flag to false on the server side would be
> incorrect.
There are two issues here. The one you're not looking at is that
that config option is different for every one of the major C
implementations of Kerberos.
[appdefaults]
no-addresses = true # Heimdal
no_addresses = true # Sun
[lidefaults]
noaddresses = true # MIT
I have no idea which of these is understood by Java, though I would
guess the Sun one, and hope that all of them are. Also the default
value varies with the version. AFAIK all now default to disable
address checking.
As I've seen in sun.security.krb5.Config#useAddresses() it reads either
the 'noaddresses' or the 'no-addresses' flag and indeed the default is
no-addresses=true. We are using 'noaddresses' that is parsed without
problems by the current code.
------
As for what you are actually asking about: almost all of us have
stopped worrying about addresses because the address check does not
work in the real world with ubiquitous NAT and multiple private IP
spaces. (Are you sure you're not running into one of those?) I
personally would not care if Java simply stopped supporting address
checking.
That may not be an appropriate thing for the universal JGSS
implementation to do though.
What's *supposed* to happen (without reading the RFC) is the
endpoint gets the IP from the socket for the other end, and compares
it with the appropriate field in the ticket. If they don't match,
then the ticket *may* have been copied and is being injected from
someplace it shouldn't be.
Since (almost) nobody is using the feature anymore I would actually
be surprised if it works on IPv6 networks. As I said it is
guaranteed to fail if there is a NAT involved.
-----
To answer the specific question in the above paragraph, I would say
checking addresses on a server is actually wrong if *any* of the
clients are connecting via VPN, or through your typical home router
box. It can only be guaranteed correct if all clients are on the
same corporate network as the server.
I agree with you that checking the client address is error prone and
even the RFC says so. It could be done only on a best effort basis. At
the moment I think that the server should do one of the followings:
1. If EncTicketPart.caddr is set then try to get the client IP and
check if it is in the list. If it is not then it *may* throw and
exception.
2. Skip the whole no-addresses processing because of the unreliable
client IP check.
My problem is that the current logic in KrbApReq java does non of these
but throws an Exception. This prevents us using OpenJDK with
'noaddresses=false' in Kerberos configuration.
Regards,
Szabolcs
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email protected] <mailto:[email protected]>, or
[email protected] <mailto:[email protected]>
--
Szabolcs Pota
Morgan Stanley | MSJava, EAI (MSSM)
Lechner Odon fasor 8 | Floor 07
Budapest, 1095
Phone: +36 1 881-3979
[email protected] <mailto:[email protected]>
