disallow requests naming principal as a service
Moore, Patrick
pcmoore at sandia.gov
Mon Mar 25 20:11:01 EST 2002
Thanks Nico, this solution looks OK to me.
It modifies the current semantics of KRB5_KDB_DISALLOW_SVR
a bit -- hope that's OK. Besides allowing U2U on a princ that is
set DISALLOW_SVR, it will not support a princ that may be a
normal service but must not be used with dup_skey service
tickets. (I can't imagine who might want that feature --
although it's for some reason supported in DCE secd's.)
With this suggested fix, my client would need to try a U2U
handshake upon getting a PRINC_UNKNOWN error from the MIT KDC.
Not streamlined - but functional enough. Long term, I'd prefer
using KDC_ERR_MUST_USE_USER2USER and report that back to the
client when you see that DUP_SKEY is allowed but SVR is not.
Pat
> -----Original Message-----
> From: Nicolas Williams [mailto:Nicolas.Williams at ubsw.com]
> Sent: Friday, March 22, 2002 2:44 PM
> To: Matt Crawford
> Cc: Moore, Patrick; ietf-krb-wg at anl.gov; krbdev at mit.edu
> Subject: Re: disallow requests naming principal as a service
>
>
> [Cc'ing krbdev at mit.edu]
>
> Sounds like kdc/kdc_util.c:validate_tgs_req():
>
> 1306 /* Server must be allowed to be a service */
> 1307 if (isflagset(server.attributes, KRB5_KDB_DISALLOW_SVR)) {
> 1308 *status = "SERVER NOT ALLOWED";
> 1309 return(KDC_ERR_S_PRINCIPAL_UNKNOWN);
> 1310 }
>
> should be changed to:
>
> 1306 /* Server must be allowed to be a service */
> 1307 if (!isflagset(request->kdc_options,
> KDC_OPT_ENC_TKT_IN_SKEY) &&
> 1308 isflagset(server.attributes, KRB5_KDB_DISALLOW_SVR)) {
> 1309 *status = "SERVER NOT ALLOWED";
> 1310 return(KDC_ERR_S_PRINCIPAL_UNKNOWN);
> 1311 }
>
> so as to match the handling of DUP SKEY:
>
> 1293 /* Server must allow DUP SKEY requests */
> 1294 if (isflagset(request->kdc_options,
> KDC_OPT_ENC_TKT_IN_SKEY) &&
> 1295 isflagset(server.attributes,
> KRB5_KDB_DISALLOW_DUP_SKEY)) {
> 1296 *status = "DUP_SKEY DISALLOWED";
> 1297 return(KDC_ERR_POLICY);
> 1298 }
>
> Someone should file a bug report :)
>
> Cheers,
>
> Nico
>
> On Thu, Mar 21, 2002 at 08:19:25PM -0600, Matt Crawford wrote:
> > > This is the reason another flag is needed so that a user
> is allowed as
> > > a service, but only via the ENC-TKT-IN-SKEY option, so
> that you can
> > > authenticate to users as a service, but without exposing a
> > > conventional TGS_REP to attack on a user's key.
> >
> > It was pointed out to me in private mail (I don't know why, the
> > sender isn't usually shy) that DISALLOW_SVR in MIT's KDC does stop
> > user-to-user. Since there already exists a separate
> > DISALLOW_DUP_SKEY flag this surprised me, but it seems to be true.
> > I suggest that the MIT krb5 has all the flags it needs, it just
> > doesn't use them properly. Still, they probably have to
> invent a new
> > one to avoid breaking some existing deployment somewhere ......
> --
More information about the krbdev
mailing list