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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>
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.
[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>, or
[email protected] <mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
--
Szabolcs Pota
Morgan Stanley | MSJava, EAI (MSSM)
Lechner Odon fasor 8 | Floor 07
Budapest, 1095
Phone: +36 1 881-3979
[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
--
Szabolcs Pota
Morgan Stanley | MSJava, EAI (MSSM)
Lechner Odon fasor 8 | Floor 07
Budapest, 1095
Phone: +36 1 881-3979
[email protected] <mailto:[email protected]>
