Subject: Minutes for - KRB-WG London meeting

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 27 Aug 2001 10:48:45 -0500

The fourth meeting of the Kerberos WG was held 8/8/2001 in London, with about 45
attendees. Since the last meeting we have had two WG last calls, on the Password 
change protocol and IAKERB. The Password change draft has been sent to the IESG.
The IAKERB will be shortly. 

The bulk of the meeting was concerned with the Kerberos Revisions. 

Cliff Neuman described a number of changes most of which where suggested at the 
last meeting. Compatibility with existing implementations, and reuse of code
was highly desirable. A list of how the client, server and KDC could know if 
it was OK to use the new format was listed.   

Ken Raeburn talked on Section 6, the encryption framework. There was consensus 
that the list of required encryption types will be listed in an appendix. The 
appendix would be for those encryption types not required for compliance, for example 
des-cbc-crc.  The list of required types will be in section 9 but needs updating.
All agree the if AES is available it should be required, but if AES is not available 
then either 3des or rc4 needs to be required. There are two camps on which should be
required.  

Tom Yu talked on Section 5, messages. A new approach for compatibility is now being 
finalized which uses new Application Tags for new format messages, which are the same 
as old format messages, but have additional fields, or optional fields thus allowing the 
same parser to pares both old and new format messages. This was not in the current draft. 

Sam Hartman talked on some of the other new features which will be included. These 
include ticket extensions, and a way of using a new address type to avoid the problems 
with addresses introduced by NAT and VPNs.     

Jeff Hutzelman discussed authenticated error messages, and there was consensus that if 
possible messages should be authenticated, as long as this does not help expose the users
key, as described below in the AS_REP concerns. 

The main unresolved issue is the (mis)use of GeneralString and UTF8. All agreed that 
this has to be addressed at some time. Harald Alvestrand [email-masked] gave us the 
IESG's view on internationalization. (The next day we also meet with Patrik Faltstrom 
[email-masked] Application's Area director who went into greater detail on the problems 
dealing with internationalization. He is willing to work with us on this. It also looks 
like we have a migration path for this, allowing us to state in the revisions the use 
of GeneralString really only applies to ASCII, and that we are working on a solution.
Jeff Hutzelman promised to write up the minutes of this meeting.)
So it might be possible to have this as a separate draft, and to proceed with the 
revisions with a warning about the misuse of GeneralString for other then ASCII. 

So it looks like the Revisions are finally starting to fall into place. There was also 
consensus that if there are older sections of RFC 1510 such as DES, we could reference
RFC 1510, rather then rewriting in new revisions.  

John Brezak presented some concerns with the security of the AP_REP. An attack might be
possible if enough separate responses could be collected. Possible solutions include SSL,
SRP, EKE, or PDM.       

John Brezak then described the revised referral informational draft. There are still issues
with cache efficiency, GSSAPI canonicalization, (John will try and talk to Martin Rex),
and the use of the KRB_ERR.  

Ken Raeburn described the AES draft, and there was consensus that the 192 could be dropped
but keep 128 and 256. There are still issues with the string-to-key functions. 

Brian Tung has a new version of the PKINIT which addresses some concerns. 

Matt Crawford described a new draft which allows a user to use unmodified telnet
along with a hardware token to have a modified telnetd obtain a ticket
for the user without exposing the Kerberos password.    
 
-- 

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

---

From: Matt Crawford <[email-masked]>
Date: Thu, 30 Aug 2001 08:28:17 -0500

> John Brezak presented some concerns with the security of the
> AP_REP. An attack might be possible if enough separate responses
> could be collected. Possible solutions include SSL, SRP, EKE, or PDM.

AP_REP?  I thought it was AS_REP, and you only needed to collect one
packet in order to try a dictionary attack against the password.  Was
I reading my own concern into John's talk?  If I didn't
misunderstand, then recall my mention of DCE RFC 26.0 ...

---

From: Martin Rex <[email-masked]>
Date: Thu, 30 Aug 2001 16:06:11 +0200 (METDST)

> misunderstand, then recall my mention of DCE RFC 26.0 ...

Each time when some information is encrypted with a key that is
directly derived from a human-user chosen password.  This probably
affects Service-Tickets addressed at users instead of servers,
or Service-Tickets for services that don't use a strong random
password but a human chosen password (e.g. W2K services ...)

This probably affects several protocol containers.  I complained
about the checksum on the Kerberos error message for authentication
failures to the AS/KDC.

From what I recall of Bill Sommerfelds explanation, DCE uses
superencryption with the machine's host key of (at least vulerable parts)
of the AS-exchange.

If you look at the IAKERB proposal: it creates such a situation where
the IAKERB Proxy requests a service ticket for a likely human user
and sends it in an AP_REQ message to the user...

-Martin

---

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 30 Aug 2001 10:08:26 -0500

> misunderstand, then recall my mention of DCE RFC 26.0 ...

I had mistyped in the minutes AP_REP, the slides do say AS_REQ. The
slides where also submitted and are attachments to the minutes you should 
have received.

--