Subject: RE: Interim IETF KRB-WG meeting

From: "John Brezak" <[email-masked]>
Date: Mon, 11 Feb 2002 12:06:44 -0800

I'd like to propose that we take the current kerberos-revisions, which
is the delta from 1510 without any ASN.1 extensibility cleanup and move
toward getting this completed - last call for the spring meetings. Once
that is completed, let us move forward with a more comprehensive
Kerberos extensibility and features I-D called "Kerberos 6".

Here is my rationale:

- I did a review of the changes required to implement the current ASN.1
proposal and found it to be in the order of 9 EM and a recurring cost of
an additional person to keep up with ongoing testing.

- ASN.1 extensibility is important and should have been in the protocol
from the beginning, however it will be very difficult and expensive to
fit this into the current protocol. We need to stop thinking about this
as a neat update to the current protocol - it is a new protocol and we
should approach it from this perspective.

- The extensibility and cleanup of ASN.1 is not sufficient justification
for implementation. From a vendor perspective, 1510 can continue to be
used with additional extensions for some time without having to resort
to the additional cost of a new protocol.

- The GeneralString problem is best dealt with in a major protocol
revision. Existing practice can be documented in the kerberos-revisions
along with recommendations on achieving interoperability across
implementations. There is also a dependency on DNS internationalization
that needs to be resolved before moving forward. I understand that the
IESG wants this addressed, but there are sufficient impediments to
accomplishing this.

- It is important to describe how current typed holes are to be
utililized that is not sufficiently explained in 1510. For example
authorization data and error data needs to have clear explainations. The
current Kerberos-revisions does this.

- Ticket extensions are needed quickly to support PKCROSS. PKCROSS is a
very important protocol needed to grow the adoption of Kerberos.

- Signed plaintext is a difficult problem and important problem, but I
believe it can be deferred until Kerb6 because Kerberos has been useful
without it. If needed pa-data and e-data can be used for this. Not
pretty, but it can work.

- Resources are limited. So far the working group have been completely
absorbed in Kerberos-revisions. There are important clarifications
needed in Kerberos that need to be documented in an RFC. There are other
functional areas of Kerberos like - referrals, initial authentication
protection, PK integration, new encryption types, application protocols,
implications of transitivity on namespaces, etc., that need attention of
this group. These areas will directly speed adoption of Kerberos and
deserve much more attention.

I propose this timeline:

- Last call for PKINIT and Kerberos-revisions (1510 delta) for Spring
2002
- Last call for PKCROSS Winter 2002
- Last call for Kerberos6 Spring 2003

I would suggest taking the Tuesday meeting to make the required feature
list for Kerberos-revisions '02 and focus on moving this forward toward
last call. We need to get control of Kerberos-revision's features
otherwise we will never ship it.

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Friday, February 08, 2002 11:28 AM
> To: Douglas E. Engert
> Cc: [email-masked]
> Subject: Re: Interim IETF KRB-WG meeting
> 
> 
> Doug, John brought up an interesting point in a discussion 
> with us last week.  It's fairly important that we produce a 
> spec that is acceptable to vendors: we want to make sure that 
> vendors can justify implementing our changes.
> 
> John has some ideas on how to accomplish this.  I think that 
> it would be worth a some of our time to discuss these issues.  
> 
> Also, I'll have a short presentation prepared on the open 
> issues list. If you have an issue with the extensibility 
> proposal that has not been properly addressed and it isn't on
> the   list I sent out in December, please let me know.
> 
> 
> I know about several issues that Microsoft presented in SLC 
> and in mail since then.
> 
> Jeff Altman is arriving Sunday.  We hope to have something 
> intelligent to say about UTF-8 by Tuesday.
> 
> 
> I also continue to work on coming up with proposed patches to 
> the draft to integrate parts of the extensibility proposal 
> that appear to have general agreement.  The actual ASN.1 
> still has several open issues, as do a few details.  But I 
> think the basic framework is getting to a point where at 
> least looking at how it fits into the draft would be worth our time.
> 
> --Sam
>

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 11 Feb 2002 15:42:11 -0500

> IESG wants this addressed, but there are sufficient impediments to

Actually, I believe there is no dependency on the DNS i18n stuff. The
reason is that RFC1510 Kerberos is already so different, so much
broader in its namespace from DNS that it is simply not possible to
retrofit IDN and stay backwards compatible with RFC1510 usage in the
ASCII part of the Kerberos namespace.

The stringprep draft is a useful guideline for dealing with the UTF-8
normalization issues however, but it need not progress for the
Kerberos extensibility/UTF-8 stuff to progress (the applicable bits of
stringprep are so small that they could be lifted almost verbatim, thus
eliminating the normative reference to stringprep altogether).

> without it. If needed pa-data and e-data can be used for this. Not

I think there's a way to secure RFC1510 AS exchanges without having to
perform sugery on the ASN.1 such that systems with service principals
can secure AS exchanges for user logins as follows:

 - TCP connect to AS
 - send AP-REQ to AS using the client [workstation] host's SPN
 - wait for AP-REQ or KRB-ERROR from AS

    - if KRB-ERROR log loudly and proceed with traditional AS-REQ; log
      any KRB-ERROR reply to the traditional AS-REQ loudly

    - if AP-REP send AS-REQ wrapped in a KRB-SAFE and wait for an AS-REP
      or KRB-ERROR wrapped in a KRB-SAFE

Very simple to implement, no new ASN.1, backwards compatible with RFC1510.

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: 11 Feb 2002 19:11:37 -0500

>>>>> "John" == John Brezak <[email-masked]> writes:

    John> I'd like to propose that we take the current kerberos-revisions, which
    John> is the delta from 1510 without any ASN.1 extensibility cleanup and move
    John> toward getting this completed - last call for the spring meetings. Once
    John> that is completed, let us move forward with a more comprehensive
    John> Kerberos extensibility and features I-D called "Kerberos 6".

I must say that I'm somewhat shocked and surprised by this proposal;
it certainly presents a different tone than the discussions we've been
having over the last few weeks.  I do appreciate you bringing these
issues forward to the WG so we can discuss them fully.

This proposal also presents a significant departure from the consensus
that was apparent at the Salt Lake City meeting (and later supported
on the list) that we wanted to solve the extensibility problems in
revisions.  Coming to realize that you want to reconsider a decision,
particularly a recent decision, does happen from time to time.  

However, as I discussed previously it seems that as a working group we
have two options if we believe the December proposal is too expensive.

We could decide that another proposal provides a solution to the
extensibility problem at a lower cost.  The easiest way of doing this
is to find a lower-cost proposal.  We think we've done the best we
can, but someone else could always think of something clever.

We did try and split out our proposal so that our goals were separate
from the specific implementation.  Thus it should be fairly easy to
argue that a specific alternative proposal solves the same problems we
did even if the implementation is very different.

Alternatively, we could decide that we don't want to solve the
extensibility problem possibly because it is too expensive.  We tried
to clearly state our reasons for believing that the extensibility
problem needed to be solved.  If you want to move forward on this
option, then you should explicitly disagree with one of our
assumptions or the reasoning that lead us from the assumption to the
conclusion that we need to solve the extensibility problem.

Alternatively you could present a case that we've correctly identified
a problem and its consequences but that solving the problem is too
expensive.  If you present such a case, you should explain how to deal
with the consequences of the problem.  For example we argued that
without extensibility mechanisms vendors are likely to extend the
protocol in incompatible ways.  If you argue we don't want to solve
extensibility,  you should explain what we do about these incompatible
extensions or why it is acceptable to have interoperability decrease
over time.

I'm not clear whether you consider your proposal to be an alternative
proposal that   eventually solves extensibility   or an argument that
we don't need to solve extensibility now.

Either way, I'm not sure how you save money with this proposal instead
of just going forward with the new protocol.

If we continue to encourage use of protocols based on RFC 1510 and do
not fix the extensibility problems, what do we do to avoid the
evolutionary problems of Kerberos Version 4?

Similarly we have some technical concerns with your proposal.  OUr
efforts to fix Kerberos over the past year have been motivated by
problems with the existing Kerberos revisions document.  Certainly,
the revisions document presented at San Diego was not compatible with
RFC 1510.  We aren't sure what you consider to be an acceptable delta
over RFC 1510 and we are not convinced that generating such a delta is
easier than completing work on revisions.

Similarly we contend that ticket extensions cannot be added to
Kerberos without adding capability negotiation.  We are very
uncomfortable adding capability negotiation now for ticket extensions
and later for other protocol features.

That's just my initial reaction.  We look forward to discussing these
and other issues in the Kerberos meeting.

--Sam

---

From: Martin Rex <[email-masked]>
Date: Wed, 13 Feb 2002 17:52:10 +0100 (MET)

> Very simple to implement, no new ASN.1, backwards compatible with RFC1510.

What about workstations without a host SPN? (and IAKERB scenarios?)

What do you do if the host SPN is from a different realm than
the realm the user wants to login to?

Do we want to require the host-SPN to be accessible for the user
(or require a trusted service for this purpose) from *ALL* Kerberos
implementations?

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 13 Feb 2002 12:11:43 -0500

This was a straw man. I wasn't seriously proposing this.

Nico