Subject: New naming draft submitted

From: Sam Hartman <[email-masked]>
Date: Sun, 20 Feb 2005 16:42:40 -0500

I've submitted draft-ietf-kitten-gss-naming-01.txt.  I think this one
is readyish for last-call, but would like to ask Nico and Martin to
review it and tell me what's broken and then consider the next
revision for a real last call. 

I believe I've addressed Nico's comments this time around.  I've also
pulled in some information from the discussion of SPKM and naming.

The one thing I haven't touched is text on mechanisms that
respond/assert to multiple names.  I think I convinced Nico that in
the normal v3 case we didn't want that behavior unless you were
limiting a credential in some way.  However I thing there was still
some question about how the ability to assert multiple names might
work for v2 mechanisms/applications.

In any solution to this problem we need to keep Martin's comments
about v2 names and how they interact with credentials in mind.  In
particular, you can have a single cert/ticket/something that can
generate different gssapi credentials depending on what name you use
to acquire credentials.  You cannot have more than one credential for
the same mechanism as part of a gssapi credential.  Also, once you
have a v2 gssapi credential, the name you get back from enquiring that
credential must be the same as the name you would get from enquiring a
context established with that credential.

For v3, it's not clear clear to what extent this shows up as multiple
GSSAPI credentials for the same underlying cert/ticket that are
selected by the name you acquire or whether there is more mechanism
involved.

Does there need to be text about this in the draft?  If so, where and
roughly what?

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 22 Feb 2005 17:42:46 -0600

I very much like this I-D -- it covers the problem description and
proposed solutions quite well, with the right level of abstraction and
sufficiently detailed examples.

Comments:

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

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

   Why would that beinadequate?  To begin with, using the cert itself as
   the exported name token would cause problems with respect to
   certificate expiration, revocation and replacement.  If a cert is
   revoked and a new one (with a new subjectPublicKey) is issued then
   any exported name tokens for the revoked cert will fail to match the
   peer when it uses the new cert.  But also, there may be environments
   where there are multiple certs corresponding to the same DN but with
   different extensions/attributes/subjectAltName where using certs as
   the exported name token may be inapropriate.  And then there's
   applications where one might want to grant access to some resource to
   any peer whose cert has some EKU, or to any peer whose cert is from
   some subset of a larger PKI, and so on -- name-based authorization
   just does not support this well, as pointed out in your I-D already.

 - section 4, we may need some additional operations:

    - inquire additional typing information given a name attribute OID

    - name attribute type/value display operation

    - utility for extended name display

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

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

   In particular, if the GSS-API is to support name attribute assertion
   on a per-security context basis, in addition to, rather than only on
   a per-credential basis, then applications definitely need to know
   whether a given name attribute was merely asserted, or actually
   authenticated.

 - section 4.2, IMO these extensions should allow for arbitrary name
   attribute assertion by peers.  See above.

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

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

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

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

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

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

Nico
--