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

Weijun Wang weijun.wang at oracle.com
Mon Mar 28 12:21:13 UTC 2011


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 <hbhotz at dslextreme.com
> <mailto: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 <mailto:Henry.B.Hotz at jpl.nasa.gov>, or
>     hbhotz at oxy.edu <mailto: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 <mailto:Szabolcs.Pota at morganstanley.com>
>



More information about the security-dev mailing list