Subject: krb-wg-53rd IETF notes - Draft 1.0 for review by attendees

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 21 Mar 2002 14:20:26 -0600

Draft 1.0 of minutes for review by the attendees. Please send comments
on the minutes to me.  

The Kerberos  WG (krb-wg)  meet at 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

(keys in separate document).

(Donna, you're moving too fast for me to take notes!  Refer to her
slides!)

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.  Further discussion to list.

Jacques Vidrine V(?) 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 then closed the meeting.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 21 Mar 2002 16:49:35 -0500

Very good notes.

> Jacques Vidrine V(?) was up next giving a talk about Kerberos weak password

[...]

> - Steve Bellovin noted the irony that EKE was invented to solve this exact

Sigh. Similarly with SPEKE.

> SRP is good enough and concerned people can license it.

DH + Edh(PA-ENC-TIMESTAMP) is subject to a MITM attack. But it's still
an improvement over PA-ENC-TIMESTAMP.

We could specify several mechanisms and let the IP issues be resolved
later. If several mechanisms are specified in one go then realm admins
will have an easier time turning off one pre-auth type when the lawsuits
come, if they do.

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.

---

From: Sam Hartman <[email-masked]>
Date: 21 Mar 2002 16:58:53 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> DH + Edh(PA-ENC-TIMESTAMP) is subject to a MITM
    Nicolas> attack. But it's still an improvement over
    Nicolas> PA-ENC-TIMESTAMP.

Right, but if it is good enough for Athena and for people that use
unkeyed hosts then it's a lot better in my mind that making Kerberos
depend on public key.

---

From: Matt Crawford <[email-masked]>
Date: Thu, 21 Mar 2002 17:06:51 -0600

> - PA-ENC-TIMESTAMP (sniff it)

I eliminate the third one by marking all user principals
KRB5_KDB_DISALLOW_SVR (MIT notation -- disallow requests naming that
principal as the service).

Doesn't everyone?

---

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 21 Mar 2002 17:17:28 -0600

I am changing the title on this, as it is not a comment on the minutes,
but a suggestion. 

Its a good suggestion, and we should have it in the clarifications
as an implementation note. 

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Lawrence Greenfield <[email-masked]>
Date: Thu, 21 Mar 2002 18:23:21 -0500

Cc: "Douglas E. Engert" <[email-masked]>, [email-masked]
   From: Sam Hartman <[email-masked]>
   Date: 21 Mar 2002 16:58:53 -0500

I don't understand the difference between this and using a public key
scheme that is possible to secure.  They degrade to the same attack if
the client doesn't have some certificate to verify the KDC.

Larry

---

From: Sam Hartman <[email-masked]>
Date: 21 Mar 2002 20:41:12 -0500

>>>>> "Douglas" == Douglas E Engert <[email-masked]> writes:

    Douglas> I am changing the title on this, as it is not a comment
    Douglas> on the minutes, but a suggestion.

    Douglas> Its a good suggestion, and we should have it in the
    Douglas> clarifications as an implementation note.

This seems worth noting, but I'd point out that it does disallow some
usage of Kerberos.  In particular, it means I cannot store my key on a
machine and have people authenticate to me as a service.

In most cases this is OK.

---

From: Wyllys Ingersoll <[email-masked]>
Date: Fri, 22 Mar 2002 12:55:37 -0500

[...]

>to use LDAP as a KDC admin interface.  Further discussion to list.
I think the point that was raised was that if  there is a real need to 
have 2 separate documents,
that *all* of the key related items be covered in one, and everything 
else in the other.  I think that
the understanding was that there was some info about key storage in LDAP 
in both the
LDAP Schema draft and the KDC Key storage draft.   I think both are 
going to be updated
soon, so the point may be moot by now anyway.

The issue of  whether or not it is appropriate to use a directory server 
as the KDC backend was
also raised.   I may have misunderstood the comments being made against 
this practice, but
if the directory server is "sufficiently secured" by whatever means, 
 then I dont understand the
strong objections.   I realized this has come up before, but if these 
LDAP drafts go forward,
its going to come up again (see, it already has :).

One final note - Doug 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.  Has a definite 
decision been made
as to whether or not this WG will meet in Japan?  Its a long way off 
(relatively) but international
travel often involves additional lead-time for folks who need to get 
approved for travel such
as this, so it would be good to know what the decision is as soon as 
possible.

thanks,
  Wyllys Ingersoll

---

From: Sam Hartman <[email-masked]>
Date: 26 Mar 2002 16:46:04 -0500

>>>>> "Wyllys" == Wyllys Ingersoll <[email-masked]> writes:

    Wyllys> Douglas E. Engert wrote:

    Wyllys> The issue of whether or not it is appropriate to use a
    Wyllys> directory server as the KDC backend was also raised.  I
    Wyllys> may have misunderstood the comments being made against
    Wyllys> this practice, but if the directory server is
    Wyllys> "sufficiently secured" by whatever means, then I dont
    Wyllys> understand the strong objections.  I realized this has
    Wyllys> come up before, but if these LDAP drafts go forward, its
    Wyllys> going to come up again (see, it already has :).

It has some significant bootstrapping problems, and requires that you
treat your LDAP backups more carefully than you would otherwise do so.
Note that while the keys are encrypted, the keys are not the only
sensitive part of the KDB record.  I understand you have to be fairly
careful with LDAP backups anyway, especially if you use LDAP for
authorization.  However, for many environments it seems reasonable to
claim that authentication and auditing actually benefit from higher
security than that used for authorization.

I'm not prepared to claim in an IETF context that people shouldn't
store their KDB in LDAP.  I will claim that many people do so without
understanding the consequences and do so in environments where there
are no significant benefits.  AS part of the MIT Kerberos team I hope
to convince MIT not to implement LDAP KDB support because I believe it
is significantly misused and providing that functionality might not be
the best thing for our customers.  But that discussion should happen
on krbdev.

I do think it is reasonable in an IETF context for me to work to make
sure that the LDAP schema drafts can be used as an admin protocol even
if LDAP KDB is not used.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 26 Mar 2002 17:18:14 -0500

Given that the KDB description has been ripped out of clarifications
(and, by extension, extensions) I would say that how an implementation
of a KDC stores and retrieves KDB records is out of scope for
clarifications (and extensions).

I think that the security considerations section should, nonetheless,
have language to strongly impress upon readers the importance of
securing the KDB, particularly should it be distributed beyond the KDCs
themselves.

Cheers,

Nico

---

From: Sam Hartman <[email-masked]>
Date: 26 Mar 2002 17:25:05 -0500

I agree.

---

From: Wyllys Ingersoll <[email-masked]>
Date: Tue, 26 Mar 2002 17:40:47 -0500

> security than that used for authorization.

I certainly agree with you.  There are bootstrapping problems
(chicken or egg?) and the database that is used to store the
data must certainly be protected.  This much is obvious.

> the best thing for our customers.  But that discussion should happen

Alot of large organizations are moving towards storing their
user/employee information in some directory service, typically
with an LDAP interface to the information.  There would be
significant  benefit for these large organizations if their Kerberos
information could be stored and accessed in a similar manner.  Anything
that can be done to reduce the management and administrative overhead
for Kerberos in general would be very well recieved by customers
everywhere.

> sure that the LDAP schema drafts can be used as an admin protocol even

Having a standardized, published, administrative protocol would be
great.  However, it may be beyond the scope of the WG to specify the
details of whatever DB is actually used to store the information except
to say in no uncertain terms that it must be sufficiently secured.

-wyllys

---

From: Wyllys Ingersoll <[email-masked]>
Date: Tue, 26 Mar 2002 22:14:23 -0500

Sam Hartman wrote:
>>>>>>"Wyllys" == Wyllys Ingersoll <[email-masked]> writes:
>>>>>
> 
>     >> I'm not prepared to claim in an IETF context that people
>     >> shouldn't store their KDB in LDAP.  I will claim that many
>     >> people do so without understanding the consequences and do so
>     >> in environments where there are no significant benefits.  AS
>     >> part of the MIT Kerberos team I hope to convince MIT not to
>     >> implement LDAP KDB support because I believe it is
>     >> significantly misused and providing that functionality might
>     >> not be the best thing for our customers.  But that discussion
>     >> should happen on krbdev.
> 
>     Wyllys> Alot of large organizations are moving towards storing
>     Wyllys> their user/employee information in some directory service,
>     Wyllys> typically with an LDAP interface to the information.
>     Wyllys> There would be significant benefit for these large
>     Wyllys> organizations if their Kerberos information could be
>     Wyllys> stored and accessed in a similar manner.  Anything that
>     Wyllys> can be done to reduce the management and administrative
>     Wyllys> overhead for Kerberos in general would be very well
>     Wyllys> recieved by customers everywhere.
> 
> I've heard this claim and this is the primary reason that I'm pushing
> MIT to avoid using LDAP.  People seem to be using LDAP for Kerberos
> out of reflex--we want to store everything in LDAP--than because it
> buys their organization something.  Because of the backup concerns I
> actually suspect it costs their organization more than it saves.

I agree that LDAP is a popular "buzzword", and that many people who
request its use do not fully understand the implications or issues
involved in implementing it.  However, there are compelling reasons
to consider it as an alternative to the current KDB.  I would certainly
not recommend storing the keys and other sensitive information in the
same DB as the rest of the user/employee data, but a properly specified
schema can make allowances for this through the use of referrals to
a more secure DB (just one example).  Ultimately the goal should be
a more scalable, and more managable DB.  One that integrates
easily into an existing infrastructure is even better.

I guess at this point, this is more of a krbdev discussion rather
than a krb-wg one.

>     >> I do think it is reasonable in an IETF context for me to work
>     >> to make sure that the LDAP schema drafts can be used as an
>     >> admin protocol even if LDAP KDB is not used.
> 
>     Wyllys> Having a standardized, published, administrative protocol
>     Wyllys> would be great.  However, it may be beyond the scope of
>     Wyllys> the WG to specify the details of whatever DB is actually
>     Wyllys> used to store the information except to say in no
>     Wyllys> uncertain terms that it must be sufficiently secured.
> 
> question: Are you aware of anyone claiming the WG should say anything
> about the DB?  I'm certainly not saying that; I'm simply asking that
> the LDAP drafts be reviewed for an additional use besides as a
> mechanism for the KDC to use to communicate to an LDAP server.

No, and I didnt mean to imply otherwise.  I agree that LDAP related
drafts should be reviewed for both uses as well.

-wyllys