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

From: "Shawn M. Emery" <[email-masked]>
Date: Fri, 01 Aug 2008 18:08:44 -0600

Henry B. Hotz wrote:
> On Jul 31, 2008, at 10:58 AM, Shawn M. Emery wrote:
>
>   
>> Henry B. Hotz wrote:
>>     
>>> On Jul 31, 2008, at 2:39 AM, Shawn M. Emery wrote:
>>>
>>>       
>>>> <snip>
>>>>         
>>>> 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.
>>>>         
>>> 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.
>>>       
>> 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.
>>     
>
> 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.
>
>   
>> In regards to allowable ticket flags, DISALLOW_SVR disallows server- 
>> only
>> 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.
>   

Might be useful, I haven't seen an implementation that does this on 
purpose.  When set, it may make things hard for debugging and might 
break some administrative environments, but may provide extra security 
measures for those who want it.

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

---

From: Leif Johansson <[email-masked]>
Date: Mon, 11 Aug 2008 10:48:03 +0200

> I think it's helpful to understand the various principal attributes in
> 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.

Note that the opaque policy field is always there. The question in my mind
is if there is enough generality in a bit-field to warrant its presence in the
model in addition to the opaque policy field.

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Mon, 11 Aug 2008 10:48:03 +0200

Cheers Leif