Hi Max,<br><br><div class="gmail_quote">On Tue, Mar 29, 2011 at 4:35 PM, Weijun Wang <span dir="ltr"><<a href="mailto:weijun.wang@oracle.com">weijun.wang@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Update:<br>
<br>
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.<br></blockquote><div><br>Yes. I've tested and the client addresses are indeed set.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
So forget about that patch.<br>
<br>
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.<br></blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
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.<br></blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I'll think about this more.<br>
<br>
Thanks<br>
Max<div><div></div><div class="h5"><br></div></div></blockquote><div><br>Thanks,<br><br>Szabolcs <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div class="h5">
<br>
<br>
On 03/29/2011 10:13 PM, Weijun Wang wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Szabolcs<br>
<br>
On 03/29/2011 09:18 PM, Szabolcs Pota wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Max,<br>
<br>
The client was Java in all cases. I've tried with the following<br>
combinations:<br>
<br>
* Open JDK b133 with JGSS<br>
* Open JDK b133 with MIT native Kerberos<br>
</blockquote>
<br>
I guess this means using the native GSS provider with<br>
-Dsun.security.jgss.native=true.<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
* JDK 6u23 with JGSS<br>
* JDK 6u23with MIT native Kerberos<br>
<br>
The result is always the same:<br>
</blockquote>
<br>
This is a little strange. I do think the service ticket on the client<br>
should not have the caddr field. If your client is using JAAS, can you<br>
print out the KerberosTicket in its private credentials set after the<br>
first initSecContext() is called?<br>
<br>
Anyway, I've made some code changes to my own OpenJDK code repository<br>
and is now supporting this field in a service ticket. However, since<br>
JGSS is token-based, it has no way to get the IP address of the client<br>
from a socket object. In order to support no-addresses=false, both the<br>
client and server have to turn on channel bindings, and then the server<br>
will be able to get the client's IP address from it.<br>
<br>
Do you build OpenJDK? If so, you can try out my attached patch.<br>
<br>
Thanks<br>
Max<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Caused by: sun.security.krb5.internal.KrbApErrException: Incorrect net<br>
address (38)<br>
at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:329)<br>
~[na:na]<br>
at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:146) ~[na:na]<br>
at<br>
sun.security.jgss.krb5.InitSecContextToken.<init>(InitSecContextToken.java:108)<br>
<br>
~[na:na]<br>
at<br>
sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:761)<br>
~[na:na]<br>
<br>
Regards,<br>
<br>
Szabolcs<br>
<br>
On Mon, Mar 28, 2011 at 2:21 PM, Weijun Wang <<a href="mailto:weijun.wang@oracle.com" target="_blank">weijun.wang@oracle.com</a><br>
<mailto:<a href="mailto:weijun.wang@oracle.com" target="_blank">weijun.wang@oracle.com</a>>> wrote:<br>
<br>
Sorry for the late reply.<br>
<br>
I suppose your client side program is not in Java? Because in JDK a<br>
service ticker's addresses field is always null.<br>
<br>
Thanks<br>
Max<br>
<br>
<br>
<br>
<br>
<br>
On 03/25/2011 07:53 PM, Szabolcs Pota wrote:<br>
<br>
[+ adding back security-dev]<br>
<br>
Hi Henry,<br>
<br>
Thank you for your reply. My answers are below.<br>
<br>
On Fri, Mar 25, 2011 at 1:26 AM, Henry B. Hotz<br>
<<a href="mailto:hbhotz@dslextreme.com" target="_blank">hbhotz@dslextreme.com</a> <mailto:<a href="mailto:hbhotz@dslextreme.com" target="_blank">hbhotz@dslextreme.com</a>><br>
<mailto:<a href="mailto:hbhotz@dslextreme.com" target="_blank">hbhotz@dslextreme.com</a> <mailto:<a href="mailto:hbhotz@dslextreme.com" target="_blank">hbhotz@dslextreme.com</a>>>><br>
wrote:<br>
<br>
No-list reply since I'm subscribed with an alias which my<br>
ISP won't<br>
let me send with.<br>
<br>
On Mar 23, 2011, at 5:16 AM, Szabolcs Pota wrote:<br>
<br>
> Our global krb5.conf files have 'noaddresses=false' for both<br>
client<br>
> and server hence we get this exception. Please correct me if<br>
someone<br>
> thinks that setting this flag to false on the server side<br>
would be<br>
> incorrect.<br>
<br>
There are two issues here. The one you're not looking at is<br>
that<br>
that config option is different for every one of the major C<br>
implementations of Kerberos.<br>
<br>
[appdefaults]<br>
no-addresses = true # Heimdal<br>
no_addresses = true # Sun<br>
<br>
[lidefaults]<br>
noaddresses = true # MIT<br>
<br>
I have no idea which of these is understood by Java, though<br>
I would<br>
guess the Sun one, and hope that all of them are. Also the<br>
default<br>
value varies with the version. AFAIK all now default to disable<br>
address checking.<br>
<br>
<br>
As I've seen in sun.security.krb5.Config#useAddresses() it reads<br>
either<br>
the 'noaddresses' or the 'no-addresses' flag and indeed the<br>
default is<br>
no-addresses=true. We are using 'noaddresses' that is parsed without<br>
problems by the current code.<br>
<br>
------<br>
<br>
As for what you are actually asking about: almost all of us<br>
have<br>
stopped worrying about addresses because the address check<br>
does not<br>
work in the real world with ubiquitous NAT and multiple<br>
private IP<br>
spaces. (Are you sure you're not running into one of those?) I<br>
personally would not care if Java simply stopped supporting<br>
address<br>
checking.<br>
<br>
That may not be an appropriate thing for the universal JGSS<br>
implementation to do though.<br>
<br>
What's *supposed* to happen (without reading the RFC) is the<br>
endpoint gets the IP from the socket for the other end, and<br>
compares<br>
it with the appropriate field in the ticket. If they don't<br>
match,<br>
then the ticket *may* have been copied and is being injected<br>
from<br>
someplace it shouldn't be.<br>
<br>
Since (almost) nobody is using the feature anymore I would<br>
actually<br>
be surprised if it works on IPv6 networks. As I said it is<br>
guaranteed to fail if there is a NAT involved.<br>
<br>
-----<br>
<br>
To answer the specific question in the above paragraph, I<br>
would say<br>
checking addresses on a server is actually wrong if *any* of the<br>
clients are connecting via VPN, or through your typical home<br>
router<br>
box. It can only be guaranteed correct if all clients are<br>
on the<br>
same corporate network as the server.<br>
<br>
<br>
I agree with you that checking the client address is error prone and<br>
even the RFC says so. It could be done only on a best effort<br>
basis. At<br>
the moment I think that the server should do one of the followings:<br>
<br>
1. If EncTicketPart.caddr is set then try to get the client<br>
IP and<br>
<br>
check if it is in the list. If it is not then it *may*<br>
throw and<br>
exception.<br>
2. Skip the whole no-addresses processing because of the<br>
unreliable<br>
<br>
client IP check.<br>
<br>
My problem is that the current logic in KrbApReq java does non<br>
of these<br>
but throws an Exception. This prevents us using OpenJDK with<br>
'noaddresses=false' in Kerberos configuration.<br>
<br>
Regards,<br>
<br>
Szabolcs<br>
<br>
------------------------------------------------------<br>
The opinions expressed in this message are mine,<br>
not those of Caltech, JPL, NASA, or the US Government.<br>
<a href="mailto:Henry.B.Hotz@jpl.nasa.gov" target="_blank">Henry.B.Hotz@jpl.nasa.gov</a> <mailto:<a href="mailto:Henry.B.Hotz@jpl.nasa.gov" target="_blank">Henry.B.Hotz@jpl.nasa.gov</a>><br>
<mailto:<a href="mailto:Henry.B.Hotz@jpl.nasa.gov" target="_blank">Henry.B.Hotz@jpl.nasa.gov</a><br>
<mailto:<a href="mailto:Henry.B.Hotz@jpl.nasa.gov" target="_blank">Henry.B.Hotz@jpl.nasa.gov</a>>>, or<br>
<a href="mailto:hbhotz@oxy.edu" target="_blank">hbhotz@oxy.edu</a> <mailto:<a href="mailto:hbhotz@oxy.edu" target="_blank">hbhotz@oxy.edu</a>> <mailto:<a href="mailto:hbhotz@oxy.edu" target="_blank">hbhotz@oxy.edu</a><br>
<mailto:<a href="mailto:hbhotz@oxy.edu" target="_blank">hbhotz@oxy.edu</a>>><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
--<br>
Szabolcs Pota<br>
Morgan Stanley | MSJava, EAI (MSSM)<br>
Lechner Odon fasor 8 | Floor 07<br>
Budapest, 1095<br>
Phone: +36 1 881-3979<br>
<a href="mailto:Szabolcs.Pota@morganstanley.com" target="_blank">Szabolcs.Pota@morganstanley.com</a><br>
<mailto:<a href="mailto:Szabolcs.Pota@morganstanley.com" target="_blank">Szabolcs.Pota@morganstanley.com</a>><br>
<mailto:<a href="mailto:Szabolcs.Pota@morganstanley.com" target="_blank">Szabolcs.Pota@morganstanley.com</a><br>
<mailto:<a href="mailto:Szabolcs.Pota@morganstanley.com" target="_blank">Szabolcs.Pota@morganstanley.com</a>>><br>
<br>
<br>
<br>
<br>
--<br>
Szabolcs Pota<br>
Morgan Stanley | MSJava, EAI (MSSM)<br>
Lechner Odon fasor 8 | Floor 07<br>
Budapest, 1095<br>
Phone: +36 1 881-3979<br>
<a href="mailto:Szabolcs.Pota@morganstanley.com" target="_blank">Szabolcs.Pota@morganstanley.com</a> <mailto:<a href="mailto:Szabolcs.Pota@morganstanley.com" target="_blank">Szabolcs.Pota@morganstanley.com</a>><br>
<br>
</blockquote></blockquote>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Szabolcs Pota<br>Morgan Stanley | MSJava, EAI (MSSM)<br>Lechner Odon fasor 8 | Floor 07<br>Budapest, 1095<br>Phone: +36 1 881-3979<br><a href="mailto:Szabolcs.Pota@morganstanley.com" target="_blank">Szabolcs.Pota@morganstanley.com</a><br>
<br>