Exception while processing 'no-addresses' flag in KrbApReq.java
Szabolcs Pota
Szabolcs.Pota at morganstanley.com
Tue Mar 29 17:09:21 UTC 2011
Hi Max,
On Tue, Mar 29, 2011 at 4:35 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 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.
>
Yes. I've tested and the client addresses are indeed set.
>
> 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.
>
Unfortunately we don't have control over both sides. The client could be any
kerberos enabled client in any language. We have a custom protocol for
ticket exchange and leverage the GSS API to process those.
>
> 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.
>
This is exactly what I think would be appropriate until there is no better
way to get the client IP. Or at least some config option that could switch
the check on or off.
> I'll think about this more.
>
> Thanks
> Max
>
>
Thanks,
Szabolcs
>
>
> 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>
>>>
>>>
--
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/ec89c934/attachment.htm>
More information about the security-dev
mailing list