Re: New naming draft submitted

[Sam Hartman <hartmans at mit.edu>]

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:

Hi.  A new draft has been submitted which I believe addresses your
comments.  See below.

    Nicolas>  - section 1, 2nd paragraph, not only do names change
    Nicolas> over time, but they may even be re-used, which poses a
    Nicolas> real security problem.

Text added.

    Nicolas>  - section 3, you may want to mention that an exported
    Nicolas> name token for x.509 certs that included all attributes
    Nicolas> of the cert, or the cert itself, also would be an
    Nicolas> inadequate solution, and why.

Done.
    Nicolas>  - section 4, we may need some additional operations:

    Nicolas>     - inquire additional typing information given a name
    Nicolas> attribute OID

    Nicolas>     - name attribute type/value display operation

    Nicolas>     - utility for extended name display

    Nicolas>     - name attribute comparison and/or export/import,
    Nicolas> unless the name attribute octet string is required to be
    Nicolas> in some canonical format that can be compared directly

Added text indicating this is not an exaustive list.

    Nicolas>  - section 4, it may be worthwhile to point out that
    Nicolas> knowing the source of a name attribute would be good.
    Nicolas> Name attributes may have been added to a name without any
    Nicolas> authentication, or they may have been asserted, but not
    Nicolas> authenticated during security context establishment, or
    Nicolas> they may be part of one's or a peer's credentials, and
    Nicolas> therefore authenticated.

This is covered later.

    Nicolas>  - section 4.3, another possibility is that
    Nicolas> gss_export_name() for such mechanisms returns different,
    Nicolas> unique, results on each invocation, even if for the same
    Nicolas> name, and that the exported name tokens may either not be
    Nicolas> importable or, if imported, do not compare as equal to
    Nicolas> the original name object.

True.

    Nicolas>  - section 5, GSS-API applications do not have access to
    Nicolas> peers' credential handles, which outright rules out the
    Nicolas> use of credential extensions for extending GSS-API
    Nicolas> authorization beyond name-based authorization, unless
    Nicolas> credential extensions are paired with context extensions,
    Nicolas> which section 6 hints at.  Personally, name attributes
    Nicolas> are a simpler, and cleaner design than paired credential
    Nicolas> and security context extensions.

the intent was for context extensions as well.

    Nicolas>    Credential extensions may be useful for other
    Nicolas> purposes, as you point out, which too, I think, makes
    Nicolas> name attributes a cleaner design, as it keeps separate
    Nicolas> things separate.  Think of a credential extension for
    Nicolas> specifying whether a a delegated credential should in
    Nicolas> turn be delegatable -- such an extension has not business
    Nicolas> being like a name attribute.

I agree with you but the draft is intended to be general.

    Nicolas>  - section 6, this section should probably be merged with
    Nicolas> section 5.  See above.

    Nicolas>  - We may want some examples indicating how applications
    Nicolas> are expected to use these facilities.  Or we may want to
    Nicolas> leave that to an actual specification.

Do you see merging these as a requirement?  Personally I like the current organization.

    Nicolas>  - section 7, I don't understand this text.


What don't you understand.  Section 7 attempts to discuss the problem
that today's mail to krbdev discusses in more detail.  You want to
choose source name based on target name.


Can you suggest clarification?

_______________________________________________
Kitten mailing list
Kitten at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten