Exception while processing 'no-addresses' flag in KrbApReq.java

[Szabolcs Pota]

[+ 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 <hbhotz at dslextreme.com>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.
> Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu
>
>
>
>


-- 
Szabolcs Pota
Morgan Stanley | MSJava, EAI (MSSM)
Lechner Odon fasor 8 | Floor 07
Budapest, 1095
Phone: +36 1 881-3979
Szabolcs.Pota at morganstanley.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20110325/92d218b7/attachment.htm>