[33622] in Kerberos
Re: threading best practices?
daemon@ATHENA.MIT.EDU (Nico Williams)
Fri Jul 22 20:22:29 2011
MIME-Version: 1.0
In-Reply-To: <1311379475.23877.198.camel@t410>
Date: Fri, 22 Jul 2011 19:22:24 -0500
Message-ID: <CAK3OfOjgiooOi9kTLuXPRwbb+FR8MKkKn909cpk0eNQq70fmoA@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Greg Hudson <ghudson@mit.edu>
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Fri, Jul 22, 2011 at 7:04 PM, Greg Hudson <ghudson@mit.edu> wrote:
> On Fri, 2011-07-22 at 18:10 -0400, Nico Williams wrote:
>> Why are you not using the GSS-API?
>
> Chris started out by asking about user-to-user auth, so I didn't
> redirect him to GSSAPI since, as far as I know, GSSAPI doesn't have a
> story there (for the krb5 mech, at least).
Indeed, the krb5 mech has no story here. I'm thinking we should have
the initiator send a bogus AP-REQ with a new auth-options flag. If
the server understands it it would respond with a KRB-ERROR with the
TGT in the e-data, else with a plain KRB-ERROR.
It'd be nice to also make KRB_AP_ERR_USER_TO_USER_REQUIRED a retriable
error, with the TGT in e-data. Again, a new auth-options flag would
help here. (But this error is not likely to be very common at all.
Instead I imagine that clients will get KDC_ERR_MUST_USE_USER2USER and
so they'll just know to ask for a u2u TGT.)
Nico
--
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos