Subject: Draft 0 - KRB-WG Minneapolis meeting

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 02 Apr 2001 10:18:11 -0500

I have not received any comments on these draft minutes, so I am sending
them out one more time. I was working from Matt Crawford's excellent notes,
but I would have expected some comments. 

To those present at the WG meeting, especially the speakers, please review these 
minutes, and make comments about these minutes. Did I missed something, or got 
something wrong? 

Thanks. 

KRB-WG Minutes - Minneapolis 

The third meeting of the Kerberos WG was held 3/20/2001 in Minneapolis with about 50
attendees. Doug Engert was the chair and Matt Crawford was the scribe. After a short 
introduction of the working group, the bulk of the meeting was concerned with discussions
of the Kerberos-Revisions and the Referrals. 

Cliff Neuman described a number of minor changes to the Revisions, then turn the 
discussion over to Ken Reaburn to discuss the new Section 6. Still to be done
include updating the table of key usage numbers, have a cryptographer review the 
functions and decide which crypto functions should be available to applications. 
Further comments on Section 6 should be sent to Ken. There where some questions.
Should there be a NULL checksum method? No one could see a need for one. 
Are there other crypto methods in use? And will can they follow this section?
John Brezak said the RC4-HMAC could. Will AES also fit? Ken is working on this too,
and answered yes, all that is needed are test vectors. What does visibility of crypto
functions have to do with a protocol? The response was left open. 

Tom Yu then described the new section 5. This section tries to address many backward 
compatibility issues, but adds a lot of complexity to the draft. Tom had proposed
a new KerberosString to address the UTF-8 issues. What came out was that the current
(mis) use of the GerneralString in Kerberos is locality specific. Most implementations
just treat a GeneralString as a bit string, so if all parties agreed, it worked.
There appears that there will need to be some hint in the rest of the message 
(such as in the flags or options) to indicate if GeneralString should be treaded
following ASN.1 rules, or as Kerberos has in the past.  

Tom had also proposed a number of new message types which where designed to be extensible
version of older message types. For example a Ticket2. These where being introduced for 
backwards compatibility. There where still compatibility issues with the new messages
such as how is a client or KDC to know if the other implementation can handle the
new messages. 

There was concern that much of the Section 5 was over kill, and it could introduce
new ASN.1 problems which could also cause backward compatibility problems
and since there where so many problems, we should consider bumping the version number.
It was decide that a smaller group would meet after the WG meeting to discuss the 
Section 5 issues further. (See below for notes from that meeting.)

John Brezak then described the Referrals and name canonicalization documents. At one time
this was a separate document, then last year we tried to roll it into the Revisions,
which appears to have been a mistake, as there are still many concerns with the
referrals. It is not back to a separate document. The Revisions still has the 
necessary flags and numbers reserved. John gave a history of why this was needed,
in organizations with large flat name spaces, where uses may want to keep the same 
name, but be moved to other realms. Since there was so many concerns including GSSAPI
name canonicalization issued, a smaller group would meet later in the week to 
hash out the issues and concerns. There was not general opposition to the concepts,
but there was security concerns as to how it should be implemented.  

Cliff then continued with the Revisions, and there was general consensus that all
the text in the Revisions referring to name canonicalization and referrals work 
could dropped, as these are covered by the Referrals. This will let us move forward 
on the Revisions. 

Brian Tung described the latest revision to PKINIT. The recent last call had a number
of concerns, and a new draft was produced. There are still some issues with  E-E DH.
Matt Hur brought up some issues with a nonce to indicate willingness to accept a 
timestamp.  But the draft could be ready for last call again in two weeks. (Still 
subject to reference to the Revisions, and the flags in the Revisions for PKINIT.)

Ken Hornstein presented KDC and Realm Information with DNS and said another draft
is needed, and could be ready in a month or two for last call.

Jonathan Trostle presented the Kerberos changes/set password I-D update 
and the IAKERB. Both of these need some minor changes. 

Donna Skibbie present KDC LDAP Schema. This draft missed the cutoff, but she was invited
to speak on this again, so that the working group could give more input, and deiced
if this had merit. The presentation was accepted rather well, with even some comments on
using this as the admin interface, include updating keys. The consensus was that this 
should go forward. Other interested in this work should contact Donna, and she 
was going to submit this as a draft, and possible a draft which could access the keys as
well. It would then be up to the Area Directors if these should be assigned to this 
working group. 

Twelve people then meet after the meeting to discuss Sections 5 issues. The main outcome
of this was that the revisions is trying to do to many things at once. It should be
cut back to address only interoperability problems, features which are currently being
implemented and some interoperability problems. In effect it would document 
Kerberos V5.1. New features should be let to a V5.2 Revisions.  Tom Yu was to come up
with the list for what should be in V5.1.  

-- 

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

---

From: "John Brezak" <[email-masked]>
Date: Mon, 2 Apr 2001 15:38:05 -0700

Here are my terse notes from the referrals meeting held on Wednesday
morning.

We had a side meeting to discuss the Kerberos-referrals I-D and arrive
at a shared understanding of the proposal. We divided the discussion
into 3 parts - a) Client name canonicalization, b) server name
canonicalization and c) TGS referrals.

a) Client name canonicalization - the discussion was around the scenario
of a user having a fixed name that is independent of the user's
principal name. If the user's principal name changes (say 
they move to another domain), the user's name doesn't change. There was
no general agreement except that everyone appears to understand the
scneario and agreed that it is a valuable bit of functionality. We
intend to discuss this further on the list and in London. However the
kerberos-revisions will reserve the enterprise name type value and the
name-canonicalization kdcoption. There are 2 problems that are of
concern 1) gssapi name canonicalization and 2) the unauthorized logon
attack (Jeff's attack scenario).

1) For the GSSAPI name canonicalization of the client name for use in
ACLs, there is an existing problem with GSSAPI v2 where servers that
have multiple principal names today can have the exact same problem if a
server is to be used as an authorization subject name that is a GSSAPI
canonical name. This problem is not new to the Kerberos referrals and
needs to be addressed in GSSAPI regardless of how this proceeds.

2) The unauthorized user attack is documented in the current I-D.

b) Server name canonicalization - the scenario was to allow a service
principal to have multiple aliases. In current implementations this is
achieved by having multiple principal names all with the same key. This
is very similar to what we have today, except that the name is never
changed in the ticket (referrals I-D and Win2000). We need to figure out
what is the value of having a "foo$" name in the ticket - the service
doesn't change it anyway in our implementation. There is one expanded
scenario that is very interesting though (brought up by Ken Reaburn). A
user wants to setup a DNS alias for a computer in a foreign realm. The
name that the local user knows the remote server as is not recorded in
the realm of the server, but you would like to allow kerberos to
canonicalize the server name for mutual authentication. We agree to
investigate this scenario. We also discussed the inclusion of the ticket
extension to convey the non-canonical principal name and all aliases for
the name. This was deemed to be very useful for optimizing the ticket
cache, but this will require more thinking to apply it properly.

c) TGS referrals - the scenario is that you want to remove extensive
realm binding information from the client configuration. This means that
a TGS request to a realm that does not have that service can return a
referral to a "closer" realm. The change is that instead of a server
returning a service principal unknown error, it will return an
(unsolicited) cross-realm ticket to a "closer" realm. This saves the
client from having to know the realm of the server beforehand. It was
agreed that this is very useful and should be part of
kerberos-revisions.

-----Original Message-----
From: Douglas E. Engert [mailto:[email-masked]] 
Sent: Monday, April 02, 2001 8:18 AM
To: Douglas E. Engert; [email-masked]
Subject: Draft 0 - KRB-WG Minneapolis meeting

I have not received any comments on these draft minutes, so I am sending
them out one more time. I was working from Matt Crawford's excellent
notes, but I would have expected some comments. 

To those present at the WG meeting, especially the speakers, please
review these 
minutes, and make comments about these minutes. Did I missed something,
or got 
something wrong? 

Thanks. 

The third meeting of the Kerberos WG was held 3/20/2001 in Minneapolis
with about 50 attendees. Doug Engert was the chair and Matt Crawford was
the scribe. After a short 
introduction of the working group, the bulk of the meeting was concerned
with discussions of the Kerberos-Revisions and the Referrals. 

Cliff Neuman described a number of minor changes to the Revisions, then
turn the 
discussion over to Ken Reaburn to discuss the new Section 6. Still to be
done include updating the table of key usage numbers, have a
cryptographer review the 
functions and decide which crypto functions should be available to
applications. 
Further comments on Section 6 should be sent to Ken. There where some
questions. Should there be a NULL checksum method? No one could see a
need for one. 
Are there other crypto methods in use? And will can they follow this
section? John Brezak said the RC4-HMAC could. Will AES also fit? Ken is
working on this too, and answered yes, all that is needed are test
vectors. What does visibility of crypto functions have to do with a
protocol? The response was left open. 

Tom Yu then described the new section 5. This section tries to address
many backward 
compatibility issues, but adds a lot of complexity to the draft. Tom had
proposed a new KerberosString to address the UTF-8 issues. What came out
was that the current
(mis) use of the GerneralString in Kerberos is locality specific. Most
implementations just treat a GeneralString as a bit string, so if all
parties agreed, it worked. There appears that there will need to be some
hint in the rest of the message 
(such as in the flags or options) to indicate if GeneralString should be
treaded following ASN.1 rules, or as Kerberos has in the past.  

Tom had also proposed a number of new message types which where designed
to be extensible version of older message types. For example a Ticket2.
These where being introduced for 
backwards compatibility. There where still compatibility issues with the
new messages such as how is a client or KDC to know if the other
implementation can handle the new messages. 

There was concern that much of the Section 5 was over kill, and it could
introduce new ASN.1 problems which could also cause backward
compatibility problems and since there where so many problems, we should
consider bumping the version number. It was decide that a smaller group
would meet after the WG meeting to discuss the 
Section 5 issues further. (See below for notes from that meeting.)

John Brezak then described the Referrals and name canonicalization
documents. At one time this was a separate document, then last year we
tried to roll it into the Revisions, which appears to have been a
mistake, as there are still many concerns with the referrals. It is not
back to a separate document. The Revisions still has the 
necessary flags and numbers reserved. John gave a history of why this
was needed, in organizations with large flat name spaces, where uses may
want to keep the same 
name, but be moved to other realms. Since there was so many concerns
including GSSAPI name canonicalization issued, a smaller group would
meet later in the week to 
hash out the issues and concerns. There was not general opposition to
the concepts, but there was security concerns as to how it should be
implemented.  

Cliff then continued with the Revisions, and there was general consensus
that all the text in the Revisions referring to name canonicalization
and referrals work 
could dropped, as these are covered by the Referrals. This will let us
move forward 
on the Revisions. 

Brian Tung described the latest revision to PKINIT. The recent last call
had a number of concerns, and a new draft was produced. There are still
some issues with  E-E DH. Matt Hur brought up some issues with a nonce
to indicate willingness to accept a 
timestamp.  But the draft could be ready for last call again in two
weeks. (Still 
subject to reference to the Revisions, and the flags in the Revisions
for PKINIT.)

Ken Hornstein presented KDC and Realm Information with DNS and said
another draft is needed, and could be ready in a month or two for last
call.

Donna Skibbie present KDC LDAP Schema. This draft missed the cutoff, but
she was invited to speak on this again, so that the working group could
give more input, and deiced if this had merit. The presentation was
accepted rather well, with even some comments on using this as the admin
interface, include updating keys. The consensus was that this 
should go forward. Other interested in this work should contact Donna,
and she 
was going to submit this as a draft, and possible a draft which could
access the keys as well. It would then be up to the Area Directors if
these should be assigned to this 
working group. 

Twelve people then meet after the meeting to discuss Sections 5 issues.
The main outcome of this was that the revisions is trying to do to many
things at once. It should be cut back to address only interoperability
problems, features which are currently being implemented and some
interoperability problems. In effect it would document 
Kerberos V5.1. New features should be let to a V5.2 Revisions.  Tom Yu
was to come up with the list for what should be in V5.1.  

--