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

[Szabolcs Pota]

Hi Max,

The client was Java in all cases. I've tried with the following
combinations:

   - Open JDK b133 with JGSS
   - Open JDK b133 with MIT native Kerberos
   - JDK 6u23 with JGSS
   - JDK 6u23with MIT native Kerberos

The result is always the same:

Caused by: sun.security.krb5.internal.KrbApErrException: Incorrect net
address (38)
        at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:329)
~[na:na]
        at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:146) ~[na:na]
        at
sun.security.jgss.krb5.InitSecContextToken.<init>(InitSecContextToken.java:108)
~[na:na]
        at
sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:761)
~[na:na]

Regards,

Szabolcs

On Mon, Mar 28, 2011 at 2:21 PM, Weijun Wang <weijun.wang at oracle.com> wrote:

> 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>
>>
>>


-- 
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/20110329/acc8adbd/attachment.htm>