Subject: KRB-WG Interim Meeting 9/16/03 - Minutes

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 25 Sep 2003 15:42:49 -0500

[This is a repost to the list of the message sent to [email-masked] and the ADs.] 

The KRB-WG Interim meeting was held at Cable Labs in Louisville,CO, 
on 9/16/03 and 9/17/03. In attendance where :
Jeff Altman, Doug Engert, Doc Evans, Sam Hartman, Ken Horenstein, Matt Hur, 
Jeff Hutzelman, Sasha Medvinsky, Cliff Neuman, Ken Reaburn, Eric Rosenfeld,
Todd Stecher, Nico Williams, Tom Yu and Larry Zhu.

WG Chair Doug Engert opened the meeting. Ken Hornstein agreed to 
take notes on the first day, and Jeff Altman on the second day. 
[Thanks for doing this difficult job.]

The consensus of the attendees was that since PKINIT might be a 
controversial topic, it should be discussed first.

Doug thanked the Cable Labs people for hosting the meeting and asked
if they wanted to say a few words.

Eric Rosenfeld explained that Cable Labs is a not-for-profit research
consortium designed to develop technology for the cable industry,
such as high speed internet access and VoIP.  One part of this
technology involves security, hence their interest in Kerberos, PKINIT
specifically.

With that, Doug switched the discussion to PKINIT.  Brian Tung sent out
version 17, which seemed to remove a fair amount from the spec.  Sam
Hartman (MIT) asked if anyone read his list of issues he sent out last
week, and suggested that Ken Raeburn go first explaining his concerns
regarding kcrypto alignment, and then go through Sam's list of issues
regarding preauthentication refactoring.

Ken Raeburn: My concerns are regarding the overloading of the negotiation
of the encryption negotiation for PKINIT.  If public key negotiation
uses a Kerberos enctype number, do they need a full KCRYPTO specification?
That would seem sub optimal, since many parts of the KCRYPTO specification
are not applicable to CMS algorithms used in PKINIT (like string-to-key).

Sam: We have several options

- Decide we don't care (say that PKINIT is a special case)
- Provide another way for PKINIT to learn about client capabilities.

Jeff Hutzlman (CMU): How about a compromise: Define something new (like
a new PA-DATA type) that a client can send CMS encryption algorithm
identifiers in addition to the currently defined integer enctypes.

Sam: You would need to solve the binding problem; how do you bind this new
message to the current PKINIT PA-DATA?  Note that a new preauthentication
framework would have to solve this anyway.

Sam: Since we're going to have to make a wire incompatible change anyway
(changing the PA-DATA number), and that change is small, is adding a new
negotiation mechanism also small?

After an extensive discussion, it was agreed that a new optional field shall
be added to the PKINIT messages from client to server (somewhere is
PA-PK-AS-REP) with the new CMS encryption types.

Sam: Now we can move to the refactoring preauth discussion.  Many preauth
mechanisms duplicate parts of each other; a more modular approach would
be useful.  Are people interested in discussing this?  I don't believe it's
possible to modularize PKINIT without changing the wire encoding.

After an EXTENSIVE discussion, involving all of the PKINIT principals,
Sam agreed that he could commit to producing a preauthentication framework
by November.  It was agreed that interoperability with the PKINIT draft
16 is extremely desirable.

Sam talked about the design team that Eric put together, that generated
the following output:

To Be Removed:

- Use of Raw Public Keys (only Digital Signatures)
- Name transformation (X.500)

Open Issues:

- Security of cached DH values and the use of a nonce
- Confirm alignment of CMS and KCRYPTO/Clarifications (AES, DH Key derivation)
- Internationalization of strings
- Update PA-Types
- Refactoring Kerberos preauthentication
- Need to deal with the transited realm field (due to X.500 removal)
- Principal name as a trusted-CAs CHOICE
- OCSP and optional revocation information
- Extensibility in general (enctype negotiation specifically)

Nico Williams (Sun) pointed out that the use of the principal name in the
trusted-CAs field might be an artifact of the use of a raw public key, and
since that is being removed, perhaps it should be removed.  The consensus
of the group was that this should be removed.

Regarding internationalization, after an extensive discussion, it
was agreed that Jeff Altman should be the one to handle/propose
text for the i18n issue.

Sam Hartman agreed to handle the refactoring Kerberos preauthentication
issue.

Consensus was reached that the preauth type numbers should change, and
Cliff Newman (ISI) was the person in charge of that.

Nico Williams proposed that there was no reason that CAs should appear
in the transited realms field, since they weren't realms.  An extensive
discussion ensued.  The suggestion came up that transited CAs would
appear in a new authorization data field.  It was finally reached
that the authorization data should be added with the semantics that if
you do PKINIT with a non zero list of CAs, you MUST include the
authorization data field.  Nico Williams volunteered to come up with
an A-D type, the semantics for it, and possibly text to go into
PKINIT.

Todd Stecher (Microsoft) volunteered to tackle the PKINIT CMS alignment issues.

Sasha Medvinsky volunteered to handle the PKINIT KCRYPTO alignment issues.

Nico Williams brought up the following clarifications alignment issues:

- Use of unconstrained integer
- Cut & pasting of typed data
- References to RFC1510 & RFC1510bis

And he volunteered to work on them.

Todd Stecher volunteered to issue regarding the handling the security of
the cached DH values, and to provide a proposal for the use of OCSP.

Todd provided an overview of the OCSP issues: basically, data is needed
in the AS_REQ and the AS_REP to provide the OCSP signed data (OCSP protocol
issues are "sketchy" at this point).

Sam Hartman brought up the point that there's no way for the KDC to indicate
that it does PKINIT, but it was decided that this would be discussed later.

In terms of extensibility, Jeff Hutzlman suggested that extensibility
can be achieved by adding ASN.1 extension markers in the appropriate place,
and adding typed holes can be done via a protocol revision (if that ever
happens).  Jeff Hutzlman volunteered to handle this.

Cliff Neuman volunteered to handle the initial flag issue.

There are two milestones that came out of this discussion.
(1) Preauth Framework is needed by November, (2) Wire protocol
for PKINIT needs to be set  even if the text changes. 

PKINIT is needed by some vendors, if the Preauth framework is not
complete by November, the PKINIT should proceed on its own.  

After a break for lunch, the topic switched to Extensions.  The list of
proposed items to add to extensions is currently:

- Brief overview of IETF53 semantics
- Proposals for additional semantics (revoking TGTs, relative OIDs)
- Discussions of encoding (for Wednesday)
- I18N text recommendations (PKINIT, change pw)
- Go through the text and and mark the various strings as Query, Display,
  or Storage.
- Confirm negotiation mechanisms
- Do we have solutions to all open issues?

Regarding current open issues (after December 2001):

- Handling multiple applications with different Kerberos library
  implementations sharing the same credential cache.
- Handling U2U authentication (old versus new)
- Transitive realm encoding
- krb-error guidelines (guidelines on when krb-errors are signed).
- Add nonce to krb-error
- Allow a KDC to offer to support extensions by including PA-DATA suggesting
  PA-AS-REQ.
- Addresses of unknown families should be accepted by the KDC.
- Typed hole name spacing
- Downgrade attack (AS_REQ from extensions to clarifications)
- Clients that are only willing to accept extensions, but may want to probe
  the KDC for extension support.

Jeff Hutzlman presented a slide back from the March 02 IETF meeting, regarding
future enhancements:

- Ability for the IETF to enhance/evolve the protocol (thus adding extension
  markers).
- Support for adding IETF and vendor extensions.
- Ticket extensions
- Make PKCROSS and other WG work items possible.
- Enable tying tickets to host/location/whatever.

New items (from that same presentation):

- New name types (which are dead)
- Cross realm referrals (Todd Stecher agreed to take up Brezak's expired
  document)
- Client name canonicalization
- Fix EDATA brokenness (get rid of it, because of the lack of type semantics)
- Name space restrictions.

Update the MUST implement requirements

Authenticated clear text (consensus is that the this work will be in
extensions).

Additional work that will not appear in extensions, but possibly via other
documents:

- Protect AS_REQ exchange from weak passwords
- PFS for KDC/application exchanges
- Minor error codes
- Key exchange without authentication
- Timestamp independence

Current to-do items:

- Todd revives Brezak's X-realm document (and make it a WG document)
- Remove SMTP name (Cliff)
- Identify international strings (Jeff & Jeff)
- Adding language tags to request as well as reply (Tom Yu)
- PKINIT US-ASCII text (Jeff Altman)
- Nico does UTF-8 for set-change-pw

Tackling Open Issues:

- Mixed client libraries (deferred, Sam Hartman & Jeff Altman will take it)
- U2U negotiation (deferred from this meeting, Tom Yu (MIT))
- Transitive realm encoding. (decided to punt on it)
- KRB-ERROR signing guidelines (deferred, Sam Hartman)
- Add nonce to krb-error (text by Tom Yu)
- Allow a KDC to offer to support extensions by including PA-DATA suggesting
  PA-AS-REQ (deferred, Sam Hartman)
- Internationalization issues (migration, sasl-pref, Jeff & Jeff)
- Allow addresses of unknown families should be accepted by the KDC - all
  agreed, text by Cliff
- Name space restrictions (cache poisoning, algorithm for validating
  transited realm path, deferred, Sam Hartman)
- Encoding proposal (deferred until tomorrow)
- Update MUST implements (DES, 3DES, NOT SHOULD) (deferred)
- Downgrade AS-REQ from Extensions to Clarifications (deferred, Nico Williams)
- Client probe for KDC support (defer to list)

There was an extensive discussion regarding relative OIDs and typed
holes.  The consensus was that we should NOT generalize to all of
the typed hole name space (each typed hole has it's own name space),
allow a relative OID as a CHOICE, defer the the policy discussion
of how to assign the OIDs, and to not assign an OID for current
typed hole name spaces.  Tom and Nico will work together to generate text
and assign the OID space.

After various side discussions, the meeting was closed for the day.

On wednesday morning, Tom begins presentation "Syntax and Encoding for 
Extensibility" [See the attached set of slides.]

A demonstration of extension markers.  "[[" and "]]" brackets are part of 
the notation used to wrap the extended fields.

RELATIVE-OIDs allow for more compact representation on the wire.  The Base 
OID is not included in the ASN.1.  There is no ability to use the ASN.1 
compiler to enforce relativity to a given base.

When would a typed hole be used instead of a new field?  New fields can 
only be created by IETF action to revise the Kerberos protocol.  However, 
typed holes are the preferred mechanism for extending the protocol without
requiring protocol revisions.

Authenticated Cleartext: a checksum will be used to protect a new InnerType 
by signing the InnerType with the available key.  This data structure is 
optional because we do not always have a key available during all instances 
we need to send a KRB_ERROR at.  Signed is extensible because we are being 
conservative about making sure we always have a means of extending constructs
whenever possible.  

There is a desire to rename Signed to something else to make it be less
ambiguous as to whether it is a base ASN.1 type or not.

This discussion applies to both hand and machine generated ASN.1 encoders 
for the Kerberos messages.  The use of shared encoders will reduce costs and 
errors.  MIT does not have script for auto generating the separate encoders 
from the shared encoders at the current time.  We anticipate that high end ASN.1 
compilers provide these transformations.  Microsoft requests that none of the 
new ASN.1 syntax be used. Jeff Hutzelman explains how the shared encoders can be used to 
generate independent encoder input for both 1510 and Extensions.  Perhaps we 
should include expanded ASN.1 modules as an Appendix to the Extensions document.  

Informational Parameters / Constraints.  The WG has done a poor job in the past
of identifying which keys or key usage values should be utilized when encrypting
any particular piece of encrypted data.  

Larry: Why is the 'kvno' in EncryptedData not protected by the checksum?  There
is agreement that the lack of the "kvno" is a defect which should be fixed in 
Extensions.

Larry: It is possible to have multiple keys for the same Enctype, why does 
EncryptedData not take this into account?  This is an issue for Microsoft because 
they use password based Service keys.  This is not an issue for keytab stored 
Service Keys.  Perhaps the EncryptedData should contain a salt-string.  Sam 
believes that passwords should not be used for service keys instead of adding new 
fields to EncryptedData.  

Why should PK-CROSS be a Ticket extension versus an EncryptedData extension?  
The EncryptedData field only contains the minimum information needed to decrypt
the data minus the key.  It seems like other required information could be added.
PK-CROSS is a protocol extension and its operations are unique to a Ticket.  
EncryptedData extensions should be more general.  Lots more discussion.  

Discussion of Microsoft's requirement to use StringToKey on service keys should be 
brought to the list.

Information Objects allow us to formalize how holes are used in the protocol.  

"@" binds the element in padata-value must match the id-int in padata-type.

The TYPED HOLE definition utilizes the WITH SYNTAX mechanism for defining our own 
user readable syntax for specifying typed holes.  

Microsoft supports the use of the Information Object System (IOS) however there 
is significant concern regarding the use of ASN.1 syntax which has not previously 
been used due to the use of internal ASN.1 compilers which have not been verified 
for the previously unused syntax.

All of the proposed extension syntax is accepted provided that simplified forms 
of the ASN.1 modules are provided.  The working group needs to find someone with 
a really good modern ASN.1 compiler to use for verifying. (including expansion of 
parameterized types.)

BREAK

The group desires KRB-SAFE functionality similar to GSS-GET-MIC.

(in case it was not in yesterday's notes)  We want to make it such that KRB-ERROR
Pre-auth failed contain PA-DATA.

Option Flags are to be non critical.  

A question to be answered closer to publication: "must applications support version
1 tickets"?

We need a new typed hole in the authenticator with traditional criticality (i.e., 
NOT CRITICAL)

We need a new critical container for Ticket Extensions.  Mandatory to implement.

We want 64-BIT Sequence numbers. 
 
The group has entered a rat hole while discussing the use of "nonce" within the 
Kerberos protocol.  The nonce is used to bind a reply to a request; and it is also
used to prevent replays.  It is an open issue to determine whether the integer 
nonce should be increased in length.  Larry proposes a random value of 16-bytes in 
length. (octet-string 8..32).  This is implemented as a constrained choice.

Doug then asked if there where any scheduling conflicts for the next WG meeting.
For next Kerberos meeting avoid conflicts with: SASL, SECSH, SAG, IPSEC, 
APP-OPENAREA, LDAP, NFSV4.