gss_init_sec_context with delegated_cred_handle error
Hi, When I pass GSS_C_NO_CREDENTIAL as cred_handle to gss_init_sec_context(), I got no error. But when I pass delegated_cred_handle (output from gss_accept_sec_context) as cred_handle to gss_init_sec_context(), I got 'Matching credential not found' error. It seems that when passing delegated_cred_handle gss_init_sec_context care about ticket cache. In my case the default principal in the ticket cache was upper case use...@my.domain.com. Currently, I can remedy the situation by running a 'kinit use...@my.domain.commailto:use...@my.domain.com -t -v $KRB5_KTNAME' to create a lower case default principal use...@my.domain.commailto:use...@my.domain.com. I have two questions: 1. Why gss_init_sec_context care about ticket cache default principal when using delegated_cred_handle? Why it works when I am not delegating? 2. Is there a better approach to remedy this problem other than kinit since the ticket cache could expire overtime, I am running a web service that could stop working if it expires? Is there a code based solution? I am using krb5 version 1.11.5 -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
RE: gss_init_sec_context with delegated_cred_handle error
The mailing server mess up the string of the principal into email Here is uppercase principal USERID @ MY.DOMAIN.COM and the lower case principal is userid @ my.domain.com From: Xie, Hugh Sent: Thursday, October 23, 2014 11:39 AM To: kerberos@mit.edu Subject: gss_init_sec_context with delegated_cred_handle error Hi, When I pass GSS_C_NO_CREDENTIAL as cred_handle to gss_init_sec_context(), I got no error. But when I pass delegated_cred_handle (output from gss_accept_sec_context) as cred_handle to gss_init_sec_context(), I got 'Matching credential not found' error. It seems that when passing delegated_cred_handle gss_init_sec_context care about ticket cache. In my case the default principal in the ticket cache was upper case use...@my.domain.commailto:use...@my.domain.com. Currently, I can remedy the situation by running a 'kinit use...@my.domain.commailto:use...@my.domain.com -t -v $KRB5_KTNAME' to create a lower case default principal use...@my.domain.commailto:use...@my.domain.com. I have two questions: 1. Why gss_init_sec_context care about ticket cache default principal when using delegated_cred_handle? Why it works when I am not delegating? 2. Is there a better approach to remedy this problem other than kinit since the ticket cache could expire overtime, I am running a web service that could stop working if it expires? Is there a code based solution? I am using krb5 version 1.11.5 -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: What happened to PKCROSS?
On Mon, Oct 20, 2014 at 09:04:18AM +0200, Rick van Rein wrote: Hello Nico, Are you still working on your neo-PKCROSS draft? I’d love to see it I'll update the I-D soon, but I still don't have cycles for implementing. move forward! Me too. You may have seen draft-vanrein-dnstxt-krb1 pop up; it arranges that a No, I hadn't. client (or its KDC) can figure out under what realm to address for a given hostname. This is based on DNS TXT RR + DNSSEC. This will cause realm crossover inquiries, even for hitherto unknown realms. To enable the KDC to resolve such inquiries, we’ll need some form of PKCROSS based on “remote KDC credentials in DNSSEC”. Well, I envision two options: - client-driven PKCROSS (as described earlier) - TGS-driven PKCROSS, which would work for existing, unmodified clients, and which would not create persistent, long-term symmetric cross-realm trust principals. Here the TGS would use the client-drivern PKCROSS protocol as a client, but would obtain a cacheable, short-lived cross-realm credential that can be used to issue cross-realm TGTs for the given x-realm TGS principal name. In both cases using DANE as much as possible, with stapled DANE as Google wanted to do for HTTPS (though they've backed off for now). My thoughts were: * KDC’s peer to cross realms * publish the KDC server key using DANE * employ PKINIT with DH to establish a one-sided krbtgt Yes. Your thoughts were (AFAIK): * clients hold a certificate (possibly from their local KX509 service) * clients connect to remote KDC’s * publish CA certs for clients using DANE The first is tighter on security, the second supports more flows. The first can be implemented on the basis of the second: the TGS uses PKINIT at the remote realm to acquire a special (because of the TGS' client principal name in its PKINIT certificate) cross-realm TGT whose purpose is to enable the client TGS to issue x-realm TGTs for that one x-realm. Mixing the two will probably lead to mutual weakening, so I am thinking that it might be useful to split the two, but ensuring that they remain as compatible as can be. Does that sound wise to you? I don't agree. A client-driven PKCROSS is feasible now. In fact, I heard earlier this week of a couple of environments where it actually *is* used in practice. (The user has a TGT in a given realm, uses kx509/kca to get a certificate, then PKINIT to get a TGT at the remote realm.) I don't have specifics, and I gather that the AS at the remote realm had to have local enhancements added to make this possible. A client-driven PKCROSS is deployable even if you use a KDC whose vendor isn't likely to add KDC-driven PKCROSS any time soon. That's convenient! A client-driven PKCROSS protects the client's privacy relative to its home KDC. A client-driven PKCROSS is sub-optimal though: a TGS-driven PKCROSS can significantly reduce the number of PK operations needed, compared to a client-driven PKCROSS. The TGS-driven PKCROSS can be substantially similar to the client-driven one, with the TGS being the client. Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
