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

[Weijun Wang]

Update:

I think I was wrong about caddr in a service ticket. JRE does not 
provide the address field in its TGS-REQ packet, but the KDC can still 
set the caddr in a ticket.

So forget about that patch.

Anyway, my previous mail on address from channel binding is still valid. 
You can try calling setChannelBinding() on both side and there will be 
no exception.

We can relax this check a little: if there is no channel binding then 
there is no way to get the client's IP. In this case, we can skip the 
caddr check.

I'll think about this more.

Thanks
Max


On 03/29/2011 10:13 PM, Weijun Wang wrote:
> Hi Szabolcs
>
> On 03/29/2011 09:18 PM, Szabolcs Pota wrote:
>> 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
>
> I guess this means using the native GSS provider with
> -Dsun.security.jgss.native=true.
>
>> * JDK 6u23 with JGSS
>> * JDK 6u23with MIT native Kerberos
>>
>> The result is always the same:
>
> This is a little strange. I do think the service ticket on the client
> should not have the caddr field. If your client is using JAAS, can you
> print out the KerberosTicket in its private credentials set after the
> first initSecContext() is called?
>
> Anyway, I've made some code changes to my own OpenJDK code repository
> and is now supporting this field in a service ticket. However, since
> JGSS is token-based, it has no way to get the IP address of the client
> from a socket object. In order to support no-addresses=false, both the
> client and server have to turn on channel bindings, and then the server
> will be able to get the client's IP address from it.
>
> Do you build OpenJDK? If so, you can try out my attached patch.
>
> Thanks
> Max
>
>>
>> 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
>> <mailto: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>
>> <mailto: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>
>> <mailto: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> <mailto: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>
>> <mailto: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 <mailto:Szabolcs.Pota at morganstanley.com>
>>