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