disallow requests naming principal as a service

[John Brezak]

The initial User2user restriction in Windows will also use the
KDC_ERR_S_PRINCIPAL_UNKNOWN with a typed-data of 128 (indicating
user2user required) in the e-data. This is needed to retain backward
compat with existing Windows clients so that they can fallback to NTLM
until they can get u2u switching in the SSP.

-----Original Message-----
From: Moore, Patrick [mailto:pcmoore at sandia.gov] 
Sent: Monday, March 25, 2002 5:10 PM
To: krbdev at mit.edu
Cc: John Brezak (E-mail); 'Nicolas Williams'; Matt Crawford
Subject: RE: disallow requests naming principal as a service


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 ......
> --