Subject: krb-wg 53rd IETF Meeting Minutes

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 01 Apr 2002 14:51:51 -0600

Kerberos  WG (krb-wg)  53rd IETF, 3/19/02
-----------------------------------------

Doug Engert opened the meeting with a review of the agenda. There where
about 116 people attending.

Ken Hornstein volunteered to take note. [These minutes are substantial
his notes. Thanks Ken.]

First item up is Jeff Hutzelman's report of the Kerberos interim WG meeting.
Meeting was Feb 12-13th, had 10 attendees.

Discussions at interim meeting:

- Many desired changes (some conflicting)

Essential items for the next document:

- RFC1510 compatibility (didn't want a new protocol)
- Clarifications to RFC 1510 (name types, KDC replay cache, implementation
  notes)
- Modern crypto architecture, developed by Ken Raeburn.
- How to find a KDC (important, not covered in RFC 1510)
- New network address types
- TCP exchanged with KDC

The basic problem: Conflicting requirements

- Clarifications to RFC 1510 badly needed
- WG wanted extensibility
- IESG mandate for internationalization
- WG wanted various new features

Solutions: Two documents (_neither_ named revisions)

- Kerberos clarifications
  Goals:
	Clarify and cleanup RFC1510
	a few new critical features
	minimal impact on implementors

- Kerberos extensions
  Goals:
	Internationalization
	Complete Extensibility

Kerberos Clarifications

- Goals:
	Must be compatible with RFC 1510 and existing implementations
	Minimize implementation & testing cost

- Document cleanup
	Section with combined ASN.1 encoding
	KDB description dropped (not appropriate for specification)
	Pseudo-code dropped (implementation specific, did not match spec)

- Clarifications
	Name types are _advisory_
	KDC replay cache behavior - need to clarify exactly when same text was
	to be returned and when to return error.
	Implementation notes (document "weird" behavior)
	Others (such as criticality of PA data)

New items -- many from previous kerberos-revisions
- Modern crypto (will remain separate document)
- How to find a KDC (will remain separate document)
- TCP support (who needs to do what, when)
- Network address types (IPv6, any others?)
- Dealing with client time skew
- Kept transited-check and ok-as-delegate ticket flags

- Update the MUST-implement requirements

-- Kerberos Extensions

Goals:
	(Still) must be compatible with RFC 1510
	Usage similar (but doesn't have to be the same) message formats as
	RFC1510

I18N:
	IESG mandate for I18N.
	IESG mandate for UTF-8 encoding as a minimum.
	Support for UTF-8 in principals, realms, passwords.
	Migration for old just-send-8

Future enhancements:
	Ability to enhance/evolve protocol (experience shows that protocols
	are rarely static)
	Support for adding IETF and vendor extensions.
	Ticket Extensions 
	Make PK* and other WG items possible.
	Enabling tying tickets to hosts/location/whatever.

New Items:
	AES (should it remain separate document or get folded into the
	crypto document)
	Request for new name types (SMTP name type)
	Remove address dependencies
	Cross-realm referrals a good idea.
	Client name canonicalization is also a good idea.
	Fix EDATA brokenness (field contains different things depending on what
	the error is)
	Name space restrictions (Microsoft)

Update MUST-implement requirements

Authenticated cleartext? (Not yet achieved consensus on this issue).

-- Additional Work Not Appropriate for Revisions (most are enabled by
   extensibility document)

- Protect AS_REQ exchange against weak passwords.

- PFS for KDC exchanges

- PFS for application exchanges

- Minor error codes (better error text?)

- Key exchange without authentication (how did it relate to anonymous?)

- Timestamp-independence (right now we have places where time stamps
  are in the protocol that makes things not work if clocks are skewed;
  should that be fixed?)

_Whew_

Cliff Neuman was up next with a status report of new documents:

- Decided to separate issues into clarifications & extensions documents
  (See above)

- Goal is to settle clarifications quickly and to move in parallel on
  extensions (will _not_ stop at clarifications).

Clarifications:

- New draft announced & discussed on list; several changes already been
  suggested.
- Significant changes
  - Section 4 - GONE!
  - Section 6 details moved to separate document
  - Pseudocode deleted
  - Appendix A replaced with single ASN.1 code module.
  - Appendix B, Authorization data now scaled back
  - Appendix C, ticket extensions not in clarifications

- Sections needing more significant work:
  - Section 3 needs some update to match new ASN.1 module.
  - Section 5 needs rewrite to bring in line with ASN.1 module.

Clarifications to be made (1)

- I18N text on character sets
- Move tables for assigned numbers
- Implementation notes - behavior of different implementations
- Clarify how enc-tkt-in-skey (explain how u-to-u works).
- Constraints on integers used as types

Clarifications to be made (2)

- Implementation note about typed data in krb-error
- Update _musts_ (encryption, checksums, deprecate things)
- krb-cred without encryption (implementation note - HartmanS)
- security considerations added about end-to-end, especially naming (lot of
  confusion there).
- Recommendations on reducing address dependence
- Changes since 1510 (bcn)

Larry Greenfield brought up the issue about the text in clarifications
regarding canonicalization of host-based service names; he basically asked
that text be added overriding the gss-krb5 mechanism document regarding
how to canonicalize service names.  Doug suggested that Larry send some
text for discussion.

Major extension issues (1)

- Extensibility by vendors and IETF using typed holes
  - Strong words on not-violating interoperability
  - Strong words not to use Kerberos as application transport

- Extensibility markers (but these are for working group use only)

- Address inadvertent use with old clients (transition path)

- I18N
  - Full Unicode for names & passwords

- Reducing of dependence on addresses
  - Explain what this means for forwarding & proxies
  - Use krb_priv/krb_safe with direction bit instead of explicit address

- Desired extensions should be supportable
  - Either by using typed holes (preferred)
    - Enable tying tickets to host / location /whatever (auth data)
    - Encrypted exchanges with KDC for user privacy and reduction of
      offline vulnerabilities
  - Or by explicit support in extensions
    - E.g, anonymous flag

- A reasonable migration path from old to new

Moving Forward

- Completed the listed items for clarifications
- Address comments and suggestion for clarifications submitted on the
  mailing list.
- Last call on clarifications (lets target for 45 days from now, or sooner)
- Continue work on extensions in parallel.

Cliff finished with no further questions from WG.

Next up was Donna Skibbie from IBM, discussing the draft defining the LDAP
Schema for KDC information.  Was presented last year, work has been done,
presenting current status.

Advantages:

- Standard KDC administration API (note: key information is now in a separate
  draft, due to security concerns)
- Leverage existing LDAP tools.
- Single view of user data

Donna explained the flow of data (from KDC->LDAP API->LDAP
server->backend database), and pointed out that the security critical
section was the LDAP API-> LDAP server connection (about 40K lines
of critical code)

Sam Hartman asked if instead of the KDC being an LDAP client, could it
store it in a traditional Kerberos database and instead use LDAP as the
administration to that database.  Donna said, Yes, this was certainly possible.

Attributes defined in KDC LDAP Schema:
- Realm attributes
- Principal attributes

But for more information: contact Donna Skibbie ([email-masked]).

It was brought up that without the key definition, the draft isn't
complete, but Jeff H. pointed out that there are two consumers of this
draft; people who want to use LDAP as a KDC backend, and people who want
to use LDAP as a KDC admin interface. The possibility of two docuemnts
was discussed, with all key related issues in one.  Further discussion to list.

Jacques Vidrine was up next giving a talk about Kerberos weak password
protection.

There are three opportunities for capturing ciphertext:

- AS-REP (sniff it or ask for it)
- PA-ENC-TIMESTAMP (sniff it)
- TGS-REP (ask for it)

Usefulness of ciphertext

- ASN.1 encoding results in a regular structure to plaintext, which makes
  checking easy (check for valid ASN.1 structure).

Operations for password guessing:

- Run through string-to-key
- Decrypt first block (past confounder)
- Check for validity

Possible solutions?

- DCE RFC 26.0-like (use host-configured key)
- SSL/TLS using KDC public key
- LEAF (being looked at by Ken R/John Brezak)
- SRP/PDM

Password Derived Moduli (PDM):

- SACRED WG dropped PDM in favor of SRP
- IP Storage seems to favor SRP (presently being debated)
- IPR Statement on file for SRP but may infringe on patents.

Various other ideas were proposed, based on other SACRED proposals,
possible PDM or SRP derivatives.

Ken Raeburn brings up various points:

- IPR issues was the cause of SACRED dropping PDM
- Ken's straw man proposal for SRP used a cookie in the protocol instead of
  requiring the KDC to keep state.

Charlie Perkins spoke up about IPR issues:

- Patent space is very ugly
- PDM was conceived to not be covered by any patents ... but that means that
  no one is willing to hire a lawyer to defend yourself.
- SRP might have similar issues (patent holders might go after SRP implementors)

- Steve Bellovin noted the irony that EKE was invented to solve this exact
  problem with Kerberos.
- Steve also suggested to iSCSI that they do CHAP under an anonymous
  DH-exchange.

Sam Hartman asked if people believed that anonymous-DH plus PA-ENC-TIMESTAMP
would be good for unkeyed hosts; jhutz points out also that just specifying
SRP is good enough and concerned people can license it.

Because Jeff Altman couldn't be here, jhutz is presenting the UTF-8
string prep profile document.  Lots of various issues regarding UTF-8
normalization (see presentation).

Jeff Schiller brought up some issues with the kerberos passwords document
that was submitted to the IESG; some revision may be necessary.

Doug Engert asked for a show of hands to get a count of people who would be able
to attend in Yokahama. Not many hands were raised. A definite decision 
had not been made as to whether or not this WG will meet in Japan. 

Doug Engert then closed the meeting.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 2 Apr 2002 11:55:31 -0500

> Kerberos  WG (krb-wg)  53rd IETF, 3/19/02

[...]

> 	Name space restrictions (Microsoft)

[...]

> - Key exchange without authentication (how did it relate to anonymous?)

These two are related. The first item was about having a way to limit
the "namespace" trusted to another realm. The example given at the
interim KRB WG meeting was one involving three realms, A, B and C and a
common trusted realm, BCA, where C might not want to trust names from A
when BCA is transited.

IIRC the MS proposal was to have C reject TGS requests involving A
clients transiting through BCA.

My proposal was to add a flag, or, rather, [relevant] authz data
element which might be added by a KDC to a ticket during transit which
would indicate to the application accepting the eventual AP-REQ that the
ticket's client name is to be ignored for the purpose of authorization
(that is, that the AP-REQ can be used for key-exchange but that the
client cannot be considered authenticated).

****

Going back to the MS example, C's KDCs would add this authz data element
(NOT in an AD-IF-RELEVANT) to any ticket transited through BCA whose
client name belongs in the A realm's namespace (i.e., including
sub-realms of A, whether A be transited or not). Thus A clients could in
fact use Kerberos to secure application sessions with C services, but
those services would either treat A clients as anonymous OR further
authenticated them (think web: digest or basic auth over a GSS- or
Kerberos-privacy-protected session).

I think of this as better than C rejecting all ticket requests bearing A
names transiting through BCA. In the case of application services not
aware of this new authz data type the end result is the same, but where
this new authz data type is supported the result is Kerberos key
exchange without authentication.

This authz data type because it has no useful data payload; it's either
present or not, and that's that. It can even be specified in a separate
document and it can be expected to work with RFC1510 Kerberos (modulo
implementation notes wrt AD criticality).

Cheers,

Nico
-- 
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.