Subject: Re: [Ietf-krb-wg] Comments on adopting draft-sorce-krbwg-general-pad as a work item

From: Shawn Emery <[email-masked]>
Date: Wed, 03 Aug 2011 01:31:10 -0600

On 07/17/11 05:11 PM, Simo Sorce wrote:
> On Mon, 2011-07-11 at 00:23 -0600, Shawn Emery wrote:
>> On 07/10/11 07:27 AM, Simo Sorce wrote:
>>> On Sun, 2011-07-10 at 01:04 -0600, Shawn Emery wrote:
>>>> On 06/29/11 08:11 AM, Sam Hartman wrote:
>>>>> The chairs would like to solicit comments on whether the PAD draft is
>>>>> ready for us to adopt as a working group draft.
>>>>> Please send comments by July 10.
>>>> Sorry for the late reply...
>>>>
>>>> General:
>>>>
>>>> It would be nice to standardize the interface (C bindings) or provide
>>>> examples for accessing PAC data through standards track interfaces.
>>>>
>>>> There have been implementations of non-standardized interfaces, such
>>>> as gss_inquire_sec_context_by_oid.  It would be out of scope for this
>>>> draft to cover a GSS-API like this, but should be considered as a
>>>> complimentary draft.
>>>>
>>>> 4.4 PAD-DNS-Domain
>>>>
>>>>       Couldn't you also have multiple domains map to a single realm?
>>> This refers to the main domain name in use, others can be available but
>>> they are not relevant for user authorization data.
>>>
>>>> 4.6. PAD-Domain-UUID
>>>>
>>>>       uuid_t is 128 bits, shouldn't this be in alignment with uuid*
>>>> functions?
>>>>       Providing a reference on how the Domain-UUID is constructed would
>>>> be helpful.
>>> This is vague as we want to allow easy mapping of Windows Domain SIDs
>>> into this field for interop purposes. So this is literally just a Unique
>>> Identifier, I can change the name if it is felt that using UUID is
>>> confusing.
>> Yes, this would be helpful.
> Ok, what about PAD-UDID (Unique Domain ID) ?

This clarifies things better.

>>>> 4.7. PAD-Posix-Username
>>>>
>>>>       In general it would be nice to have at least a non-normative
>>>> reference for the Posix attributes.
>>> I have been asked to refer to RFC 2307 for attributes. I will go thorugh
>>> RFC 2307 before the next draft and verify if the definitions there are
>>> adequate (For example I do not want to force these names to be case
>>> sensitive although implementations are free to treat them in a case
>>> sensitive way if they really, really want to.
>> Is there is a reference that could be used that is not experimental?
> I looked into the POSIX.1-2008 standard* next to see if these attributes
> are defined well enough to use it as a normative reference.
> It looks like they are very loosely defined in there.
>
>
> * IEEE Std 1003.1-2008 / The Open Group bBase Specifications Issue 7

That is unfortunate.

>>>> 4.14. PAD-AlternateNames
>>>>
>>>>       Why can't this be more generic for any naming attribute that
>>>> applications can use?
>>> I am not sure I understand the objection, can you make an example of
>>> what you'd like to use this attribute for ?
>> Refer to draft-ietf-kitten-gssapi-naming-exts::6. Representation of
>> Attribute Names.
> Uhmm you defined some characters as special in that document (space and
> ':'), but I don;t see any discussion about escaping in case those
> characters are part of the actual names as opposed to be just
> separators. ANy reason why this is not a problem in that document ?

Escape sequences are required for primary components in your use cases?

>>>> 5.1. PAD Format
>>>>
>>>>       Which Host Service Key are you referring to here?:
>>> host/fqdn@REALM
>> This should be defined or referenced.
> OK.
>
>>>>      o  Optional Host Service Key Signature (for use by trusted services
>>>>         on a host)
>>>>
>>>>       What about typed holes for future extensions?
>>> Perhaps, but I am not sure we want to make this field too extensible, it
>>> makes creating interoperable implementations harder if not done right.
>> We should do it right then.
>>
>>>> 6.1 SignedPricipalAuthorizationData
>>>>
>>>>       Why is the following a SHOULD?:
>>>>
>>>>       Unless otherwise
>>>>          explicitly administratively configured, the key SHOULD be found
>>>>          by substituting the service name component of the principal
>>>> name
>>>>          of the service with 'host'.
>>>>
>>>>       As services should try to avoid using shared keys such as this.
>>> This is not a shared key, this is useful exactly in the opposite case
>>> where the service key differs from the host key and you cannot trust a
>>> PAD signed by a service key as host. I would make it a MUST if I didn't
>>> already spot cases where an implementation might need to use a different
>>> trusted key (thinking about clusters here).
>>> Keep in mind that this signature is optional, so you can omit it
>>> completely, but if you want to use it you SHOULD provide a signature
>>> based on the host key so that a host trusted service can verify the PAD
>>> independently from the less trusted service receiving and forwarding it.
>>> In environment where host and service keys are the same (like in AD)
>>> this field is useless as it adds no security, so you should just omit
>>> it.
>> I think this should be clarified in the draft.
> OK
>
>>>> 6.2 GSS-API Authenticator Extension
>>>>
>>>>       Refer to draft-ietf-krb-wg-gss-cb-hash-agility on extension
>>>> formats.
>>> I'll take a note.

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

---

From: Simo Sorce <[email-masked]>
Date: Wed, 03 Aug 2011 08:31:02 -0400

> Escape sequences are required for primary components in your use

I am not sure, : is invalid in user/group names in posix, and although I
don't think the white space is kosher I've seen it used (esp when doing
Windows interop as there some default groups have spaces in the name).
So I was wondering what should be done if one of the chars your document
defines as special needs to be used.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

---

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Aug 2011 09:41:35 -0400

I think that RFC 2307 can be an appropriate normative reference even if
it is experimental.  The IETF has a procedure for such references.  If
the working group believes that is the right reference to use, I will
start tilting at process windmills. I think it unlikely any of them will
turn into giants. Mostly, I need to walk through the argument based on
our process documents with the IESG, and I expect that to be relatively
easy to pull off.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Leif Johansson <[email-masked]>
Date: Wed, 03 Aug 2011 15:54:44 +0200

> our process documents with the IESG, and I expect that to be relatively

Maybe Luke should consider pushing 2307 up the standards track - it has
clearly been a successful experiment.

	Cheers Leif

---

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Aug 2011 11:42:58 -0400

>>>>> "Leif" == Leif Johansson <[email-masked]> writes:

    Leif> On 08/03/2011 03:41 PM, Sam Hartman wrote:
    >> 
> I think that RFC 2307 can be an appropriate normative reference even
    >> if it is experimental.  The IETF has a procedure for such
    >> references.  If the working group believes that is the right
    >> reference to use, I will start tilting at process windmills. I
    >> think it unlikely any of them will turn into giants. Mostly, I
    >> need to walk through the argument based on our process documents
    >> with the IESG, and I expect that to be relatively easy to pull
    >> off.

    Leif> Maybe Luke should consider pushing 2307 up the standards track
    Leif> - it has clearly been a successful experiment.

I'd be happy to shepherd that as an individual submission if Luke wants
to do that.  I don't think this Kerberos document should be blocked on
such an effort.  Also, I'll caution that moving something from
experimental to standards-track is something you should probably only do
if you're interested in making changes and updates.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Aug 2011 11:45:52 -0400

Hmm.  We have special characters in the attribute names; I don't think
we have any in attribute values.  In general I'd expect any attribute
name that was complex enough to need escaping to be something like a URI
and come with its own escaping mechanism.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Howard Chu <[email-masked]>
Date: Wed, 03 Aug 2011 11:13:25 -0700

> our process documents with the IESG, and I expect that to be relatively

What exactly are you referencing in 2307? (Sorry, haven't been paying close 
attention to this list in a while.) I think most sites moved to RFC2307bis, 
and there's still this later revision to consider:

http://tools.ietf.org/id/draft-howard-rfc2307bis-02.txt

-- 
   -- 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
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Aug 2011 14:19:09 -0400

>>>>> "Howard" == Howard Chu <[email-masked]> writes:

    >> with the IESG, and I expect that to be relatively easy to pull

    Howard> What exactly are you referencing in 2307? (Sorry, haven't
    Howard> been paying close attention to this list in a while.) I
    Howard> think most sites moved to RFC2307bis, and there's still this
    Howard> later revision to consider:

    Howard> http://tools.ietf.org/id/draft-howard-rfc2307bis-02.txt

mostly the semantics for the attributes in 2307.
A reference to an internet draft would be inappropriate here.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Howard Chu <[email-masked]>
Date: Wed, 03 Aug 2011 11:23:11 -0700

Sam Hartman wrote:
>>>>>> "Howard" == Howard Chu<[email-masked]>  writes:
>
Understood, but if you're also talking about promoting 2307 from Experimental 
to Standards Track status, that would be a mistake as well.

---

From: Luke Howard <[email-masked]>
Date: Wed, 3 Aug 2011 18:43:07 +0000

Perhaps 2307bis could be intended for standards track but... let's see, we've been updating it for 13 years now. Hmm. :-)

-- Luke

---

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Aug 2011 15:18:18 -0400

>>>>> "Luke" == Luke Howard <[email-masked]> writes:

    Luke> Perhaps 2307bis could be intended for standards track
    Luke> but... let's see, we've been updating it for 13 years
    Luke> now. Hmm. :-) -- Luke

Please see my desire not to block on 2307bis or on any reclassification
of any of the above.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Leif Johansson <[email-masked]>
Date: Thu, 04 Aug 2011 10:38:58 +0200

> Understood, but if you're also talking about promoting 2307 from
> Experimental to Standards Track status, that would be a mistake as well.
> 

Well it sounds like Luke and others are at work revising 2307 which
would seem to make this an ideal time for moving to standards track.

I agree with Sam that we should not hold up the PAD draft on that
process though.

	Cheers Leif