Subject: Preliminary minutes

From: Ken Hornstein <[email-masked]>
Date: Tue, 15 Jul 2003 12:43:21 -0400

Attached you will find the preliminary minutes from the krb-wg WG.  If
you notice anything incorrect in them, please let me know.  Thanks to
Luke Howard for taking the minutes!

--Ken

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
  --------------------------------------------------------------

Backgroudn:

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 Johnathon 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 Packet Cable folk (did anyone catch the name?):

Packet Cable Labs (PCL) 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".

PCL: 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 PCL 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.

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

Sam: PCL 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. 

PCL suggested they would be willing to host an interim meeting.
Some discussion regarding interim meeting ensued.

Question from PCL: 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'".

PCL 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.

---

From: Tim Alsop <[email-masked]>
Date: Wed, 16 Jul 2003 08:03:08 +0100

Ken,

Ref: PacketCable discussion and PKINIT 

The PacketCable security specification does not use Distinguished Name mapping to determine the principal name. Section 6.4.7 in the PacketCable specification defines the method used. The security spec can be downloaded from http://www.packetcable.com/specifications/

Also, the company is called CableLabs and the standards involving Kerberos are used within the security part of the PacketCable standards. In your minutes you referred to 'Packet Cable Labs' instead.

PS. I think you made a typing mistake with the word 'Background' ?

Thanks, Tim.

-----Original Message-----
From: Ken Hornstein [mailto:[email-masked]] 
Sent: 15 July 2003 17:43
To: [email-masked]
Subject: Preliminary minutes

Attached you will find the preliminary minutes from the krb-wg WG.  If you notice anything incorrect in them, please let me know.  Thanks to Luke Howard for taking the minutes!

--Ken

Kerberos WG  (krb-wg)
Tuesday,  July 15, 2003

AGENDA:

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

Backgroudn:

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 Johnathon 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.

Packet Cable Labs (PCL) 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".

PCL: 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 PCL 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.

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

Sam: PCL 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).

Question from PCL: 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'".

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".

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.

  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.

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

  Open discussion

Nothing.

---

From: "Eric Rosenfeld" <[email-masked]>
Date: Wed, 16 Jul 2003 10:14:50 -0600

Ken,
 
Jean-Francois Mule, Director of PacketCable Architecture, attended the
meeting.  PacketCable is a project run by Cable Television Laboratories
(CableLabs), a non-profit R&D consortium of the Cable Industry.
PacketCable is a Voice-over-IP architecture for the Cable industry.
Security is a large component of the PacketCable VoIP architecture, and
Kerberos/PKINIT/PKCROSS is a very important piece of PacketCable
Security.
 
Regards,
Eric
Eric S. Rosenfeld 
Project Director, PacketCable Security 
CableLabs 
400 Centennial Parkway 
Louisville, CO  80027-1266 

Email: [email-masked] 
Phone: 303-661-3841 
Fax: 303-661-9199 

	-----Original Message-----
	From: Tim Alsop [mailto:[email-masked]] 
	Sent: Wednesday, July 16, 2003 1:03 AM
	To: Ken Hornstein
	Cc: [email-masked]
	Subject: RE: Preliminary minutes

	Ken, 

	The PacketCable security specification does not use
Distinguished Name mapping to determine the principal name. Section
6.4.7 in the PacketCable specification defines the method used. The
security spec can be downloaded from
http://www.packetcable.com/specifications/

	Also, the company is called CableLabs and the standards
involving Kerberos are used within the security part of the PacketCable
standards. In your minutes you referred to 'Packet Cable Labs' instead.

	PS. I think you made a typing mistake with the word 'Background'
? 

	Thanks, Tim. 

	-----Original Message----- 
	From: Ken Hornstein [mailto:[email-masked]] 
	Sent: 15 July 2003 17:43 
	To: [email-masked] 
	Subject: Preliminary minutes 

	Attached you will find the preliminary minutes from the krb-wg
WG.  If you notice anything incorrect in them, please let me know.
Thanks to Luke Howard for taking the minutes!

	--Ken 

	Kerberos WG  (krb-wg) 
	Tuesday,  July 15, 2003 

	AGENDA: 

	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 

	Backgroudn: 

	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 Johnathon Trostle for inclusion.

	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.

	Packet Cable Labs (PCL) 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".

	PCL: 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 PCL 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.

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

	Sam: PCL 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).

	Question from PCL: 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'".

	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". 

	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. 

	  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 

	  Open discussion 

	Nothing.