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

[Simo Sorce <[e-mail]>]

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

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

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

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

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

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