DRAFT Minutes for krb-wg at IETF62

** IETF 62 - Minneapolis, MN
** Kerberos Working Group
** Thu, March 10 - 09:00-11:30

Chair: Jeffrey Hutzelman
Scribe: Jeffrey Altman
Jabber: Jeffrey Schiller, Sam Hartman, Brian Tung

* Agenda:
  + Preliminaries - Jeffrey Hutzelman (5 min)
  + Document Status - Jeffrey Hutzelman (10 min)
  + Extensions - Tom Yu (15-60 min)
  + Referrals - Larry Zhu (10 min)
  + Enctype Negotiation - Larry Zhu (10 min)
  + Set/Change Password - Nico Williams (10 min)
  + Update Milestones - Chair and Participants (10 min)

* Preliminaries - Jeffrey Hutzelman (5 min)

reviewed agenda.

* Document Status - Jeffrey Hutzelman (10 min)

clarifications is still in the rfc editor queue
just passed iana review stage.  iana now understands
we are not creating registries yet.

crypto 3961, aes 3962 published.
much time spent reworking text.
thank you Ken.

cfx still in rfc editor queue

ocsp draft is done.  is waiting for balloting of
pkinit.

pkinit is still not done.
no list of open issues to present.  the chair is
tired of working on this draft.  chair will meet
with lzhu later in the week to go over them
russ says "just get it done!!!!" in a loud booming
voice.


* Extensions - Tom Yu (15-60 min)

Typed Hole Assignments.  Question:  Do we want to use
relative or absolute OIDs?  absolute OIDs allow orgs
to self assign.

Nico asks: do we care about size?

Sam says: make sure SMNP wants self assign.  We should
also decide whether or not self assignment should be allowed.
If we required standards action, there is no reason to allow
absolute.

Tom: is authorizationData special with regards to type numbers?

Cliff: AuthData should not be special.  Private uses should
not be allowed.

Sam: Constraint restrictions which have conflicts in AuthData might be dangerous.

Tom: are there any registries we want to maintain outside of IANA?

Kurt: you must use IANA for registry data so they can be used for lookups.

Tom: do the Application Tags need to be registered?

Sam, Nico: No.

Tom: Transited realms in tickets have open questions.  We could delay standards action on this item to delay addressing them.

Tom:  Do we want to put requirements on the use of String Types in new PDUs?

TicketExt and other new extensions ...

jaltman: yes, it would be a good idea to use UTF8 only in new types (if possible)

Sam: not worth doing if it is going to make the ASN.1 more complicated

Tom: readability issues:

do we want to use a common string type for both 1510 style and extension
style?

do we want to have constraints in text or asn.1?

Love: don't like when there are constraints in the ASN.1 which are not enforceable are useless if they don't help the human.

Tom: we need to think about a good middleground.  more time necessary

Sam: do we have timelines?

Chair: later

Tom: do we want to drop "advisory parameters"?  they are for human parsing but do not affect machine parsing.  They tie various ASN.1 PDUs
together.  1510 there are no parameters but we must remember to be
explicit in text about how the

Nico: we can also put the details into the ASN.1 module as comments
instead of syntax the parser will process and then ignore.  I would
like there to be something in the module.

Sam: EncryptedData is one of the best uses of Parameterized Data we
have.  Helped debugging broken implementations.

Tom: "Signed" parameterized type is crucial.

Nico: if we are going to have any parameterized types, keep using parameters with EncryptedData

Tom:  discusses differences between old and new formats
Some people say it is difficult to read.  Changed String types
into parameterized types.  This allows the use of simply CHOICE.

Another alternative is to not use derived types for the two ticket formats.  There is a risk of deviation (human error) between the two types.

Russ: believes the derived version will lead to less human error and
the other version is more readable for asn.1 and kerberos novices

Leif:

Sam: Boulder consensus says we must have a version of this which does
not use any of the complex asn.1 type extensions.  we must be able to
strip out to ASN.1 with CHOICE.  SignedType is a parameterized type
which will require stripping.

Bill: both have human errors.  there are more implementors than designers.

Nico: Shared encoders/decoders produce fewer errors.

Tom: Do we have consensus on the use of shared code paths?  Unknown.

Tom: I'm not familiar with asn.1 toolkits which will produced shared
code paths from derived types.  does anyone have experience?

Russ: PKIX/SMIME decided to stick to a subset of ASN.1 available in
publicly available tools.  This has caused problems with ITU.T since
we are stuck using a deprecated syntax.  All of the base X.509 types
had to expand all of the macros because the tools did not handle them.
I check every draft with gnu asnpp.  Drafts which do not pass will be
sent back.  I recommend restricting to the use of ASN.1 for which free
tools are available.

Tom: to improve readablity we can decrease the inlining the invocations
of parameterized types.  There is some desire to do this by the meeting
participants.

Sam: the parameters could be stripped to make the code more readable
for those who wish without affecting the validity of the asn.1.

Tom: need to clarify capability negotiation; resolve iana policies; and
continue working on the asn.1 modules

Nico: Transitive Encoding.  This is a hard problem.  What was the
resolution?  Do we want to stop the compression thing and how do we
deal with intermediate realms which do not process UTF-8?

Tom: tentative conclusion if we require realm administrators be aware
of and configure into their KDCs which realms support extensions.

Nico: this is already done.  In order to issue the cross realm principal
you must know that the service supports extensions or not.  The question is whether we want to allow ext->ext->1510 if there are utf8 in the name?

jaltman: I would like to speak with Ken H. and Doug about deployment issues.  I am concerned about upgrade paths.

Nico: ext->ext->1510 should be ok provided the path can be represented in 1510

jaltman: there may be other paths to deal with

Chair:  would like to come out of this discussion with some decisions.

Tom: there is a desire for human readability

Chair: Lets produce a set of tickets in RT for Extensions related issues

Sam: please set timelines for major issues such as the ASN.1 Feature Set issue.

Chair: we will defer discussing milestones until the end of the meeting

Sam: There is a IAB expired draft discussing "vendor extensions".  The SIP community feels they got pretty burned and don't want "vendor extensions".  They want "standards action".  I think we are pretty similar to SIP but we want to be open.

Chair: I believe there is a distinction between "vendor" and "site specific" extensions.

Sam: Checksum -138 for example.

Chair: DHCP site local options have also been abused.  There are multiple questions here.  AuthData types cannot be negative.  There are
no private use extensions.  Do we want to continue this?  Do we want to
add private use extensions (neg numbers) to newly typed holes?

Chair: Does the use of private use numbers depend on the assignment policy for non-private numbers?

Sam (no AD):

Chair: How many people think we need to address the assignment policy issue before the private use policy?

   3 not dependent; 3 dependent

jis: questions are linked but the order is not specific

Chair: can we acheive consensus on this here?

   doesn't look like there is; taking it to the mailing list

Luke (via Jabber): what is the existing policy regarding the use of positive numbers for pre-auth types.

Chair: talk to Cliff; he coordinates the issuing of the numbers.
for negative numbers, no auth data and for other stuff use them only
within your site.

Chair: RFC 3961 specifies IANA registration for its types

Tom: there is a good general direction in the form of the ASN.1 but
we need a bit more discussion for fine tuning.

Chair: Tom will produce a list of issues

Chair: Next is Larry on Referrals (no slides)

* Referrals - Larry Zhu (10 min)

Larry: No updates since the last meeting on the Referrals draft.
The draft must be updated to include the Microsoft UPN use in
Smart Cards.  This text was originally proposed for PKINIT and
pulled out.

Chair: Next is Larry on his proposal for Enctype Negotiation.
Please hold questions until the end.

* Enctype Negotiation - Larry Zhu (10 min)

Larry: new draft-zhu-kerb-enctype-nego-00
Allow client and server to negotiate enctypes without using the
KDC.  It has been implemented and shipped in Longhorn Beta 1.
Luke Howard implemented a version for Heimdal / XAD

Larry: in the u2u scenario the server principal can move from machine
to machine with different enctypes.  Updating the AD entry with the
current support is too expensive.

L: Client will send an ordered list of enctypes in the authorization-data in the AP-REQ: AD-ETYPE-NEGOTIATION.  This would be marked IF-RELEVANT.

L: The server would select an enctype supported by the client and the server.  The chosen enctype is then sent in the subkey field of the AP-REP.

L: Questions?

Sam: only use this in protocol environments in which server subkey wins
such as GSS CFX.  you might want to give a bit more non-normative advice
on how the key is generated.  doing so might waste a lot of time since it is non-normative.

L: will recommend that the entropy in the session key be taken advantage of.

Nico: we all agree this doesn't break anything.  Its not bad.  If it is
only going to be useful to GSS CFX how it is going to be accessed?  Will
this be exposed though GSS QoP?  Will this use be determined by client side policy?

Sam: Always use it if you are CFX and the client supports it, use it. Some people might complain if you send an AES key protected by a DES key.  However, similar complaints are implementation policy not user
policy.

Sam: negotiating AES will affect the token type used by CFX.

Chair: negotiation is safe to use in any situation in which server asserted subkeys will win.  This is true for GSS CFX and perhaps other
application protocols.

L: I will work on some text.  Do we want this to be a working group item?

Chair: asking the question. personal opinion this is little reason not to.

Sam: who would find this useful?

Chair: 12 hours before the first posting to the list in a private conversation we came to the conclusion that this functionality is required.

   useful: 1/3,  harmful: none. don't care: some

Matt Peterson: is there a reply attack possible by resending IF-RELEVANT

L: if you don't have a replay cache, you have a more serious problem then a downgrade attack.

Chair: this is auth-data in an AP-REQ.  It is encrypted and integrity protected.  Therefore, you can reply an authenticator but not simply the auth-data field.  There is no problem.

Sam: make sure it fits the charter.  if so, yes it should be a standards track item.

Chair: do people think for this work to proceed along the standards track?

   yes: many   no: none

Chair: do we want this to be a working group item?

   yes: some   no: none

Chair: no new draft name required.  Next is Nico


* Set/Change Password - Nico Williams (10 min)

There was a milestone a few weeks back to determine if we are going in the right direction.

Chair: How many have read the document in the last six months?

    9 (2 via jabber)

Chair: How many think we are going in the right direction?

    yes: 6    no: 0

Chair: seems like yes

Luke (via Jabber): it seems quite complicated

Nico: I need more specific suggestions.  I believe errors handling is complicated.

Leif: localization is too hard.

Nico: In order to extend password policies we need to be able to extend
error strings so the human can see what needs to be changed.  The server
is the only entity that can do this.

Sam: Human readable strings are required for password setting errors.

JHutz: I want to be able to set a local policy and be able to tell the
users why my local policy failed.

L: microsoft will have a hard time implementing this protocol because
the windows has a fixed string catalog.  is this the direction of the
IETF in the future?

Sam: rephrasing "Kerberos error codes are not currently meant for users therefore they are not shown to the user and local interpretation is performed.  This will require changes to the error handling system?"

L: I am against server side localization

Sam: we could send multiple error codes to the clients.  The client might only know a general

   password rejected
   password rejected for policy reason

this requires the distribution of org modified versions to understand local policy errors; instead of using server side localized strings

jaltman: I object strongly to anything that encourages locally modified
versions of my kerberos distribution by organizations.

Sam: I believe the ordered error code approach could meet the needs
of 90%

Leif: as an operator of a semi-large site.  middleware diagnostics.
help desks need to strip data from syslogs to help users.  this is
a drop in the bucket.

jaltman: we want users to change passwords, we need to make it easy
for them.  calling help desks are not always possible.

jhutz: we could use parameterized error codes

???: this would be the worst of both worlds

L: two other comments

there is both a protocol version and an extensibility marker.
can there be a per message version number instead of a protocol
version number?  This would allow backporting of one specific
feature instead of backporting the entire set of updates to the
protocol.

Nico: it is possible to say my version is Y but these features
are not supported.

L: it is not clear that the protocol is not easy to implement
because the password server must be tracked by the server.

Nico: the principal name is the handle.  In a delayed commitment,
the state is stored on the server.  If a delayed commit is in
progress the server can report "delayed commit in progress"
for the purpose of avoiding race conditions.

Jhutz:  describes race conditions with multiple clients.
no worse then multiple clients changing passwords without delayed
commitments.

L: is there an implicit assumption that all keys with have the
same kvno?

Can the client set keys for different enctypes?

jhutz: you must set all of the enctypes for a principal at once.

L: could you put back the ASCII art?  I find this helpful.

Nico: this brings us back to the questions of framing and port
numbers.

Leif: 

Nico: a single principal is supported across an entire cluster
with failover.

Jhutz: think the zephyr service key

Leif: this must happen for multiple clients at once?

jhutz: we must be able to generate a key, distribute the key to all
of the service's servers and only then allow the key to be used.

Chair: Time to discuss Milestones

* Update Milestones - Chair and Participants (10 min)

November deadlines OCSP and PKINIT were missed.

Larry: can we shoot for a WGLC in a month?
We lack opinions because people have stopped reading the draft.

Chair: two concerns.  (1) editors have made changes without there
being consensus reached on the list; (2) creeping featurism.
If we want to last call the document, it has to stand still for
a while

Love: There is signs of optimism.  There is a need for change
to the protocol to fix things which are broken.

jaltman: give people time after proposing things in order to
allow people time to catch up.

Chair: there is a controvertial issue related to the mechanism
by which a certificate can be determined to actually be from
the KDC.

L: we will have a proposal sent to the mailing list within a week.

Chair: suggesting April 05

Sam: remember SASL will be reviewed at that time

Chair: April 05 for Last Call on PKINIT

March 05 for Consensus direction of Change/Set Password

June 05 for resolving Major Issues; August for Last call of Extensions

Last Call for Referrals in August 05

Add milestone for Larry's EncNegot draft: to IESG in May 05

Leaving Change/Set Password Last Call in Sept 05