Forwarding Henry's reply to the list<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Henry B. Hotz</b> <span dir="ltr"></span><br><br>Sorry I can't post this back to the list directly. My "From" address doesn't match my subscription address.<br>
<br>
It's probably possible to use the existing, public, stable JGSS API to create a connection to yourself. The "transport" would be simply referencing the tokens from one end/context in the calls made to the other end/context. If such an internal connection could be established, that should be equivalent to verifying the tgt against the keys for the "server" end of the self-connection.<br>
<br>
Actually doing all that in application code seems really ugly, but it might be nice to put some sample code in the 1.4/1.5/1.6 docs if you don't back-port the new "verify" options.<br>
<br>
Just to be explicit: I second "cneberg"s request, and your proposed config options to control a built-in capability look good. You could give them default values of "host/`localhost`@DEFAULT-REALM" for verifyInitCredsService, and the default system keytab file for verifyInitCredsKeytab, but then you would need to consider if you want the check on by default.<br>
<br>
I think I would vote for having the check done by default in 1.7, but left off in 1.6- if it's backported there.<br>
<br>
Feel free to forward my reply to the list if you want.<br>
<div><div></div><div class="h5"><br>
On Mar 11, 2011, at 8:46 AM, cneberg wrote:<br>
<br>
> Yes, thank you that should work nicely. Is this a feature you would consider back porting, even to Oracle's vanilla jdk 1.6 (or even 1.5)? Since the warning against its improper usage isn't in the documentation for the module, it may not have been heard by developers.<br>
><br>
> Documentation for module<br>
> <a href="http://www.docjar.com/docs/api/com/sun/security/auth/module/Krb5LoginModule.html" target="_blank">http://www.docjar.com/docs/api/com/sun/security/auth/module/Krb5LoginModule.html</a><br>
><br>
> Thanks<br>
> Christopher<br>
><br>
> On Thu, Mar 10, 2011 at 7:43 PM, Weijun Wang <<a href="mailto:weijun.wang@oracle.com">weijun.wang@oracle.com</a>> wrote:<br>
> Cool. We may look at this, possibly adding more lines into the JAAS login file, something like<br>
><br>
> com.sun.security.jgss.krb5.initiate {<br>
><br>
> com.sun.security.auth.module.Krb5LoginModule<br>
> required<br>
> verifyInitCredsService=service/host@REALM<br>
> verifyInitCredsKeytab=service.ktab<br>
> };<br>
><br>
> We've always warned users that simply passing the Krb5LoginModule doesn't mean anything and you should always uses this subject in JGSS but not regarding itself as some kind of authenticity (say, use it in a java policy file). This new function might change that.<br>
><br>
> Thanks<br>
> Max<br>
><br>
><br>
><br>
> On 03/11/2011 10:19 AM, cneberg wrote:<br>
> >> So it reads the user's secret key from a keytab and try to decrypt<br>
> the TGT to see if it can successfully get the session key inside<br>
><br>
> No, it uses the user's TGT to obtain a service ticket for a known valid<br>
> key in the keytab file (any valid service key would work usually<br>
> HOST/hostname keys, or HTTP/hostname keys are used). When you do a<br>
> successful kinit (AS request) you are validating that the user and the<br>
> KDC agree that the user's key was correct, but until you actually try to<br>
> use the TGT to get a service ticket for a known service you have not<br>
> validated that the KDC you are talking to is not spoofed. In other<br>
> words, if this extra step is not performed inside the Krb5LoginModule<br>
> then it is not secure for validating passwords. Doing this extra step<br>
> is standard in mod_auth_kerb, pam_krb5, etc. If it is not supported it<br>
> will require a change in the openjdk code.<br>
><br>
> -Christopher<br>
><br>
> On Thu, Mar 10, 2011 at 6:36 PM, Weijun Wang <<a href="mailto:weijun.wang@oracle.com">weijun.wang@oracle.com</a><br>
> <mailto:<a href="mailto:weijun.wang@oracle.com">weijun.wang@oracle.com</a>>> wrote:<br>
><br>
> Hi Christopher<br>
><br>
> I'm not familiar with that function. So it reads the user's secret<br>
> key from a keytab and try to decrypt the TGT to see if it can<br>
> successfully get the session key inside?<br>
><br>
> This is a part of the Krb5LoginModule login process: it receives a<br>
> TGT from the KDC and use either the password or keytab (depending on<br>
> your JAAS config file) to decrypt it. After the commit() method is<br>
> called, the credentials (containing both the TGT and the session<br>
> key) are stored as private credentials in the JAAS subject.<br>
><br>
> All public methods we have around Kerberos are APIs defined in JAAS<br>
> and JGSS.<br>
><br>
> BTW, this mailing list is used to discuss the development of OpenJDK<br>
> security libraries itself. For API usage or general technical<br>
> support, it would be better to post a question in the forum. There<br>
> are much more experts on application programming there.<br>
><br>
> <a href="http://forums.oracle.com/forums/forum.jspa?forumID=963" target="_blank">http://forums.oracle.com/forums/forum.jspa?forumID=963</a><br>
><br>
> Thanks<br>
> Max<br>
><br>
><br>
><br>
> On 03/11/2011 01:49 AM, cneberg wrote:<br>
><br>
> How do I get the com.sun.security.auth.module.Krb5LoginModule login<br>
> module to verify the TGT against a key in the keytab like is done in<br>
> krb5_verify_init_creds() which is part of C Krb5 API?<br>
><br>
> Notes on that API<br>
><br>
> <a href="http://www.daemon-systems.org/man/krb5_verify_init_creds.3.html" target="_blank">http://www.daemon-systems.org/man/krb5_verify_init_creds.3.html</a><br>
><br>
> Thanks,<br>
> Christopher<br>
><br>
><br>
><br>
<br>
</div></div></div><br>