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

[Shawn Emery <[e-mail]>]

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