Please participate in IETF66

At IETF66 the Kerberos, Kitten and SASL Working Groups will be
experimenting with a new means of incorporating remote participants into
the meeting discussion.  In order to ensure that the comments of remote
participants as communicated via the Jabber Rooms will be seen by those
physically present, the Jabber Room will be projected onto a second
video screen.

The Kerberos Working Group will be meeting on Monday, July 10th during
the Morning Session (0900-1130 EDT) in Room 519A.

The Kitten Working Group will be meeting on Monday, July 10th during
the first Afternoon Session (1300-1500 EDT) in Room 519A.

The SASL Working Group will be meeting on Monday, July 10th during
the second Afternoon Session (1520-1720 EDT) in Room 519A.

The Audio Stream for these three sessions can accessed via

  http://videolab.uoregon.edu/events/ietf/ietf667.m3u

Use the following link to test your audio setup prior to the meetings:

  http://videolab.uoregon.edu/events/ietf/test.m3u

The Jabber Room Server is "rooms.jabber.ietf.org".  The room names are
"krb-wg", "kitten" and "sasl".

We look forward to your participation.

Jeffrey Altman

draft-ietf-kitten-gssapi-domain-based-names-02.txt - did not get published by the IETF Secretariat

The attached message from Nico Williams was sent to the
Internet-Drafts <at> ietf.org mailbox prior to the cutoff date
one minute after draft-ietf-kitten-krb5-gssapi-domain-based-names-02.txt
which was published.  The draft was neither published nor rejected.
Due to this failure on the part of the IETF Secretariat a Working Group
Last Call which I intended to announce tonight on both of these
documents will be postponed until both documents are published.

In the meantime, please find the time to review these documents.

Thank you.

Jeffrey Altman

From: Nicolas Williams <Nicolas.Williams <at> sun.com>
Subject: draft-ietf-kitten-gssapi-domain-based-names-02.txt
Date: 2006-06-26 11:40:26 GMT

NETWORK WORKING GROUP                                        N. Williams
Internet-Draft                                                       Sun
Expires: December 28, 2006                                 June 26, 2006

            GSS-API Domain-Based Service Names and Name Type

Please participate in IETF66 [Corrected Jabber Server Info]

At IETF66 the Kerberos, Kitten and SASL Working Groups will be
experimenting with a new means of incorporating remote participants into
the meeting discussion.  In order to ensure that the comments of remote
participants as communicated via the Jabber Rooms will be seen by those
physically present, the Jabber Room will be projected onto a second
video screen.

The Kerberos Working Group will be meeting on Monday, July 10th during
the Morning Session (0900-1130 EDT) in Room 519A.

The Kitten Working Group will be meeting on Monday, July 10th during
the first Afternoon Session (1300-1500 EDT) in Room 519A.

The SASL Working Group will be meeting on Monday, July 10th during
the second Afternoon Session (1520-1720 EDT) in Room 519A.

The Audio Stream for these three sessions can accessed via

  http://videolab.uoregon.edu/events/ietf/ietf667.m3u

Use the following link to test your audio setup prior to the meetings:

  http://videolab.uoregon.edu/events/ietf/test.m3u

The Jabber Room Server is "jabber.ietf.org".  The room names are
"krb-wg", "kitten" and "sasl".

We look forward to your participation.

Jeffrey Altman

IETF66 Agenda

The agenda is available from

  http://www3.ietf.org/proceedings/06jul/agenda/kitten.txt

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

Exposing the client realms of the anonymous client

In kitten, we have discussed this in detail, see the minutes for more
information. please review the relevant text for this:

   GSS-API defines the name_type GSS_C_NT_ANONYMOUS [RFC2743] to
   represent the anonymous identity.  In addition, Section 2.1.1 of
   [RFC1964] defines the single string representation of a Kerberos
   principal name with the name_type GSS_KRB5_NT_PRINCIPAL_NAME.  For
   the anonymous principals, the name component within the exportable
   name as defined in Section 2.1.3 of [RFC1964] MUST signify the realm
   name according to Section 2.1.1 of [RFC1964].  In this specification
   only the client/initiator can be the anonymous identity.

   Portable initiators are RECOMMENDED to use default credentials
   whenever possible, and request anonymity only through the input
   anon_req_flag [RFC2743] to GSS_Init_Sec_Context().

Here is the diff out:
>    GSS-API defines the name_type GSS_C_NT_ANONYMOUS [RFC2743] to
329,331d332
<    Portable initiators are RECOMMENDED to use default credentials
<    whenever possible, and request anonymity only through the input
<    anon_req_flag to GSS_Init_Sec_Context().
334,335c335
<
< Zhu, et al.             Expires December 5, 2006                [Page
6]
---
> Zhu, et al.             Expires December 3, 2006                [Page
6]
339a340,352

naming attributes

During the wg yesterday I was asked to forward my comments regarding
naming attributes to the list.

As far as I understand the point of the naming api extension is to
treat a name as an opaque extracting name attributes by attribute
identifier. There are several obvious examples of objects which could
be exposed by this api: X509 certs EKUs, SAML assertions, RDF graphs,
LDAP entries etc.

My problem is with the choice of OIDs as name attribute identifiers
is that several of the obvious examples don't use OIDs as their
native attribute identifiers. I would argue that using OIDs will
only get us into a rat-hole of having to maintain mappings from
OIDs to whatever the native name uses. Instead I would propose
using a URN which both provides a structured and managed namespace
aswell as including the OID namespace by reference.

	Cheers Leif

Re: naming attributes

On Tue, Jul 11, 2006 at 04:43:55PM +0200, Leif Johansson wrote:
> During the wg yesterday I was asked to forward my comments regarding
> naming attributes to the list.
> 
> As far as I understand the point of the naming api extension is to
> treat a name as an opaque extracting name attributes by attribute
> identifier. There are several obvious examples of objects which could
> be exposed by this api: X509 certs EKUs, SAML assertions, RDF graphs,
> LDAP entries etc.
> 
> My problem is with the choice of OIDs as name attribute identifiers
> is that several of the obvious examples don't use OIDs as their
> native attribute identifiers. I would argue that using OIDs will
> only get us into a rat-hole of having to maintain mappings from
> OIDs to whatever the native name uses. Instead I would propose
> using a URN which both provides a structured and managed namespace
> aswell as including the OID namespace by reference.

OTOH there are several obvious examples that do use OIDs as their native
attribute identifier (SANs, EKUs).

What to do?

The API being proposed is not a protocol, and its attribute identifiers
aren't used on the wire as an inherent result of their use in the API
(though where they map directly to actual uses on the wire specified in
other protocols then their use in the API will relate to their use on
the wire).

So it doesn't really matter what these identifiers are.

Re: naming attributes

Nicolas Williams wrote:
> 
> On Tue, Jul 11, 2006 at 04:43:55PM +0200, Leif Johansson wrote:
> > As far as I understand the point of the naming api extension is to
> > treat a name as an opaque extracting name attributes by attribute
> > identifier. There are several obvious examples of objects which could
> > be exposed by this api: X509 certs EKUs, SAML assertions, RDF graphs,
> > LDAP entries etc.
> > 
> > My problem is with the choice of OIDs as name attribute identifiers
> > is that several of the obvious examples don't use OIDs as their
> > native attribute identifiers. I would argue that using OIDs will
> > only get us into a rat-hole of having to maintain mappings from
> > OIDs to whatever the native name uses. Instead I would propose
> > using a URN which both provides a structured and managed namespace
> > aswell as including the OID namespace by reference.

URN might be somewhat self-descriptive, OIDs are never self-descriptive.
OTOH, OIDs are fairly small/short comparison of OIDs is foolproof and
OIDs themselves do not have any I18N/L10N issues (attribute values may still
have them).

It should be fairly easy to assign OIDs for attribute identifiers that
do not have them yet in the IETF GSS-API OID-space.

However, independent of what one choses, I don't see a way to save
application programmers from maintaining a mapping, because semantics
and code to process particular attributes will have to be programmed,
no matter what.

Re: naming attributes

Martin Rex wrote:
> Nicolas Williams wrote:
>> On Tue, Jul 11, 2006 at 04:43:55PM +0200, Leif Johansson wrote:
>>> As far as I understand the point of the naming api extension is to
>>> treat a name as an opaque extracting name attributes by attribute
>>> identifier. There are several obvious examples of objects which could
>>> be exposed by this api: X509 certs EKUs, SAML assertions, RDF graphs,
>>> LDAP entries etc.
>>>
>>> My problem is with the choice of OIDs as name attribute identifiers
>>> is that several of the obvious examples don't use OIDs as their
>>> native attribute identifiers. I would argue that using OIDs will
>>> only get us into a rat-hole of having to maintain mappings from
>>> OIDs to whatever the native name uses. Instead I would propose
>>> using a URN which both provides a structured and managed namespace
>>> aswell as including the OID namespace by reference.
> 
> URN might be somewhat self-descriptive, OIDs are never self-descriptive.
> OTOH, OIDs are fairly small/short comparison of OIDs is foolproof and
> OIDs themselves do not have any I18N/L10N issues (attribute values may still
> have them).
> 
> It should be fairly easy to assign OIDs for attribute identifiers that
> do not have them yet in the IETF GSS-API OID-space.
> 
> 
> However, independent of what one choses, I don't see a way to save
> application programmers from maintaining a mapping, because semantics
> and code to process particular attributes will have to be programmed,

Re: naming attributes

Leif Johansson wrote:
> 
> > 
> > However, independent of what one choses, I don't see a way to save
> > application programmers from maintaining a mapping, because semantics
> > and code to process particular attributes will have to be programmed,
> > no matter what.
> 
> Not true. In the SAML-assertion wrapping case the api could use an
> underlying SAML-api which extracts attribute values based on URNs.
> No mappings there.

I don't understand.
We were discussing what the application caller above GSS-API will
have to supply, and if the application caller cares at all about
a particular attribute, it will have to implement semantics to
interpret attribute values.

Your descriptions sounds like an implementation detail how the
GSS-API layer passes down the request for an attribute into
an underlying SAML-api.

What you seem to be calling for is the possibility to transfer native
labeling and attribute values between a knowing application and
a particular mechanism below GSS-API and not have to go through
an additional abstraction layer (which would require mapping).

Basically, you seen to be looking for a common API call rather
than a real abstraction (which could, in theory, provide some level
of portability/independence of the nature of the attribute).