Subject: draft-ietf-sasl-crammd5-02 / additional mechanisms ?

From: Tino Reichardt <[email-masked]>
Date: Thu, 8 Apr 2004 12:26:01 +0200

Hello ietf-sasl list.

First of all: my english isn't the best and I am new to this list.

I think the draft 'The CRAM-MD5 SASL Mechanism' should not only
specify the CRAM-MD5 mechanism.
Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar
and then specify also some other standard hash routines as SASL CRAM
mechanisms:

: CRAM-MD5
160bit: CRAM-SHA1
160bit: CRAM-RIPEMD-160
320bit: CRAM-RIPEMD-320

ps: The CRAM-SHA1 mechanism is already used by serveral servers and
    clients.

references:

[SHA1]   http://www.itl.nist.gov/fipspubs/fip180-1.htm
[RIPEMD] http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html

-- 
regards, TR

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 08 Apr 2004 16:43:33 +0100

>and then specify also some other standard hash routines as SASL CRAM
I am afraid documenting those is outside of the scope for this working 
group.
However you can contact me offline if you want to document this/help out 
to document this.

>[RIPEMD] http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html
Regards,
Alexey
__________________________________________
Isode Limited, http://www.isode.com

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html

Personal Home Page: http://www.melnikov.ca
__________________________________________

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 08 Apr 2004 23:22:28 +0200

> and then specify also some other standard hash routines as SASL CRAM

For what it's worth, I'm not convinced this is a good idea.  Unless
there is something wrong with the authentication part of CRAM-MD5, it
would only decrease interoperability if variations were added.
Especially considering that a stored, non-plain, password database is
not compatible across hash functions.

Further, I dislike SASL mechanism families.  This also applies to the
new GSS-API mechanisms.  It is a change compared to 2222, and it makes
the generic parts of a SASL library needlessly complicated (think
dynamically loading the proper SASL module based on SASL mechanism
name).

Still, nothing prevents you from register CRAM-SHA1 at IANA, write
your own specification, and using it.  But, to re-iterate, I believe
it isn't useful to change the current CRAM-MD5 document into a CRAM-*
family.  If you need a SASL mechanism that can use other hashes, have
a look at GSS-*, or perhaps KERBEROS_V5.

> ps: The CRAM-SHA1 mechanism is already used by serveral servers and

Do you have any pointers?

Thanks,
Simon

---

From: Tino Reichardt <[email-masked]>
Date: Fri, 9 Apr 2004 09:38:08 +0200

> not compatible across hash functions.
This is true ... can you tell me applications where contexts are
stored ?

> dynamically loading the proper SASL module based on SASL mechanism
Do you think on a special application ? Who loads what dynamically ?
Adding SHA1 + RIPEMD hash algorithms to an application isn't very
complex... just see [QPASSWD].

> a look at GSS-*, or perhaps KERBEROS_V5.
Okay, we need for every good hash a good draft ?

> Do you have any pointers?
Not much, but since it isn't mentioned in any standard:

Hamster SMTP+POP3+NNTP Server/Client:
http://www.tglsoft.de/misc/hamster_en.htm

Cone Mail Client:
http://www.courier-mta.org/cone/cone00index.html

Radius Server:
http://www.freeradius.org
(http://www.freeradius.org/radiusd/doc/ChangeLog)

also:
- courier-imapd
- postfix

[QPASSWD] http://www.mcmilk.de/projects/qpasswd/

-- 
regards, TR

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 09 Apr 2004 12:54:05 +0200

> This is true ... can you tell me applications where contexts are

I believe Cyrus SASL has a mode in which it doesn't store plain-text
passwords, only mechanism specific contexts.  I'm sure other
implementations can do the same.

> complex... just see [QPASSWD].

This was a generic comment, not specific to CRAM-*.  Adding code for
SHA1/RIPEMD is easy, I agree.

But the code that selects the proper module to implement a specific
SASL mechanism, based on a family name, will be more complicated than
it was in 2222.  To use GSS as an example (since there is a
specification for it, so we can get into details), to be flexible the
SASL library would have to recognize the "GSS-" prefix, and load
e.g. libgsasl-gss.so, which in turn loads the GSS implementation,
iterates over all supported GSS mechanisms (which can change over
time, without the SASL library knowing about it), compute the
truncated MD5 and check whether it match the GSS-<B32DATA> string.
Compare this to the 2222 approach, where you load (e.g.)
libgsasl-<SASLMECHANISMNAME>.so and that's it.

One idea for solving this problem would be to make the SASL mechanism
family matter purely an IETF/IANA procedural matter, and not an
intrinsic part of the SASL protocol.  I mean, the GSS SASL mechanism
should not imply that an implementation should go through the above
procedure in order to find the proper GSS mechanism to use, but that
each GSS mechanism to be used within SASL is registered as such, using
the truncated MD5 as the registered name, and only after that should
SASL implementations be assumed to recognize it automatically.  (Of
course, we can't stop implementations from recognizing non-standard
SASL mechanisms, perhaps by implementing the above algorithm.)

> Okay, we need for every good hash a good draft ?

Yes.  Or, if 2222bis is approved with SASL mechanism families, you can
write a document for the entire CRAM-* family, if you make sure it
doesn't collide with CRAM-MD5.

> [QPASSWD] http://www.mcmilk.de/projects/qpasswd/

It appears as if a document describing CRAM-SHA1 would be a useful
contribution.  You can add a link to it on the IANA SASL page.

Regards,
Simon

---

From: Tino Reichardt <[email-masked]>
Date: Fri, 9 Apr 2004 19:45:34 +0200

> implementations can do the same.
Okay, but for SMTP + POP3 servers doesn't that matter, because the
initial server response differs every time ...
So storing contexts here, makes no sense. As far as I know - Maybe I
am on the wrong track :)

> libgsasl-<SASLMECHANISMNAME>.so and that's it.

The applications should just load what they need to support some
special typ of SASL mechanism. But such a implementation can't be the
reason for not specifying new mechanisms.
They have to load for every new SASL mechanism another library, when
it doesn't work another way.  Maybe the concept of those
implementations is wrong, because when I want to by a car, I don't
choose the tires first and then the car, which has to fit to them.

> SASL mechanisms, perhaps by implementing the above algorithm.)

Hm...

> doesn't collide with CRAM-MD5.

HMAC-SHA1 and HMAC-RIPEMD is also spcified in rfc 2104. So why
shouldn't CRAM-SHA1 + CRAM-RIPEMD be mentioned in a new CRAM-MD5 rfc ?
Maybe the name isn't the best one than - okay :)

> contribution.  You can add a link to it on the IANA SASL page.
Who?

-- 
regards, TR

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 09 Apr 2004 11:41:52 -0700

Tino,

The WG CRAM-MD5 work item is limited to revising the SASL CRAM-MD5
authentication mechanism.  Engineering of other CRAM-based
mechanisms is simply beyond the scope of the working group.  I
suggest you pursue the specification of other mechanisms on an
individual basis.

I do not that this list is an acceptable forum for review of
SASL-related submissions produced by individuals (as long as
such review does not impede progress on WG deliverables).

Regards, Kurt (as co-chair of the SASL-WG)

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 09 Apr 2004 22:37:33 +0200

> reason for not specifying new mechanisms.

Right, the argument was a reason for not introducing SASL mechanism
families at all, at least not as a protocol matter, in 2222bis.  Don't
take it as criticism of your idea specifically, it wasn't meant as
such.  Your idea just made me think of the general topic of SASL
mechanism families.

> Maybe the name isn't the best one than - okay :)

As Kurt Zeilenga said, the agenda for CRAM-MD5 is rather limited.
Delaying it further because it can be generalized, does not sound like
a good idea to me.  This doesn't mean you can't work on CRAM-* in
parallel though, and since you quoted existing software that uses it,
having it documented and registered with IANA would be a good idea.
The document for CRAM-* could begin by explaining what the technical
motivations for developing it was.  At least I'm curious about that.
(Don't you trust MD5?  Is the code size of MD5 too large?  Etc.)

>> contribution.  You can add a link to it on the IANA SASL page.

See http://www.iana.org/assignments/sasl-mechanisms

Regards,
Simon

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 09 Apr 2004 13:53:39 -0700

At 03:54 AM 4/9/2004, Simon Josefsson wrote:
>intrinsic part of the SASL protocol. 

It should be clear in the revised SASL base specification,
if not already so, that families of mechanisms is purely a
name space matter.  To the protocol, each name/mechanism
is independent of all other name/mechanism pairs.

Kurt

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 08 Apr 2004 16:43:33 +0100

Regards,
Alexey

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 08 Apr 2004 23:22:28 +0200

Thanks,
Simon

---

From: Tino Reichardt <[email-masked]>
Date: Fri, 9 Apr 2004 09:38:08 +0200

Cone Mail Client:

Radius Server:

also:
- courier-imapd
- postfix

-- 
regards, TR

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 09 Apr 2004 12:54:05 +0200

Regards,
Simon

---

From: Tino Reichardt <[email-masked]>
Date: Fri, 9 Apr 2004 19:45:34 +0200

Hm...

Who?

-- 
regards, TR

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 09 Apr 2004 11:41:52 -0700

Tino,

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 09 Apr 2004 22:37:33 +0200

Regards,
Simon

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 09 Apr 2004 13:53:39 -0700

Kurt