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

[Shawn Emery <[e-mail]>]

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.

>> 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?

>> 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.

>> 5.1. PAD Format
>>
>>      Which Host Service Key are you referring to here?:
> host/fqdn@REALM

This should be defined or referenced.

>>     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.

>> 6.2 GSS-API Authenticator Extension
>>
>>      Refer to draft-ietf-krb-wg-gss-cb-hash-agility on extension
>> formats.
> I'll take a note.

Thanks,

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