Subject: Proposed Charter (Draft #2)

From: Jeffrey Altman <[email-masked]>
Date: Thu, 09 Sep 2004 14:38:49 -0400

Incorporating PRF and most of Ken Raeburn's comments.

Proposed Charter

The Generic Security Services API [RFC 2743, RFC 2744] provides an API 
for applications to set up security contexts and to use these contexts 
for per-message protection services.  The Common Authentication Technology
Next Generation Working Group (Kitten) will work on standardizing 
extensions and improvements to the core GSSAPI specification and language
bindings that the IETF believes are necessary based on experience using 
GSSAPI over the last 10 years.  Extensions may be published as separate 
drafts or included in a GSSAPI version 3.  While version 2 of the GSSAPI 
may be clarified, no backward incompatible changes will be made to this 
version of the API.

This working group is chartered to revise the GSSAPI v2 RFCs for the 
purpose of clarifying areas of ambiguity:
 o Use of channel bindings 
 o Thread safety restrictions 
 o C language utilization clarifications and recommendations 
   (e.g., type utilization, name spaces) 
 o Guidelines for GSS-API mechanism designers 
 o Guidelines for GSS-API application protocol designers 

This working group is chartered to specify a non-backward compatible 
GSSAPI v3 including support for the following extensions:
 o Clarify the portable use of channel bindings and better specify 
   channel bindings in a language-independent manner. 
 o Specify thread safety extensions to allow multi-threaded applications 
   to use GSSAPI 
 o Definitions of channel bindings for TLS, IPSec, SSH and other 
   cryptographic  channels based on work started in the NFSV4 working  
   group. 
 o Define a GSSAPI extension to allow applications to store credentials.
   Discussions to be started based upon: 
     o draft-williams-gss-store-deleg-creds-xx.txt 
 o Extensions to solve problems posed by the Global Grid Forum's GSSAPI 
   extensions document. 
 o Extensions to deal with mechanism-specific extensibility in a 
   multi-mechanism environment. 
 o Extend GSSAPI to support mechanisms that do not have a single 
   canonical name for each authentication identity. 
 o Extensions to support stackable GSSAPI mechanisms. 
 o Define a Psuedo-Random Function for GSSAPI 

This working group is chartered to perform the following GSSAPI mechanism
specification work:

 o Specify a GSSAPI v2/v3 Channel Conjunction Mechanism 
 o Revise RFC 2748 (SPNEGO) to correct problems that make the 
   specification unimplementable and to document the problems 
   found in widely-deployed attempts to implement this spec. 

This working group is chartered to perform the following new GSSAPI Language
Binding specification work:

 o Specify a language binding for C# 

End of Proposed Charter

The participants of the IETF-CAT mailing list realize the quantity of 
work which we desire to undertake is quite ambitious in scope. This is 
simply an indication of how much work has accumulated over the last few 
years since the CAT working group disbanded.  We believe that we can 
accomplish the stated work items in 18 months.

Milestones
Either:
 o Clarifications to GSSAPIv2 (six months to IESG) 
   Informational
   [editor: TBD] 
Or:
 o Generic Security Service Application Program Interface Version 2, Update 2 
   (six months to IESG)
   Proposed Standard
   [editor: TBD] 
 o Generic Security Service API Version 2, Update 1 : C-bindings (six months to IESG)
   Proposed Standard
   [editor: TBD]
End:
 o The Channel Conjunction Mechanism (CCM) for the GSSAPI (six months 
   to IESG) 
   Proposed Standard
   [editors: Nicolas Williams/Mike Eisler] 
 o On the Use of Channel Bindings to Secure Channels (six months to IESG) 
   Proposed Standard
   [editor: Nicolas Williams]
   draft-ietf-nfsv4-channel-bindings-01.txt
 o GSSAPIv3 (18 months to IESG)
   Proposed Standard
   [editor: to be determined]
 o Stackable Generic Security Service Pseudo-mechanisms
   Proposed Standard or to be folded into GSSAPIv3 
   [editor: Nicolas Williams]
   draft-williams-gssapi-stackable-pseudo-mechs-00.txt
 o GSS-APIv2 Extension for Storing Delegated Credentials
   Proposed Standard or to be folded into GSSAPIv3
   [editor: Nicolas Williams]
   draft-williams-gssapi-store-deleg-creds-00.txt
 o GSSAPI Mechanisms without a Unique Canonical Name (12 months to IESG)
   to be folded into GSSAPIv3
   [editor: Sam Hartman]
   draft-hartman-gss-naming-00.txt 
 o SPNEGO (RFC 2478) Revisions (18 months to IESG)
   Proposed Standard
   [editor: TBD] 
 o Pseudo-Random Function for GSSAPI
   to be folded into GSSAPIv3
   [editor: Nicolas Williams]
 o C# Bindings for GSSAPI 
   Proposed Standard
   [editor: Larry Zhu]

End of Milestones

MAILING LIST:
The mailing list for discussions is 

  [email-masked]

Use the following web page to join:

  https://www1.ietf.org/mailman/listinfo/kitten 

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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 9 Sep 2004 14:10:57 -0500

Are we taking the CCM document from the NFSv4 WG?  Also, I'm not the
editor of that one -- Mike Eisler is (I'm not sure if he's on this list
either).

My understanding was that we'd last call CCM in both WGs.

Also, I take it the C# bindings are now part of KITTEN's charter?  (I
don't mind, mind you.)  If so, Sun has some corrections to make to the
Java bindings RFC (the error codes used by Sun's implementation don't
agree with the ones in the RFC; it's easier to change the RFC than to
fix the implementations and recompile the apps).

Nico

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 09 Sep 2004 15:25:09 -0400

> editor of that one -- Mike Eisler is (I'm not sure if he's on this list

I believe the decision should be made by the IESG.

> fix the implementations and recompile the apps).

I do not object to updating the Java Bindings as part of the Charter.

Other comments?

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 9 Sep 2004 14:22:52 -0500

> I believe the decision should be made by the IESG.

Sure.

> I do not object to updating the Java Bindings as part of the Charter.

Still reviewing.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 9 Sep 2004 15:22:13 -0500

>    canonical name for each authentication identity. 

I'm not sure I like the way that this is phrased.  We're trying to make
it possible to do better than name-based authorization in portable
GSS-API applications, which also happens to be something we'd want to do
if we were to have mechanisms that lack a unique canonical name for each
principal.  I don't want a narrowly crafted item description here to
constrain us unnecessarily.

I propose:

 o Extend the GSS-API to support authorization by portable GSS
   applications while also supporting mechanisms that do not have a
   single canonical name for each authentication identity.

Also, we should add an item for a domain-based name type.  We've
discussed this before elsewhere (in the SASL WG); I believe Sam is in
favor and I'm pretty sure we can reach consensus on this item easily.

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 10 Sep 2004 15:10:03 -0400

>    single canonical name for each authentication identity.

This language is acceptable to me.  Anyone else in favor of the change?

> favor and I'm pretty sure we can reach consensus on this item easily.

Can you summarize the discussion for this group?

Thanks.

Jeffrey Altman

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 10 Sep 2004 15:52:05 -0400

> This language is acceptable to me.  Anyone else in favor of the change?

Works for me

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 10 Sep 2004 15:01:03 -0500

> Can you summarize the discussion for this group?

When using LDAP w/ SASL w/ GSS* one is supposed to use ldap@<host> as
the name of the server's principal (and hostbased service name type).

This is not sufficient to authorize the server as a valid server for the
directory that one is interested in.

Consider a site that has three LDAP directories.  Each directory will
have one or more servers, all with ldap@<host> hostbased princ names.

So how can a client authorize any one server to be a valid server for
the directory that the client is interested in?  How can one avoid
redirection attacks?

Deploying DNSSEC is one answer.

Another is to put the name of the directory (a "domain name" if you
wish) into the servers' principal names.

We propose a new name type for this.  We call this domain-based service
principal names.

Instances of domain-based service principal names containt three parts:
a service name, a host name and a "domain" name.

IIRC we had consensus in the SASL WG to proceed with domain-based names
as SASL WG items (Sam?), but now that KITTEN WG has arrived I think
KITTEN would be more appropriate.

Cheers,

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 10 Sep 2004 16:12:03 -0400

Thanks for the summary.

A few questions to help me justify the additional work item:

* Assuming we define the new GSS Service Name type within Kitten, what
   work must be done by SASL to allow them to be used?

* What must be done by application protocols such as LDAP to allow them
   to be used?

* What other application protocols are likely to use it?

Thanks.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 10 Sep 2004 17:30:24 -0400

>>>>> "Jeffrey" == Jeffrey Altman <[email-masked]> writes:

    Jeffrey> Thanks for the summary.  A few questions to help me
    Jeffrey> justify the additional work item:

    Jeffrey> * Assuming we define the new GSS Service Name type within
    Jeffrey> Kitten, what work must be done by SASL to allow them to
    Jeffrey> be used?

We'd need to define rules for using it in our gssapi mechanism draft.
I believe that's doable and I believe there is close to a consensus to
do the work within the SASL group.  I actually believe there is close
to a consensus to do the entire thing including definition of the GSS
name type within SASL if you decline it.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 10 Sep 2004 16:35:23 -0500

>   work must be done by SASL to allow them to be used?

Not much.  Fortunately for SASL the Kerberos V mechanism makes it
possible to detect support for a give peer name by trying
GSS_Init_sec_context() without actually having to exchange any context
tokens :)

Clearly this is not likely to be true for other mechanisms.  So users of
the GSS-API have to know a priori what names (and name types) to use.
See below.

> * What must be done by application protocols such as LDAP to allow them

This may be more complicated.  But at least we stop the rot.

I figure that typically which type of name to use for acceptors in such
apps will have to be a configurable option.

> * What other application protocols are likely to use it?

Things like kadmin, SMTP/SUBMIT, etc... come to mind.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Fri, 10 Sep 2004 17:53:34 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    >> * What must be done by application protocols such as LDAP to
    >> allow them to be used?

    Nicolas> This may be more complicated.  But at least we stop the
    Nicolas> rot.

    Nicolas> I figure that typically which type of name to use for
    Nicolas> acceptors in such apps will have to be a configurable
    Nicolas> option.

    >> * What other application protocols are likely to use it?

    Nicolas> Things like kadmin, SMTP/SUBMIT, etc... come to mind.

Basically anything that indirects name lookups through SRV should
probably use this.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 10 Sep 2004 16:50:47 -0500

> Basically anything that indirects name lookups through SRV should

Excellent point.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 14 Sep 2004 18:50:39 +0200 (MET DST)

> the directory that the client is interested in?  How can one avoid

The correct approach would be to use a directory and secure directory
lookup to translate abstract service names into specific
instances of a service (network address plus Kerberos principal name).

As much as I dislike DCE, but they got this part right!

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Sep 2004 12:10:34 -0500

> instances of a service (network address plus Kerberos principal name).

That is a perfectly valid approach, though it has a bootstrapping issue.

One approach is [much] simpler than the other though, requires less
effort to specify, is nameservice/directory independent and so, taking
all of this into account, much more likely to be interoperable.

By the KISS principle, then, I think that the domain-based naming
approach is worth following.

Authorizing service principals to serve a given resource can be hard
when that very resource is what you'd use to authorize the service
principals in question.

Yes, DNSSEC prevents DNS spoof attacks, which saves all apps that use
SRV records to locate their servers from having to authorize the
servers' service principals.  But if we can avoid having to rely on
secure nameservices, and we can do so with little effort, I think we
should.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Fri, 10 Sep 2004 16:13:13 -0400

Jeffrey> Nicolas Williams wrote:
    >> applications while also supporting mechanisms that do not have
    >> a single canonical name for each authentication identity.

    Jeffrey> This language is acceptable to me.  Anyone else in favor
    Jeffrey> of the change?

I like it.