Subject: RE: I-D ACTION:draft-josefsson-sasl-kerberos5-00.txt

From: Tim Alsop <[email-masked]>
Date: Sat, 11 Jan 2003 10:42:10 -0000

My comments below :

-----Original Message-----
From: Simon Josefsson [mailto:[email-masked]] 
Sent: 11 January 2003 10:19
To: Sam Hartman
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-josefsson-sasl-kerberos5-00.txt

Sam Hartman <[email-masked]> writes:

> So, what operational situations do you need this mechanism for?  The 
> iakerb justification is that you may want to use Kerberos for initial 
> authentication before you can route packets to the KDC.

One example is accessing mail servers through firewalls that filter Kerberos
(when the server is behind a firewall but also when the client is behind a
VPN or point to point connection to the mail server, or for limited IPv6
only clients).

Tim> So, why can you not use IAKERB for this ? I am trying to understand why
SASL helps rather than using regular IP communications, so can you explain
this please ?

This can of course be generalized into all situations where the server is in
a better position, network topology or otherwise, to contact the KDC than
the client.

If the IAKERB/GSSAPI combo does not offer forwarding credentials in SASL,
accessing servers that can make use of the users' credentials would be
another example.

Tim> I understand that the GSSAPI involvement in the IAKERB draft is mostly
because the only known implementation of this draft today is in Microsoft
products (IE and IIS) where Microsoft needed to negotiate between NTLM and
k5 and so SPNEGO with GSS was the approach chosen to do this. The basic
'proxy' components of the IAKERB draft are more than capable of addressing
the needs of a KDC behind a firewall or VPN gateway.