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

From: [email-masked]
Date: Fri, 10 Jan 2003 13:49:18 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: A Kerberos 5 SASL Mechanism
	Author(s)	: S. Josefsson
	Filename	: draft-josefsson-sasl-kerberos5-00.txt
	Pages		: 11
	Date		: 2003-1-9
	
This document specifies a Simple Authentication and Security Layer
(SASL) [3] mechanism for Kerberos 5 Client/Server Authentication [1],
with optional initial Authentication Service (AS) and/or
Ticket-Granting-Service (TGS) exchanges.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-josefsson-sasl-kerberos5-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-josefsson-sasl-kerberos5-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-josefsson-sasl-kerberos5-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 10 Jan 2003 13:38:09 -0600

Does anyone know anything about this draft, or why it was sent to 
the krb-wg? It is not an official WG document. It may also be out of
the scope of the WG. 

Also what does it gain over the use of SASL with gssapi? It does not
discuss forwarded or delegated credentials.

[email-masked] wrote:
>   --------------------------------------------------------------------------------------------
> Content-Type: text/plain
> Content-ID:     <[email-masked]>

-- 

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

---

From: Sam Hartman <[email-masked]>
Date: Fri, 10 Jan 2003 14:56:08 -0500

>>>>> "Douglas" == Douglas E Engert <[email-masked]> writes:

    Douglas> Does anyone know anything about this draft, or why it was
    Douglas> sent to the krb-wg? It is not an official WG document. It
    Douglas> may also be out of the scope of the WG.

It does overlap with technology we are working on--iakerb.  

It's probably good we were informed.

    Douglas> Also what does it gain over the use of SASL with gssapi?
    Douglas> It does not discuss forwarded or delegated credentials.

It gives you iakerb like functionality.  One valid response for us
would be to decide people wanting that functionality should use iakerb
and to send mail to the security ADs saying we do not believe the
document should be published as the IETF already has a better solution
to the problem.

Another solution would be to decide we like this approach better than
iakerb and to either try and get the draft to go forward as an
individual submission or to get it assigned to our working group.

---

From: Luke Howard <[email-masked]>
Date: Sat, 11 Jan 2003 14:25:45 +1100

>document should be published as the IETF already has a better solution

The KERBEROS_V5 SASL mechanism might be a "better" solution, but IAKERB
has the advantage of working with protocols that do not support SASL
(such as DCE RPC) and not requiring changes to existing SASL code,
except to add (for example) GSS-IAKERB as a registered mechanism name.

-- Luke

--
Luke Howard | PADL Software Pty Ltd | www.padl.com

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 11 Jan 2003 08:19:10 +0100

> the krb-wg? It is not an official WG document. It may also be out of

I asked for the draft to be announced here as well, in case the
expertise here have time to look at it, and as it may overlap with
IAKERB.  Feedback is appreciated.

> discuss forwarded or delegated credentials.

The draft discusses some benefits over GSSAPI: AS/TGS exchanges for
nodes without IP addresses, like IAKERB.  Another advantage is support
for forwarded credentials via the KRB_CRED packet.  Compared to
IAKERB, one practical benefit is that the specification doesn't update
the base Kerberos V5 or GSSAPI specifications and supposedly
consequently doesn't require changes in the Kerberos or GSSAPI
implementation.

> except to add (for example) GSS-IAKERB as a registered mechanism name.

IAKERB can use the "GSSAPI" SASL name if I understand it correctly.
However, it will require changes in the SASL GSSAPI code, and may
require changes in the GSSAPI and Kerberos V5 code as well.

---

From: Sam Hartman <[email-masked]>
Date: Sat, 11 Jan 2003 02:40:46 -0500

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.

Who is planning to use SASL for initial authentication or in some
protocol where you cannot depend on IP?

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 11 Jan 2003 11:18:59 +0100

> 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).

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.

---

From: Luke Howard <[email-masked]>
Date: Sun, 12 Jan 2003 02:06:05 +1100

>require changes in the GSSAPI and Kerberos V5 code as well.

According to draft-ietf-cat-sasl-gssapi-05.txt, section 3:

...
   Each and every GSSAPI mechanism used within SASL is implicitly
   registered by this specification.

   For backwards compatibility with existing implementations of Kerberos
   V5 and SPNEGO under SASL, the SASL mechanism name for the Kerberos V5
   GSSAPI mechanism [GSSAPI-KERBEROS] is "GSSAPI" and the SASL mechanism
   for the SPNEGO GSSAPI mechanism [SPNEGO] is "GSS-SPNEGO".  The SASL
   mechanism name for any other GSSAPI mechanism is the concatenation of
   "GSS-" and the Base32 encoding of the first ten bytes of the MD5 hash
   [MD5] of the ASN.1 DER encoding [ASN1] of the GSSAPI mechanism's OID.
   Base32 encoding is described later in this document.  The Base32   
   rules on padding characters and characters outside of the base32  
   alphabet are not relevant to this use of Base32.
...

-- Luke

---

From: Lawrence Greenfield <[email-masked]>
Date: Mon, 13 Jan 2003 13:30:18 -0500

I find this SASL mechanism interesting in several ways. I'm not sure
any of these reasons are important enough to suggest implementation
but I list them here for others to consider.

- It might allow clients to do something more sane for users. Users
  have a lot of trouble setting up Kerberos when all they want to do
  is check their e-mail (or whatever). If the server is able to
  redirect the initial authentication to the appropriate Kerberos
  server, it might make the "kerberos out of the box" work.

- It discusses the "combined service & KDC" operation. This is
  interesting since it makes Kerberos a strict superset of SASL
  mechanisms such as CRAM-MD5 or DIGEST-MD5.

- It uses the krb_mk_safe, krb_mk_priv primitives directly, which cuts
  down on the number of cryptography primitives needed to understand
  the security of the system.

- Last & least, it avoids the non-interoperable GSS layer, and cuts
  down on the number of round-trips necessary.

Again, none of these are necessary killer reasons for a new SASL
mechanism, but they are advantages over the existing GSSAPI SASL
mechanism.

Larry

---

From: Sam Hartman <[email-masked]>
Date: Mon, 13 Jan 2003 13:58:14 -0500

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> 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.

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

Considering your response, I am coming to the strong conclusion your
draft should not be considered for standards track for architectural
reasons.

This is the IETF; we're designing Internet protocols here.  Tunneling
every protocol we do over every other protocol is not reasonable from
a complexity standpoint.

Yes, there are firewalls, but if a site has decided they are unwilling
to create a hole for Kerberos in their firewall that is presumably a
(possibly incorrect) security decision.  It is not appropriate for
application servers to be second guessing this security decision.
True, people could disable this SASL mechanism, but I think its real
benefit would be that it would tend to work around firewalls.

Ask yourself whether you think it would be appropriate to modify the
SPKM GSSAPI mechanism to support tunneling the public key path
validation protocol, etc, etc.

In general, I've been convinced of a need to tunnel Kerberos for
initial network access in EAP.  If EAP is to use GSS, then IAKerb
should advance.  If it is not and there is not another justification
for IAKerb then IAKerb should not advance.

If EAP is not going to use GSS, then it is reasonable for EAP to have
a Kerberos-specific tunnel.

But unless there is some similar use of SASL that justifies doing
something different, this mechanism should not advance.

If this mechanism is to be published, even as an information draft, it
should gain an applicability statement clearly indicating when GSS
should be used and when this mechanism should be used.

-
--Sam