Kitten Working Group Status Report and Important IETF 60 Deadlines

The request for the creation of the Kitten Working Group is still being 
discussed by
the Security Area Directors and the IESG.  While there is still plenty 
of time for the
working group to be approved prior to IETF 60, it is prudent that we 
assume that
approval will not be obtained prior to the end of the scheduling 
period.  As such I
will be submitting a request for a BOF slot which can be converted to a 
working group
slot once approval is obtained.

The IETF 60 Important Dates are as follows:
    July 12, Monday - Internet Draft Cut-off for initial document (-00) 
submission at 09:00 ET
    July 19, Monday - Working Group and BOF scheduling closes at 17:00 ET
    July 19, Monday - Internet Draft final submission cut-off at 09:00 ET
    July 21, Wednesday - Pre-Registration and Pre-payment cut-off at 
12:00 noon ET
    July 26, Monday - Registration cancellation cut-off at 17:00 ET
    July 26, Monday - Working Group agendas due date at 12:00 ET
    August 1-6, 2004 - 60th IETF Meeting in San Diego, CA, USA

If you have committed to submitting a new Internet Draft for Kitten, 
please ensure that
the draft has been submitted by next Monday.

To assist me in planning the BOF time slot please send me private mail 
indicating whether
or not you are planning to attend the IETF session and if there are any 

Fax Message Received

Request to create KITTEN (daughter of CAT) BOF at IETF 60

Draft available on GSSAPI naming issues

Please take a look at
http://www.ietf.org/internet-drafts/draft-hartman-gss-naming-00.txt.
This describes problems I see with GSSAPI's naming architecture and a
proposal to solve these problems.  I will be presenting at the BOF
meeting.

I'm particularly interested in things I've missed in the problem
description or other open issues that I failed to mention.

--Sam

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to majordomo <at> lists.stanford.edu

Re: Draft available on GSSAPI naming issues

Sam,

Sam Hartman wrote:
> 
> Please take a look at
> http://www.ietf.org/internet-drafts/draft-hartman-gss-naming-00.txt.
> This describes problems I see with GSSAPI's naming architecture and a
> proposal to solve these problems.  I will be presenting at the BOF
> meeting.
> 
> I'm particularly interested in things I've missed in the problem
> description or other open issues that I failed to mention.

There are zero problems with existing GSS-API naming.

I have three major problems in the above document:

 (1) it fails to distinguish authentication from authorization.

     In the past I have seen two proposals to extend GSS-API
     authentication with an API for authorization
     (presented in CAT wg sessions at IETF meetings),
     one was XGSS-API from the SESAME project and the other
     one was "GAA" (Cliff?)

 (2) it fails to recognize where existing infrastructures deliberatly
     abuses the underlying protocol (e.g. Microsoft entirely ignores
     the Kerberos name-based authentication and uses a proprietary
     extension to convey authentication and authorization information).

 (3) it fails to realize that *ALL* access control schemes require
     a canonical representation of either the identity or some
     standarized authorization information in order to work.

     On Microsoft platforms the "canonical" name appears to be a "SID",
     which is what gets stored in their (D)ACLs.  The printable representation
     of a SID is a "SAM account name" (LanManager style).

The provision of GSS-API to (pre-)populate ACLs using
gss_import_name()+gss_canonicalize_name()+gss_export_name() is
absolutely necessary.  Btw: It is extensible since gss_canonicalize_name()
already requires a (mechanism) OID input parameter as a hint what kind of
transformation is required.

I don't see a problem in defining mechanism- or environment-specific
OIDs which can be used to draw a canonical name from a particular
namespace -- or alternatively from some kind of authorization data.

But don't fall prey to illusions, any such approach is no longer
a general abstraction.  It will actually turn out to be extremely
implementation specific.  The acceptor would have to use
gss_canonicalize_name() on the src_name returned from
gss_accept_sec_context() upon successful authentication in order
to transform the name to the alternative namespace (currently no
gssapi-based server needs to do that).  Keep in mind that the
authentication may be successful, but a transformation of the
identity into a particular namespace or authorization space
may fail for all sorts of reasons.

Personally I think it would be perfectly OK to allow to extend
the use of gss_canonicalize_name() for arbitrary namespaces,
maybe even for authorization elements (since the app caller needs
to be explicitly aware of the OIDs anyway).  But I don't think
that this will have an impact on PORTABLE gssapi callers that
use gssapi for the purpose of **abstraction** in heterogeneous
environments.

Just take Microsoft's abuse of the Kerberos 5 protocol as an
example.  We do have several customers that use a Microsoft
W2K Active Directory for user management but run their servers
on Unix machines with a (mostly vanilla MIT Kerberos) that only
supports name based authentication.  The server side implementation
doesn't implement/understand Microsoft's proprietary extensions,
therefore the only namespace available for authentication is
that of the base Kerberos 5 protocol -- name-based authentication
of Kerberos principals.  And it is likely to remain like this
for some time, I assume.  HP-UX 11.11 seems to include an
implementation of MIT Kerberos v1.1 today.

-Martin
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to majordomo <at> lists.stanford.edu

Re: Draft available on GSSAPI naming issues

On Tue, Jul 13, 2004 at 03:57:48PM -0400, Sam Hartman wrote:
> 
> Please take a look at
> http://www.ietf.org/internet-drafts/draft-hartman-gss-naming-00.txt.
> This describes problems I see with GSSAPI's naming architecture and a
> proposal to solve these problems.  I will be presenting at the BOF
> meeting.
> 
> I'm particularly interested in things I've missed in the problem
> description or other open issues that I failed to mention.

Comments:

 - The Abstract starts with a claim that the GSS-API "uses name-based"
   authorization.  This is not so.  Authorization is outside the scope
   of the GSS-API v2u1, though the GSS-API does aim to make name-based
   authorization workable as a lowest common denominator.

   A nit?  Solaris' NFS server (and CITI's) can map GSS-API principal
   names to Unix credentials and authorize clients based on those
   credentials and ACLs that reference Unix UIDs/GIDs; and Windows does
   much the same thing -- so I don't think this is a nit.

   The abstract should point out that name-based authorization is the
   LCD for the GSS-API, that name-based authorization is highly
   problematic (see below), and that generic extensions that facilitate
   authorization based on principals' attributes *other* than their
   names are highly desirable.

 - I disagree with the fourth sentence of the Abstract.  It's always
   been the case that principal names are subject to change, and this
   has been true for all GSS-API mechanisms (including MS' NTLM and
   Sun's DH mechs), as well as for non-GSS security mechanisms.

   It is the fact that names are subject to change, combined with the
   utter lack of any generic mechanism for keeping name-based ACLs up to
   date with name changes that argues against name-based authorization.

   It's important to point out why names change too.  Marriage and
   divorce, as well as other legal name changes are typical reasons, but
   so are user dissatisfaction with their short-form usernames (initial
   misspellings are a typical reason for this), and then there's
   collisions (particularly in flat namespaces) resulting from relating
   to mergers and acquisitions, etc...

   If the GSS-API's mechanisms' canonical names were not based on human
   readable display versions of principal names, but on unique,
   unchanging identifiers intended for machine use then authorization
   based on canonical GSS principal names would not be so bad.  But this
   is not a feasible solution now.

   Another way of stating this is this: canonical names based on display
   forms of principal names, for any security mechanism, including
   non-GSS mechanisms, are of bounded utility, in time, for
   authorization purposes.  Emphasis should be placed on this not being
   a GSS-API-specific problem.

 - That last comment makes me think of possible different approaches to
   this problem, none of which, fortunately, are attractive to me, but
   which might keep existing users of name-based access controls happy,
   such as a method for converting MNs to GSS_C_NT_MACHINE_UID_NAME
   names.  Such an extension would not be fully satisfactory to me, but
   as long as there's an exported name for for GSS_C_NT_MACHINE_UID_NAME
   this might be helpful to anyone who, for whatever reason (e.g.,
   legacy), must cling to GSS-API name-based ACLs.

Cheers,

Nico
--

-- 
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to majordomo <at> lists.stanford.edu

Re: Draft available on GSSAPI naming issues

On Tue, Jul 13, 2004 at 11:14:33PM +0200, Martin Rex wrote:
> Sam,
> 
> Sam Hartman wrote:
> > 
> > Please take a look at
> > http://www.ietf.org/internet-drafts/draft-hartman-gss-naming-00.txt.
> > This describes problems I see with GSSAPI's naming architecture and a
> > proposal to solve these problems.  I will be presenting at the BOF
> > meeting.
> > 
> > I'm particularly interested in things I've missed in the problem
> > description or other open issues that I failed to mention.
> 
> There are zero problems with existing GSS-API naming.

I agree with your comment -- there's nothing wrong with the GSS-API's
naming.

Name-based authorization is really problematic though, and in a way that
transcends the GSS-API.

Please read the comments I just posted.  I think some extensions to the
GSS-API can be made that will greatly improve authorization in
applications by moving beyond the use of canonical names based on
display forms that are subject to change at any time.

> I have three major problems in the above document:
> 
>  (1) it fails to distinguish authentication from authorization.

It doesn't have to.  The GSS-API handles authentication.

>  (2) it fails to recognize where existing infrastructures deliberatly
>      abuses the underlying protocol (e.g. Microsoft entirely ignores
>      the Kerberos name-based authentication and uses a proprietary
>      extension to convey authentication and authorization information).

It doesn't have to.  The basic problem with name-based authorization
transcends the GSS-API and its mechanisms (see above and my other post
just now).

>  (3) it fails to realize that *ALL* access control schemes require
>      a canonical representation of either the identity or some
>      standarized authorization information in order to work.
>
>      On Microsoft platforms the "canonical" name appears to be a "SID",
>      which is what gets stored in their (D)ACLs.  The printable representation
>      of a SID is a "SAM account name" (LanManager style).

But a user may have multiple SIDs (a primary user SID, a primary group
SID and additional user and group SIDs).  The primary user SID can be
considered a canonical name, yes, and maps onto the
GSS_C_NT_MACHINE_UID_NAME name type, but the GSS-API provides no way to
get the GSS_C_NT_MACHINE_UID_NAME that corresponds to a
GSS_C_NT_USER_NAME (or vice-versa -- but the reverse might not be a
one-to-one mapping!).

We MUST at the very least have a way to convert names of one type to
another, where that is feasible.

I'm sure you'll agree that authorization by UID or SID is much better
than by name -- the former change much less frequently than the latter
and non-reuse of the former is a typical policy in many organizations.

> The provision of GSS-API to (pre-)populate ACLs using
> gss_import_name()+gss_canonicalize_name()+gss_export_name() is
> absolutely necessary.  Btw: It is extensible since gss_canonicalize_name()
> already requires a (mechanism) OID input parameter as a hint what kind of
> transformation is required.

But GSS_Canonicalize_name() has no nametype OID parameter.  If it had
both, a mech OID and a nametype OID, or if GSS_Display_name() had an
optional display-as-other-nametype OID parameter then name-based
authorization, using GSS_C_NT_MACHINE_UID_NAME names, would be a lot
less problematic.

I'll stop here.  I consider this nametype conversion idea an olive
branch.  I do prefer the name attribute interface that Sam's draft
describes however, as that would allow for access to principals' group
membership information, and so one, in a fairly generic manner.

Nico
--

-- 
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to majordomo <at> lists.stanford.edu

Re: Draft available on GSSAPI naming issues

>>>>> "Martin" == Martin Rex <martin.rex <at> sap.com> writes:

    Martin>  (1) it fails to distinguish authentication from
    Martin> authorization.

Really?  Pointers on where I got this wrong would be appreciated; I
agree with you that this distinction is critical and I'd certainly
like to correct any errors I made in this regard.

I don't think the draft talks much about authorization; it talks a lot
about making certain authentication assertions (or parts of names)
available for authorization decisions.

    Martin>      In the past I have seen two proposals to extend
    Martin> GSS-API authentication with an API for authorization
    Martin> (presented in CAT wg sessions at IETF meetings), one was
    Martin> XGSS-API from the SESAME project and the other one was
l    Martin> "GAA" (Cliff?)

I certainly remember GAA.  I was not really around for XGSS.

    Martin>  (2) it fails to recognize where existing infrastructures
    Martin> deliberatly abuses the underlying protocol (e.g. Microsoft
    Martin> entirely ignores the Kerberos name-based authentication
    Martin> and uses a proprietary extension to convey authentication
    Martin> and authorization information).

I actually believe I do discuss Microsoft's PAC.  You're right that I
assume the reader is roughly familiar with the contents of the PAC
already; I can certainly add a bit more background to this section of
the draft.

    Martin>  (3) it fails to realize that *ALL* access control schemes
    Martin> require a canonical representation of either the identity
    Martin> or some standarized authorization information in order to
    Martin> work.

OK, then the draft is unclear.  The entire point of the draft is that
you need such representations.  The problem seems to be that there
will be multiple representations available and different applications
will require different representations.

I actually like your proposal of expanding gss_canonicalize_name to
deal with environment-specific OIDs.  I don't think it fully solves
the problem though, because it doesn't deal with composite identities
like subjectAltName extensions or like group memberships.  Let's say
we define an oid that when passed into gss_canonicalize_name gives us
a representation of all the sids associated with some name in the
Microsoft authorization model.  I don't really want to put that
representation on an ACL because the account might gain or lose group
memberships and thus gain or lose sids. Instead I somehow want to put
a representation of a single sid corresponding to some group on the
ACL.  Later, when I try and authorize some previously-authenticated
context, I want to find out if the identity corresponding to that
context has that single group sid as part of its name.

With your proposal, an application wanting to do this sort of
authorization would need to understand the representation of the
sid-based name and decompose that representation.

With name attributes it seems like you could define a multi-valued
attribute for group membership and see if the name in the context
contained the value for this attribute corresponding to SId placed on the ACL.

--Sam
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to majordomo <at> lists.stanford.edu

Kitten BOF has been approved

FTP AUTH GSSAPI - Is Kitten the appropriate forum?