Subject: Final minutes for krb-wg

From: Ken Hornstein <[email-masked]>
Date: Thu, 17 Jul 2003 08:50:53 -0400

Attached you will find the final minutes of the Kerberos Working Group.
I appreciate everyone who sent in comments and corrections.

Kerberos WG  (krb-wg) 

Tuesday,  July 15, 2003
1700-1800 Afternoon Sessions IV
======================================================

Acting CHAIR: Ken Hornstein  (Doug Engert can not attend) 
Scribe: Luke Howard

AGENDA:

  Introduction, agenda bashing
  --------------------------------------------------------------

Ken introduced himself. No comments on the agenda.

  Living life in a Post-Clarifications World
  --------------------------------------------------------------

Noted that documents have gone to last call; believe that all
comments were syntax or wording issues that can be fixed by
the author re-edits. No further comments.

  Extra TGT draft
  --------------------------------------------------------------

Background:

The extra TGT draft is designed to use the host key to give you
stronger preauthentication to avoid exposure to weak passwords
that Kerberos has always has. The major problem has always been
how it combined keys and used Kerberos cryptography. The
crypto framework now has the necessary primitives for doing
this in a clean way, although without a combine keys function.
Sam noted that he has done the work on a combine keys function
that is sufficiently obvious and has sought review, and will
supply the necessary text to Jonathan Trostle for inclusion.
Suggest that it could last call by Minneapolis.

There was another proposal from Jacques re: anonymous DH for
pre-authentication, no response from Jacques regarding its
status.

  PKINIT, PKCROSS
  --------------------------------------------------------------

Packet Cable have expressed (privately) interest in this. Noted
that PKCROSS was deferred due to its dependence on ticket
extensions. Both drafts have expired to Ken's knowledge.

At the last IETF there was a large discussion about mapping
realms (in?) certificates to Kerberos names; questions about
clarity. The technical issues that remain are "fairly simple"
(Sam's words), but someone needs to discuss with Tom Yu the
encoding of distinguished names in Kerberos principals. This
needs to be investigated. Similarly the X.509 to Kerberos name
mapping has some outstanding issues (not subjectAltName).

The assumption that any published standard will be compatible
with deployed implementations (eg. Windows 2000) may
unfortunately be incorrect.

Some discussion on whether we need new editors for the document;
depends on the degree of interest from the working group.

Comments from Jean-Francois Mule, Director of PacketCable Architecture:

Cable Television Laboratories (CableLabs) is an organisation that
manages specifications along with vendors. It does not create specs on
its own. They are definitely interested in both PKINIT and PKCROSS.
Understanding is that they are not that far from the current drafts and
are willing to commit resources to moving these things forward. Moved
to discuss this after meeting.

Sam: it might be possible for PC to do an informational RFC
describing what they have done (notwithstanding the need for
a standards track RFC); noted, again, that PKCROSS is blocked
on Kerberos extensions. Working group is likely to object to
any standards track document that describes doing things that
are a violation of the Kerberos specification as it stands 
and would lead to interoperability problems. 

Ken: background regarding extending ASN.1 types in an
interoperable manner. Extensions are the next major work 
item but no timeline, "active participants want it to see
it progress rapidly".

Jean-Francois: concern is that they do not wish to promulgate non-
standard implementations but timelines may force otherwise.
ITU-T study group 9 has a specification that has been
consented but cannot progress to the next step until it
can normatively reference an information track (?) RFC.

Jeffrey: noted that PacketCable require an extension that would break
backwards compatability, and that this is a difficult situation with
respect to timelines; conversely, doesn't see that there is a lot that
can be done to make this happen faster.

Jean-Francois: not asking for faster as much as a timeline, so that
vendors and service providers can be provided with an answer.

Sam: PacketCable has the opportunity to deploy an implementation that
long-term is interoperable with existing (non-standard) and future
(extensions) clients. Issues are: encoding of extensions and writing
texts, so it is reasonable to expect that within a year they may be
sent to the IESG (assuming the current degree of focus within the
working group is maintained).

Proposed timeline: end of July 2004 for IESG. 

It was noted that only PKCROSS was being held up by the extensions
document; all PKINIT needed was an editor willing to do the work.
Jean-Francois said that CableLabs was willing to provide resources
to make PKINIT happen.

Jean-Francois suggested they would be willing to host an interim
meeting.  Some discussion regarding interim meeting ensued.

Question from Jean-Francois: what's the likelihood of the IESG
accepting an information draft describing their existing use. Steve
noted that the IESG will not accept an individual submission that looks
like an "end-run" around the working group; the working group has veto
power over individual drafts in its space, and the working group would
be likely to approve this given the acknowledged issues re: extensions.
Steve noted that it would "take a good description, possibily in the
document or in a submission from me to say why this is being done this
way... eg. 'we will issue a standards track document when it is
possible'".

Jean-Francois noted two separate issues:

	- documenting what they are doing
	- request for I-D to reference in ITU-T; hence
	  informational RFC would be useful

Much discussion on whether an information RFC would actually
be useful or not.

Question on whether it would be possible to advance PKCROSS
without extensions. Working group has decided against this
because of the present lack of extensibility mechanisms in
the Kerberos protocol.

Some discussion on whether an issue tracking system would
be useful.

  Password change protocol
  --------------------------------------------------------------

Much discussion recently on this document; sounds like that
it is "progressing quite nicely".

  Kerberos/GSSAPI authentication in SAML
  --------------------------------------------------------------

Tim Alsop of Cybersafe UK. 

Wanted to gauge interest in SAML working with Kerberos. SAML
is a standard that is part of the many web services standards,
and there is some discussion on how it may be used with
Kerberos.

Luke: does this interact with WS-Security? Agreed that WS-Security
is hopelessly underspecified particularly with respect to
Kerberos.

Bob Morgan: noted his involvement with SAML, OASIS. WS-Security
is "almost done" (did I understand that correctly?) and specifies
interaction with X.509 and Kerberos. Some people have been
discussing how SAML assertions might be used in a SASL context.

Tim noted that there are multiple ways in which SAML could be
used. Some question on whether OASIS or this working group was
the appropriate forum. IETF might be, but not this working
group.

Bob noted some movement regarding SASL referencing SAML, out
of scope for krb-wg. Head nodding from Jeff Hodges.

Wyllys Ingersoll: question about cat-wg. Defer to list.

  draft-ietf-krb-wg-hw-auth-02.txt
  --------------------------------------------------------------

Matt Crawford cannot be here; skipped due to time constraints.

  Kerberos KDC LDAP schema
  --------------------------------------------------------------

Focus has changed to using LDAP as an admin protocol rather than
storing Kerberos keys in LDAP. Leif Johannson noted that the
current issue is describing the information model; the schema
will come later. There will be a meeting after this meeting.

  Extensions
  --------------------------------------------------------------

Many things (like ticket extensions) were deferred until 
extensions.

The next thing to do is: "charge ahead". No-one disagreed.

  Do we need an interim meeting?
  --------------------------------------------------------------

Resounding consensus is that we do need an interim meeting;
when/where should be deferred to the mailing list.

  Open discussion
  --------------------------------------------------------------

Nothing.

--Ken