Subject: RE: [Fwd: Re: Submission of draft-ietf-cat-iakerb-08.txt to IESG]

From: Tim Alsop <[email-masked]>
Date: Fri, 18 Oct 2002 09:08:04 +0100

Hi,

As I mentioned yesterday I would try and find time to look at the draft. I
have started to review it and have a few comments/questions which I thought
were worth mentioning :

When I started reading it I read upto section 4 (ie. Overview) and starting
thinking to myself that this looks fairly straightforward so far ... I could
see real benefits, real need and understood the way it was being proposed.
My understanding at that point was that a Kerberos client on one side of an
IAKERB proxy can work the exact same way as it does today when on a regular
intranet environment such that it can obtain TGT, issue TGS requests,
receive cross realm TGT's, sent AP-Req's etc. without any loss in
functionality. It was clear that the Kerberos client software on both the
client and service hosts are likely to need some changes to support IAKERB
communications, but any applications that are currently written that are
'kerberos enabled' would work transpartently as long as the kerberos client
libraries on each of the systems understood how to communicate through such
a proxy.

A consideration on the above reference to Kerberos client changes - this
means that Microsoft Windows 2k/XP and all unix kerberos clients (CyberSafe,
MIT, Heimdal, etc.) would have to be changed to allow them to work
transparantly through the IAKERB proxy. Is this understanding correct, or
have I missunderstood the transparency capabilities of this proxy ?

The important consideration is that any application today, either
commercially available or customer written should work in the same way today
when not going via. an IAKERB proxy as it would where a proxy was placed
between the client and KDC/service. Is this correct ? We don't want to force
any application developers to change their code to support this, do we ?

Anyway. I then read further into the draft and started to get a little
confused. There were references to GSS and SPNEGO in section 5 and I cannot
see why ? What is there to negotiate ? I haven't read the remainder of the
draft in detail yet because I want somebody to explain to me why GSS is
mentioned in this draft ? I thought GSS was a mechanism indepent API often
used to allow application developers to secure their applications without
having to necessarily understand the specifics of the mechanism being used ?
If so, then surely GSS is related to application interfaces and this is what
it is/was designed for, so why do we need to use GSS for a proxy that
handles forwarding of kerberos tickets/messages across networks ? If this is
referenced to allow GSS enabled applications to work through the proxy then
this needs to be made much clearer - it is not obvious to me as a first time
reviewer of this draft.

Thanks, Tim.

-----Original Message-----
From: Jeffrey Altman [mailto:[email-masked]] 
Sent: 17 October 2002 18:10
To: Tim Alsop
Cc: Tim Alsop; Ken Hornstein; [email-masked]; [email-masked]
Subject: RE: [Fwd: Re: Submission of draft-ietf-cat-iakerb-08.txt to IESG]

> Jeffrey wrote:
> 
> as you can tell from the discussion, the problem is a lack of people 
> to discuss the topic from a position of expertise.  Most expertise 
> comes from experience related to implementation.  Since no one has 
> attempted to implement this draft I believe it is impossible for us to 
> resolve the issues.
> 
> If this draft is going to be important to you, I hope you will find 
> the time to review it closely in the short term.  It would be very bad 
> if this draft is approved as an RFC simply because of lack of proper 
> review and then in three months time when you need to implement it you 
> find that you cannot.
> 
> -------------
> 
> I will try and find time to look at the draft in next few days, but we 
> are not just interested in this draft. We are looking to get our 
> GSS-API, SPNEGO, EAP-GSS, 802.1X and IAKERB together to create a 
> solution. There is a lot of new technology and drafts in different 
> stages of maturity that need to be considered, the IAKERB is only one 
> of them. I hope this helps you understand why it may take us a number 
> of months to validate on paper of in prototype whether IAKERB meets 
> our needs.
> 
> For the reasons explained above - my last posting to this distribution 
> suggested that we leave it as a draft or perhaps (if possible) move to 
> some mid-way status between an RFC and draft - is that the 
> Experimental status ? I noticed that the EAP-GSS draft is in 
> experimental status, so perhaps that is the right place to put the 
> IAKERB draft ?
> 
> 

It is my opinion that the draft should be made an Experimental RFC until
such time as some real world implementation experience is available.  

 - Jeff

 Jeffrey Altman * Sr.Software Designer     Kermit 95 2.0 GUI available
now!!!
 The Kermit Project @ Columbia University  SSH, Secure Telnet, Secure FTP,
HTTP
 http://www.kermit-project.org/            Secured with MIT Kerberos, SRP,
and 
 [email-masked]               OpenSSL.