Subject: [Ietf-krb-wg] kdc-model attributes suggested by Shawn Emery

From: Leif Johansson <[email-masked]>
Date: Wed, 30 Jul 2008 10:12:49 +0200

The attributes Shawn suggested fall into 3 distinct categories:

* Auditing:

numberOfFailedAuthenticationAttempts (int)
lastFailedAuthentication (time)
lastSuccessfulAuthentication (time)
lastCredentialChange (time+principal)
lastModified (time+principal)
created (time+principal)

I'm fine either way with these. There is no doubt in my mind that things like 
these would be needed in (say) a MIB. The question is (as Sam put it) if the 
focus of the kdc model is management or auditing.  I'm leaning towards 
including them.

* General info

description (free-text)

I doubt the value actually. In most cases (say an LDAP schema) existing 
attributes part of orthogonal information-models covers this already. I don't
think it is needed.

* Policy

maximumTicketLifetime (time delta)
maximumRenewableLifetime (time delta)
authenticationFlags (eg "requires pre auth")

The first two I feel are pretty ok - I tend to view their absence in the 
current version as a bug. The last one is more problematic. It would be
difficult to model in a good way. In the general case authentication 
requirements ("you must be at least this tall to authenticate") can only
be modelled as a blob which is already in the document. I think we should
skip authenticationFlags.

Comments?

	Cheers Leif

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 30 Jul 2008 11:00:53 -0700

> lastModified (time+principal)

There's the issue of how do you maintain these across multiple KDC's,  
but I think that's out of scope for this document.

> current version as a bug.

OK.

> The last one is more problematic. It would be

I don't think it makes sense to include a-F's unless you define the  
flags themselves.  I suppose you can have provision for new-extra  
flags and that makes it complicated.  Still, a few flags are pretty  
standard.  We should at least define the ones that are mentioned in  
4120.

Require-pre-auth, BTW might be more complex than just a flag, since  
there may be some combination of PKINIT and/or OTP which is really  
required (while password/timestamp are prohibited).  Perhaps we have a  
pre-auth flag and then an optional pre-auth policy which defines what  
pre-auth mechanisms are valid for this entry?

---

From: "Shawn M. Emery" <[email-masked]>
Date: Thu, 31 Jul 2008 02:50:10 -0600

>> attributes part of orthogonal information-models covers this  

Is Heimdal using this?  I know we do, strictly for administrator 
purposes; auditing, etc.

> standard.  We should at least define the ones that are mentioned in  

These are ticket flags, which don't necessarily intersect with principal 
attribute data.  In any case here is the attribute list of what I sent 
to Leif so far:

DISALLOW_POSTDATED         // disallow post-dated tickets
DISALLOW_FORWARDABLE  // disallow delegated tickets
DISALLOW_TGT_BASED          // disallow ticket issuance from TGT
DISALLOW_RENEWABLE        // disallow renewal of ticket
DISALLOW_PROXIABLE          // disallow proxy tickets
DISALLOW_DUP_SKEY            // disallow user-to-user ticket
DISALLOW_ALL_TIX                // disallow the issuance of any ticket
REQUIRES_PRE_AUTH             // requires pre-authentication
REQUIRES_HW_AUTH              // requires hardware pre-authentication
REQUIRES_PWCHANGE           // requires new password
DISALLOW_SVR                         // disallow service ticket
PWCHANGE_SERVICE              // password change service
SUPPORT_DESMD5                    // support for des-cbc-md5

> pre-auth mechanisms are valid for this entry?

Good points, I don't know what other implementors are doing to enforce 
this.  Heimdal, RSA, MS, etc. could you provide input here?

Shawn.
--

---

From: Tom Yu <[email-masked]>
Date: Thu, 31 Jul 2008 05:19:44 -0400

> SUPPORT_DESMD5                    // support for des-cbc-md5

The above attributes look like they are implementation-specific.  Do
we agree that this is actually the set we want going forward?  I have
already seen a request for a set of flags allowing more orthogonal
control of whether a principal is allowed to be client-only or
service-only.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Shawn M. Emery" <[email-masked]>
Date: Thu, 31 Jul 2008 03:39:06 -0600

> control of whether a principal is allowed to be client-only or

I think it's helpful to understand the various principal attributes in 
order to determine if we have a complete data model.  Specifying the 
various attributes in the document may or may not be beneficial, 
however, as Henry pointed out, there may be other possible fields (e.g. 
pre-auth flags and pre-auth policy) that have not be thought about, but 
required.  Having no attribute field in the data model is unacceptable 
to me.

Shawn.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 31 Jul 2008 10:23:33 -0700

> required.  Having no attribute field in the data model is unacceptable

My inclination is to try to pare this down to a more "minimal  
required" set.  I don't think the MD5 one should be specified.  I do  
think the requires-pre-auth one should be there, but if set there MAY  
also be a list of pa mechs that are allowed (expandable as new ones  
are defined).  Should be flags to specify client-only, server-only,  
both (neither?).  Also disallow-all-tix.  Not sure about the others.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: "Shawn M. Emery" <[email-masked]>
Date: Thu, 31 Jul 2008 11:58:19 -0600

Henry B. Hotz wrote:
>> <snip>

> both (neither?).  Also disallow-all-tix.  Not sure about the others.

In regards to pa mechs; I think Tom's update:

* if/which preauth is required

covers your use-case, however it should be clear that they are separate 
items.

In regards to allowable ticket flags, DISALLOW_SVR disallows server-only 
tickets, but I'm not sure about client.  Agreed on MD5.

Shawn.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 31 Jul 2008 11:44:52 -0700

> covers your use-case, however it should be clear that they are  

Now that I realize Tom's comments are part of this thread, I still  
agree with them.  I think they are the right scope, but I think we  
need to be more specific for Lief's draft-RFC.

> tickets, but I'm not sure about client.  Agreed on MD5.

It doesn't match either MIT or Heimdal (or anyone else) AFAIK, but  
shouldn't we just have DISALLOW_SVR and a parallel DISALLOW_USR flag?   
If people don't like that, how about something related to the name  
type from 4120?  I'd rather not enshrine the current implementation  
restriction that only has DISALLOW_SVR.