Re: New naming draft submitted

On Sun, 2005-02-20 at 15:42, Sam Hartman wrote:
> 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. 

Some text I wrote for a (now expired, hopefully soon to be resurrected)
draft on IPsec API requirements took a slightly different approach
at the question of naming.

Here's an excerpt:

8. WHO

   This is perhaps the most tricky part of the problem.  Existing IPsec
   key management protocols provide a wide variety of authentication
   methods -- preshared secrets, public key, Kerberos, X.509
   certificates, etc.,

   There are several potential uses for names provided by IPsec:

8.1 OPAQUE IDENTITY

   It should be possible to determine that two IPsec-protected
   communications conducted within a short to medium time frame were
   with the same authenticated peer; it should be possible to use a
   received identity to initiate a communication back to that identity.

   Example cases: connectionless replies; linking ftp control and data
   connections.

   The application need only be able to determine if two identities are
   equal.

8.2 AUDITING

   It should be possible for an application to construct a log entry
   naming the peer.

8.3 ACCESS CONTROL

   While policy rules may allow traffic to be blocked entirely, it's
   often necessary for a program to provide services to mutually
   suspicious clients.  It should be possible for a service to make
   appropriate access control decisions based on the identity of the
   peer; in addition, the peer's certificate may contain interesting
   SubjectAltName or other attributes which may have relevance for the
   application; it may also be possible for the system to derive other
   attributes from the peer's identity.

8.4 ATTRIBUTES/CREDENTIALS

   [Mission Creep Alert] In many cases, an application is not so much
   interested in the peer's name, but rather in some other attribute of
   the peer.  Exactly where and how to map from long-term keys to these
   attributes needs to be nailed down; it may well be that this is best
   left as a local issue.

   Some of this is probably out of scope for the working group; however,
   we should not preclude others from building on this.

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