Re: [Ietf-krb-wg] Fwd: New Version Notification for draft-ietf-krb-wg-kdc-model-05

Jeffrey Hutzelman wrote:
> --On Thursday, August 06, 2009 11:32:14 PM +0200 Leif Johansson
> <leifj@mnt.se>  wrote:
>
>
>>>     This is a multivalued attribute containing enumerated string values
>>> representing the ticket flags defined in RFC4120 Section 2 "Ticket Flag
>>> Uses and Requests"...
>
> Strings?  Why?  The ticket flags aren't strings.

>> You're thinking of the policy as a set of the allowed flags? A ticket
>> flag  policy could be a lot more complex than that. Perhaps something
>> like  this:
>>
>> A ticket flag policy specifies the ticket flags allowed for tickets
>> issued for a principal. Minimally the expression of a ticket flag SHOULD
>> be a set of  ticket flags as defined in RFC 4120, section2.
>
> That SHOULD is silly, since there are features which use multiple ticket
> flags that cannot be logically separated.  For example, it makes little
> sense to allow MAY-POSTDATE but not POSTDATED, or FORWARDABLE but not
> FORWARDED.
>
> It's silly to set policy indicating whether the INITIAL, PRE-AUTHENT,
> and/or HW-AUTHENT flags may be set; the KDC should set them according to
> the actual situation (though one might want policy controlling whether any
> what preauth is required for a principal).  Similarly for
> TRANSITED-POLICY-CHECKED or OK-AS-DELEGATE.

Right, the actual flag bits are not useful for a ticket policy. Instead you 
need a name for a feature, which may be implemented by ticket flags, or bits 
in the KRB_AS_REQ kdc_options, or some other means (like pre-auth data). Which 
is one reason to use enumerated strings here. E.g. instead of 
ALLOW-POSTDATE+POSTDATED+VALIDATE use a string "POSTDATING" to represent that 
feature.

>> Sure but that doesn't mean the realm needs to be an element of the
>> model. We could define Realm as a first order object of the model and
>> have associations from the principals to each realm in which it lives but
>> I'm not sure what value that would add to the text...
>>
>> In other words: what property of realms other than the association of
>> the principal to it do you want to model?
>
> In other other words, despite the fact that we usually separate them in the
> protocol, how is the realm name not just part of the principal name?

I guess the realm has no interesting properties of its own, other than being a 
container for the policies and principals. OK, I'll drop this point too.
-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg