Subject: Last Call for Comments on IETF 61 Kitten Minutes

From: Jeffrey Altman <[email-masked]>
Date: Fri, 03 Dec 2004 11:47:05 -0500

Attached is the latest draft of the minutes for the
IETF 61 Kitten Meeting.  I would like to thank Ken Hornstein
for acting as Jabber Scribe.

Please review.  If there are no additional comments,
I will submit these minutes as they are.

Thanks.

Jeffrey Altman

 IETF 61: Kitten Working Group Summary
Monday, November 8, 2004
Jeffrey Altman <[email-masked]> [chair]

Presentations: 
  http://web.mit.edu/jaltman/Public/Kitten/ietf61/ietf61-kitten.pdf

The chair announced the creation of the working group by the IESG; reviewed 
the charter and the group's initial milestones. (please see the presentation 
slides for details).

Since the BOF at IETF 60 there has been significant progress
on:
 + describing the GSS Naming problem
 + solving the interoperability problems between protected SPNEGO 
   and implementations which have been widely deployed
 + defining the requirements and interfaces for PRFs
 + C# bindings
 + producing a roadmap document

Nico Williams gave a presentation on Pseudo-random function API: Many 
applications would like to obtain an encryption key from the GSSAPI context.  
Breaking the abstraction layer to obtain the negotiated key is dangerous.  To 
solve the problem we are proposing the use of a new PRF seeded with internal 
keying material. Calls to GSS_Pseudo_Random() will be deterministic.  When 
initialized with the same context and input it will produce the same output.

Nico Williams gave a presentation on a Kerberos v5 GSS Mech PRF: We will 
construct the Krb5 PRF based on the Kerberos v5 crypto framework PRF.  For new 
mechanisms we will always use the acceptor's subkey.  For 1964 mechs the 
initiator subkey can be used. Key usage to be determined.

Nico Williams gave a presentation on Domain based Service Names for
GSS and the Krb5 Mechanism:

Domain based Service names are meant mitigate against attacks caused by the 
use of insecure DNS SRV to obtain the host/service pair for a given domain.
The generic name syntax is: 

  <service>@<domain>@<host>

an OID for GSS_C_NT_DOMAINBASED_SERVICE needs to be allocated. Since the I-Ds 
were published the Krb5 name form was changed to 

  <service>/<hostname>/<domain>@<REALM>

An open question is "how do we determine the realm of the domain?" We do not 
want the realm to be that of the host.
 + Must fold edits in for:
   – Domain name not optional in 'query' name form
   – Switch order of krb5 princ name components
   - Add Security considerations
Both I-Ds will soon be ready for WG Last Call

Chair presented Corby Morris' presentation on C# Bindings:

# bindings will be very similar to the Java bindings except for some minor 
differences in the method declarations due to language requirements.  
draft-morris-java-gssapi-update-for-csharp

Note: Java Security team will soon submit an update to RFC 2853 which will 
correct differences between the rfc and the implemented org.ietf.jgss package.

Larry Zhu gave a presentation on SPNEGO:

The goals for this work is to update 2478 to restore the 'P' in SPNEGO while 
maintaining backwards compatibility with the existing Windows SPNEGO 
implementation.  Initial draft published: draft-zhu-spnego-2478bis-00 The 
basis of the backwards compatibility is provided by a set of rules called: 
Safe-To-Omit-MIC rules.  

Significant issues: 
 + Safe-to-omit MIC rules: what are they? and when can they be used?
 + should we protect reqFlags?
 + SHOULD or MAY use optimistic token? 
 + How is the MIC token computed?
 + Do we need out -of-band negotiation with down-level clients and servers?

There was heavy discussion on the need for negotiation and the case for 
maintaining compatibility with existing implementations even though they do 
not implement the existing RFC.  Conclusions were that negotiation is 
important and there is a need to provide protected negotiation while 
maintaining interoperability if it can be done securely. The discussion on the 
use of the optimistic token did not produce an opinion on the use of SHOULD vs 
MAY.  There were strong feelings against supporting the use of mechanisms 
which do not provide integrity protection.  No conclusion was reached on how 
the MIC token is to be computed.  Is it over the OCTET-STREAM, with or without 
the OID.

Sam Hartman gave a presentation on GSS Naming:

The immediate goal of this document has been to describe problems that we're 
trying to solve to prevent scope creep. We want to support authentication of 
internal identities (uuids) and allow applications to work with parts of 
composite names.  Applications should be able to query available credentials 
and presented names based on components and thereby find the most appropriate 
credential for a target. (Martin Rex points out that you can't do 
authentication of internal identities portably today) We think it can be 
portable, and Nico and I think at least we can do a lot better than we can do 
today.  There are several levels of GSSAPI v2 compatibility we need to look 
at.
 + New mechanisms used by old applications (should they be visible?  
   Or only do GSSAPI v2 features?)
 + File formats for ACLs containing names
Possible Solutions include name attributes, GSSAPI credential extensions, 
client given ability to assert a name, a facility for enumerating the 
credentials that we have, choose different credential depending on the party 
that they're talking to.

name attributes: names are composed of attributes. attributes are OID label 
plus ??????
 
client aserted names: allow clients to assert part of a name to be exported. 
tell implementation what part of the name that it gets. this would provide 
better compatibility with older applications

credential extensions: add labelled extensions to credentials similar in 
functionality to name attirubutes, but requires more changes to contexts.

credential enumeration: Basically a "GSSAPI klist" facility to find 
credentials that are available.

Consensus was reached that we will have a document describing the solution 
space.

Chair lead discussion on whether or not implementation of Kerberos 5 
mechanism support for PRF and Domain Names should take place in kitten
or krb-wg.

Close of Meeting.

DECISIONS (to be validated on the list):

 + Maintaining interoperability with existing deployed SPNEGO implementations
   is more important then the ability to add new features such as protect 
   reqFlags

 + No consensus was reached on whether the use of an optimistic token in SPNEGO
   will be SHOULD or MAY.

 + There are strong feelings against the relaxing the MUST NOT applied to the
   negotiation of mechanisms which do not support integrity protection

 + The GSS Naming document will describe the problem space and not just 
   solutions

 + The Kerberos 5 mechanism documents will working group documents of Kitten.
   We will work closely with the Kerberos WG to ensure proper review and we
   we last call in both.  This decision was made by flipping a coin.

ACTION ITEMS:

 + Larry Zhu will follow up on the outstanding issues with SPNEGO and report
   to the list by Fri Nov 19

 + The chair will send a list of working group documents to the secretariat

 + Nico Williams will publish new I-Ds for PRF and Domain Names including 
   results of recent on-list discussions

 + The Chair will contact Sun Java Security team to obtain a draft describing
   the incompatibilities between RFC and org.ietf.jgss

 + Sam Hartman will revise GSS Naming document and then hand it off to a new
   editor

MILESTONES:

Nov 04	  	First Meeting
Dec 04          Prepare SPNEGO for Last Call
Mar 05	  	Submit SPNEGO to the IESG as Proposed Standard
Mar 05	  	First drafts of either 'Clarifications to GSSAPIv2' as 
                Informational OR submit 'Generic Security Service Application 
                Program Interface Version 2, Update 2' and 'Generic Security 
                Service API Version 2, Update 2 : C-bindings' to the IESG as 
                Proposed Standard   
Jul 05	  	Submit either 'Clarifications to GSSAPIv2' as Informational OR 
                submit 'Generic Security Service Application Program Interface 
                Version 2, Update 2' and 'Generic Security Service API Version 
                2, Update 2 : C-bindings' to the IESG as Proposed Standard   
Jul 05	  	Submit 'The Channel Conjunction Mechanism (CCM) for the 
                GSSAPI' to the IESG as Proposed Standard 
Jul 05	  	Submit 'The Simple and Protected GSS-API Negotiation Mechanism 
                (Revised)' to the IESG as Proposed Standard 
Nov 05	  	Submit 'GSSAPI Mechanisms without a Unique Canonical Name' to 
                the IESG as Proposed Standard 
Jul 06	  	Submit 'Generic Security Service Application Program Interface 
                Version 3' to the IESG as Proposed Standard  
Jul 06	  	Submit 'Generic Security Service API Version 3 : C-bindings' 
                to the IESG as Proposed Standard 
Jul 06	  	Submit 'Generic Security Service API Version 3 : Java and C# 
                bindings' to the IESG as Proposed Standard 
Nov 06	  	Charter Review

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