Hi Max, On Tue, Mar 29, 2011 at 4:35 PM, Weijun Wang <[email protected]> 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 <[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]> >>> >>> -- Szabolcs Pota Morgan Stanley | MSJava, EAI (MSSM) Lechner Odon fasor 8 | Floor 07 Budapest, 1095 Phone: +36 1 881-3979 [email protected]
