Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name

From: Ken Murchison <[email-masked]>
Date: Wed, 02 Jan 2002 10:55:00 -0500

"Raif S. Naffah" wrote:
> 
> hello Ken,
> 
> At 11:17 AM 12/7/01 -0500, Ken Murchison wrote:
> 
> >Keith, Raif,
> >
> >What is the expected behavior of an implementation with respect to MDA
> >names?  Can we only support the "standard ASCII name" as defined by
> >[SCAN], or should we also support all of the aliases for each MDA?  In
> >either case, should the same rule(s) apply to the integrity layers?...
> 
> i'm not sure we can fully answer this question right now! this is because
> it will depend on how SASL-SRP, and other similar "generic" mechanisms will
> be registered with IANA.
> 
> currently it was customary for a mechanism, described in a draft/RFC to
> have one name.  SASL-SRP and others --eg. SM2-- describe a family of
> concrete mechanisms, the name of which, in SASL-SRP's case, is dependant on
> the name of the underlying hash function.
> 
> this in a way is similar to the situation that faces the TLS WG: when they
> want to add support for new ciphersuites, they cannot allocate the final
> identifiers, unless/until the proposed suite(s) are approved.
> 
> there are different alternatives to answer this question, none of which is
> perfect.  assuming that such a generic mechanism, say SASL-SRP, becomes an RFC:
> 
> 1. include in the RFC in an appendix, the 'current' list of fully qualified
> mechanism names, including the names of the underlying hash algorithms (and
> the reference(s) to their specifications) --so the reader would know what
> abc hash algorithm will be called/used, and which
> version/specification/variant of that abc algorithm is meant by that
> name.  the full list that would get included would be discussed/presented
> on this list, and may be also cc-ed to the SAAG.
> 
> 2. separate the RFC into a "static" part and a "dynamic" one: eg. SRP SASL
> Mechanisms --Protocol, and SRP SASL Mechanisms --Algorithm Names and
> Specifications.  the latter may be an Informational document updated
> regularly or on an as-needed-basis.
> 
> (1) has the disadvantage of when amending the list of names+specifications,
> a new RFC has to be published to replace the previous one.
> 
> (2) the second diminishes the "status" of the "static" RFC by rendering it
> incomplete, though it offers the advantage of not requiring frequent
> updates (of the RFC part).
> 
> another alternative, say (3), would be to have the dynamic part an RFC in
> its own right, and use it for all SASL mechanisms that require such
> 'dynamic' information.

I see a couple of other options, both of which eliminate the need for
the hash function to be part of the mech name:

(4) select and standardize on a single hash function, ie SHA-1

(5) allow the hash function to be negotiated as part of the exchanges. 
Since the hash function isn't needed until the server calculates K, we
can can have either a C->S-> C or S->C->S round trip to negotiate it.
draft-ietf-tls-srp-01.txt does this with the client providing a list of
supported hashes for the server to select from.  I'd prefer for the
server to provide a list, or a single hash (as done in the the SASL OTP
challenge).

Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

---

From: "Raif S. Naffah" <[email-masked]>
Date: Thu, 03 Jan 2002 21:02:19 +1100

hello Ken,

At 10:55 AM 1/2/02 -0500, Ken Murchison wrote:

> > >names?...
> > be registered with IANA...
>
>the hash function to be part of the mech name:...
>
>(5) allow the hash function to be negotiated as part of the exchanges...

Keith and I discussed this and we agree that it is worth incorporating in 
the next release of the draft.  we believe we dont need to add any 
additional roundtrip for negotiating the hash, instead this can be done in 
the L (server options) / o (client selection) exchange.

thank you for your comments + cheers;
rsn

---

From: Ken Murchison <[email-masked]>
Date: Thu, 03 Jan 2002 09:48:48 -0500

> the L (server options) / o (client selection) exchange.

Agreed.  Will this be something along the lines of the integrity option,
where if not specified, SHA-1 is the implied underlying hash?

Are either of you involved in the SRP TLS effort?  Any idea why they
have the client presenting the hash options instead of the server?

Ken

---

From: [email-masked]
Date: Thu, 3 Jan 2002 18:13:46 +0200

Quoting Ken Murchison <[email-masked]>:

> > additional roundtrip for negotiating the hash, instead this can be done
> in the L (server options) / o (client selection) exchange.
> 

SHA-1 will not be implied. It will be MANDATORY for the server to advertise
support for SHA-1, so that we can ensure interoperability between different
clients and servers. The server can then list any other digest algorithms it
supports.

> have the client presenting the hash options instead of the server?

I'm not involved with this effort.

> Ken

  - Keith

---

From: "Raif S. Naffah" <[email-masked]>
Date: Fri, 04 Jan 2002 06:08:00 +1100

>where if not specified, SHA-1 is the implied underlying hash?

Keith has already answered this one, and that concludes the SASL-SRP 
mechanism name.

the thread initiated by your original question about "naming" still 
remains, and i would like us to discuss it further in this group if there's 
benefit.  Alexey? Kurt?

cheers;
rsn

---

From: Ken Murchison <[email-masked]>
Date: Sat, 05 Jan 2002 23:44:49 -0500

> the L (server options) / o (client selection) exchange.

Just a heads up...

I've started to implement this behavior in CMU SASL, and have realized
why the TLS folks decided to have the client send its list of supported
MDAs -- it simplifies the server-side implementation.

If the client supplies its list of supported MDAs and the same time as
'U', then the server can do a lookup of a verifier for 'U' coresponding
to one of the provided MDAs.  So the lookup and selection of the MDA
happens in one step.

If the server provides the list (and the server is only storing
verifiers), then when it receives 'U' from the client, it must lookup
all available verifiers for this user and build the list of MDAs from
the retrieved verifiers (not knowing which will be used yet).  Once the
MDA is selected by the client, the server can then grab the correct
verifier (either by another lookup, or using the cached copy).

There are two ways that the server can simply the latter process:

1. It supports only one MDA (all verifiers use the same hash, like OTP
via OPIE) so that it always knows what the MDA is and will be
(essentially no negotiation).

2. It stores plaintext (or equivalent) passwords so that it can
calculate the verifier on the fly and easily handle multiple MDAs.

Its late and I may not be making much sense, so I can try to clarify
further if necessary.

Ken

---

From: [email-masked]
Date: Sun, 6 Jan 2002 13:01:48 +0200

> to one of the provided MDAs.  So the lookup and selection of the MDA

Assuming that the server doesn't know what MDAs are supported for the client, it
can't just do a lookup based on one of the provided MDAs (other than SHA-1). It
may try each of the MDAs in the client's list, and if the client provides a long
list (say every MDA available from the library it is using) this may require
several lookups on the server. Alternatively, the server could lookup all
available verifiers for this user and go through the list of MDAs from the
retrieved verifiers until it finds one it can use. But this is the same as
described below.

> verifier (either by another lookup, or using the cached copy).

As you noted, this is the case if the server is only storing verifiers. It can
of course also store the list of MDAs associated with each user, thereby making
it unnecessary to retrieve all the verifiers. It would also make the case where
the client sends the list easier too. In both cases, the server needs to know
what MDAs it supports for each user.

I agree that with the client providing the list, the lookup and selection on the
server occur in one step and with the server providing the list, the lookup and
selection on the server are separate steps. I think that the former is probably
easier to implement because the  process is in one step, not because the process
is all that different or more efficient.

> (essentially no negotiation).

I expect that this will be the common case. Most servers will just have
SHA-1-based verifiers. I think this is perfectly acceptable since they will be
able to interoperate with all clients. Using a different MDA may be due to the
discovery of a super-quick new MDA or more likely to comply with some policy
(government, corporate, organisational etc.).

> calculate the verifier on the fly and easily handle multiple MDAs.

Ugh! Not having plaintext-equivalent passwords on the server is one of the
primary benefits of SRP. :-)

> Its late and I may not be making much sense, so I can try to clarify

You're making sense. Having the client send the list of MDAs it is prepared to
use makes it easier to implement the server since the lookup of supported MDAs
and selection of the MDA to use occurs in one step. There will always be
interoperability, since the client will have to include SHA-1 in the list it
provides.

To me this looks like a good change, but we will have to see whether there are
other consequences.

Thanks for the heads-up.

  - Keith

---

From: Ken Murchison <[email-masked]>
Date: Sun, 06 Jan 2002 09:19:29 -0500

> Quoting Ken Murchison <[email-masked]>:

[...]

> >
> > There are two ways that the server can simplify the latter process:
> >

If you expect this to be the case, why even offer more than one MDA? 
Just stipulate that SRP uses SHA-1, and if a superior MDA comes along
down the road, then a SRP-FOO SASL mech can be written up.  Hmm, now I'm
backtracking...

> To me this looks like a good change, but we will have to see whether there are

I'm still not a big fan of having the client provide the list, even
though it does simplify things for the server.  I'm used to erroring on
the side of putting the complexity into the server, like IMAP.  I'm
curious what other folks think since this has only been a three person
discussion so far.

Ken

---

From: [email-masked]
Date: Sun, 6 Jan 2002 17:56:16 +0200

> down the road, then a SRP-FOO SASL mech can be written up.  Hmm, now I'm

SRP allows you to use any MDA (with certain requirements - see section 3.2 of
RFC2945), so the SASL mechanism that uses it shouldn't be more restrictive.
We're also trying to make the mechanism as future-proof as possible and making
it dependant on a single MDA makes it less so. We're aiming for flexible (use
any algorithm) and practical (have mandatory algorithms for simplicity and
interoperability).

> curious what other folks think since this has only been a three person

In the simplest case where the client provides a list of MDAs, the client need
only specify SHA-1in the list it provides, which can be hardcoded. Where the
server provides a list of MDAs, the client need only specify SHA-1 without
needing to look at the list since it is guaranteed to be there. Both simple
cases are not complex to implement on the client.

Whichever way we do it, the client will need to be configured to use the default
MDA or specify the MDA(s) it should use.

I agree that we should try to put most of the complexity on the server, but
which is more complex for the client: choosing from a list of MDAs or providing
a list of acceptable MDAs?

I'm happy with either option and I'd also be interested in other people's views.

  - Keith

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 06 Jan 2002 08:26:05 -0800

>cases are not complex to implement on the client.

This may not have a significant impact on this issue, but
I'd like to point out that "mandatory to implement" does
not imply "mandatory to use".  That is, while an implementation
must be capable of support the mandatory to implement hash,
the deploy may choose to disable it.

Kurt

---

From: [email-masked]
Date: Sun, 6 Jan 2002 19:19:12 +0200

> the deploy may choose to disable it.

According to the current draft, mandatory means "mandatory to advertise", so to
be compliant a server would have to advertise support for the hash.

  - Keith

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 06 Jan 2002 09:38:48 -0800

>be compliant a server would have to advertise support for the hash.

That seems quite odd.  I suggest I-D be modified not such
that the mandatory to implement hash is not mandatory to use
and hence not mandatory to advertise.

---

From: [email-masked]
Date: Sun, 6 Jan 2002 19:41:16 +0200

Quoting [email-masked]:
> which is more complex for the client: choosing from a list of MDAs or
> providing a list of acceptable MDAs?

To answer my own question. I think you're right Ken. The client already has to
be able to choose from a list to be able to select integrity and confidentiality
algorithms, so choosing from a list of MDAs is probably less complex for the
client. So, we should go with the server sending the list of MDAs?

I talk too much.

  - Keith

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Sun, 6 Jan 2002 09:44:57 -0800 (PST)

On Sun, 6 Jan 2002 [email-masked] wrote:

> According to the current draft, mandatory means "mandatory to
> advertise", so to be compliant a server would have to advertise
> support for the hash.

This is inappropriate for a document specifying a protocol.  In general,
IETF protocol standards tell software implementors what they have to do,
not system deployers.  This is especially true of something like a SASL
mechanism that may be used in many different scenarios.  The only time
IETF docs constrain deployments is in those services that are fundamental
to Internet infrastructure, like DNS and SMTP-based mail transfer.

 - RL "Bob"

---

From: [email-masked]
Date: Sun, 6 Jan 2002 19:50:18 +0200

> and hence not mandatory to advertise.

How do we guarantee interoperability then? IMO if a client only supports the
mandatory algorithm, it should be able to talk to any server.

  - Keith

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Sun, 6 Jan 2002 10:05:34 -0800 (PST)

On Sun, 6 Jan 2002 [email-masked] wrote:

> How do we guarantee interoperability then? IMO if a client only
> supports the mandatory algorithm, it should be able to talk to any
> server.

Since, as I noted in my previous message, an IETF protocol standard only
tells software developers what to do, the only interoperability guarantee
that is made is between implementations, not between deployments.  That
is, the standard should be written so that if we each obtain a compliant
implementation, we should be able to get them to interoperate by choosing
to use the mandatory-to-implement features; this is among many other
things we'd have to do to actually interoperate in practice, like have
connectivity and share passwords etc.  A protocol standard can't force my
deployment to interoperate with yours if I don't want it to.

 - RL "Bob"

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 06 Jan 2002 10:09:36 -0800

>and hence not mandatory to advertise.

For clarify, I meant:

I suggest the I-D be modified such that the hash is mandatory
to implement but not mandatory to use, hence not mandatory to
advertise.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 06 Jan 2002 10:15:39 -0800

>mandatory algorithm, it should be able to talk to any server.

You don't guarantee interoperability, you allow it.  That is,
because both applications must support the mandatory to implement
algorithm, they can interoperate.  However, a deployer is free
disable the mandatory to implement algorithm.

Kurt

---

From: Lawrence Greenfield <[email-masked]>
Date: Mon, 7 Jan 2002 00:05:09 -0500

Date: Sun,  6 Jan 2002 17:56:16 +0200
   From: [email-masked]
[...]
   > down the road, then a SRP-FOO SASL mech can be written up.  Hmm, now I'm

   SRP allows you to use any MDA (with certain requirements - see
   section 3.2 of RFC2945), so the SASL mechanism that uses it
   shouldn't be more restrictive.  We're also trying to make the
   mechanism as future-proof as possible and making it dependant on a
   single MDA makes it less so. We're aiming for flexible (use any
   algorithm) and practical (have mandatory algorithms for simplicity
   and interoperability).

I don't understand this flexibility.  If a security flaw comes up with
the single MDA chosen, we issue a new draft and all implementors
must rewrite their code.  If a security flaw comes up with the
mandatory-to-implement MDA, we _still_ have to write a new draft and
implementors still have to update their code.

If there's a large clamor for another MDA, a new SASL mechanism can
easily be written up and deployed at equivalent cost to adding an MDA
to an existing mechanism, and we don't get into these sub-SASL
negotiation problems.

Larry

---

From: [email-masked]
Date: Mon, 7 Jan 2002 13:50:17 +0200

> deployment to interoperate with yours if I don't want it to.

Okay. So we can ensure that implementations CAN interoperate, but we can't
ensure that they WILL in practice. I suppose that sounds fair enough. Thanks for
taking the time to clarify this.

  - Keith

---

From: [email-masked]
Date: Mon, 7 Jan 2002 22:02:40 +0200

> to an existing mechanism, and we don't get into these sub-SASL

What we are allowing with this flexibility is for a server to use any MDA it
chooses as the underlying MDA for all operations.  If the existing mechanism
already supports more than one MDA then it is easier for deployers to switch to
another MDA when the one they are using is found to be flawed.

If we say that an implementation may use any underlying MDA them some
implementations will provide support for more than one MDA.  These
implementations won't have to be rewritten if one MDA breaks.  If we say that
only a single MDA may be used then no implementations will support a different
MDA.  Then all these implementations will have to be rewritten if this MDA breaks.

I agree that if the mandatory-to-implement MDA breaks we will have to update the
specification, but at least in some cases implementations will not need to be
updated, since some of them will support the new mandatory-to-implement MDA
already, since they will have the flexibility to do so.

In the end, the negotiation of the MDA is quite simple. There are just various
ways of doing this and we're trying to decide on the best one, which appears to
be to have the server decide.

  - Keith

---

From: Ken Murchison <[email-masked]>
Date: Mon, 07 Jan 2002 16:52:16 -0500

> be to have the server decide.

To simplify things further, why don't we take the SASL OTP (RFC2444)
approach.  OTP supports multiple MDAs, but the server only spits out the
one that is/was used for the user's secret.  This makes the
lookup/selection for the server trivial.  On the client side, its either
take it or leave it.  This puts more burden on the client side, in that
it should be able to support as many of the probable MDAs in use by the
servers, but this shouldn't be a showstopper.  This provides the
framework that you are looking for (ability to support multiple MDAs),
but also simplifies the implementation of such.

My guess would be that most initial implementations would be based on
SHA-1 (the MUST be supported algorithm), just like most OTP
implementations are based on MD5.

Ken

---

From: [email-masked]
Date: Tue, 8 Jan 2002 18:49:36 +0200

Quoting Ken Murchison <[email-masked]>:
> > In the end, the negotiation of the MDA is quite simple. There are just
> > various ways of doing this and we're trying to decide on the best one, 
> > which appears to be to have the server decide.
> 

Agreed. This is in fact what I meant by "have the server decide", since that's
what Raif and I came up with during our discussions. I'm glad to see that there
is some precendent for this. Are others agreed that this is the way to go?
 
> implementations are based on MD5.

Agreed.

  - Keith

---

From: Ken Murchison <[email-masked]>
Date: Tue, 08 Jan 2002 14:26:15 -0500

> > implementations are based on MD5.

So you that the server select a single MDA tell the client what that MDA
is, and not provide a list?  That was my main point.

Ken

---

From: [email-masked]
Date: Tue, 8 Jan 2002 22:05:54 +0200

> is, and not provide a list?  That was my main point.

Yes, you made the point much more clearly that I did. I apologise if it seemed
that I was attempting to take credit away from you.

This is what we currently have:

  "mda=<message digest algorithm name>" indicates that the specified
   algorithm MUST be used as the underlying Message Digest Algorithm for 
   all SRP calculations - to compute both client-side and server-side digests.
   This option is only sent once by the server and the specified algorithm MUST
   meet the requirements specified in section 3.2 of [RFC-2945]:

      "Any hash function used with SRP should produce an output of at
       least 16 bytes and have the property that small changes in the input
       cause significant nonlinear changes in the output."

  Note that in the interests of interoperability with client implementations and
other
  SRP-based tools, the server MUST support SHA-160 as an underlying Message
  Digest Algorithm. While the server is not required to use SHA-160 as the
  underlying Message Digest Algorithm, it must be able to do so.

  - Keith

---

From: Ken Murchison <[email-masked]>
Date: Tue, 08 Jan 2002 15:09:02 -0500

> is, and not provide a list?  That was my main point.

I meant to say, "So you agree that...".

However if you want to leave it so that the server CAN list multiple
MDAs, nothing precludes an implementation from only listing one if it
simplifies the implementation

Ken

---

From: Ken Murchison <[email-masked]>
Date: Tue, 08 Jan 2002 16:28:32 -0500

> that I was attempting to take credit away from you.

Nope.  I didn't feel that way at all.

>   underlying Message Digest Algorithm, it must be able to do so.

Great!  Some preview text.  This goes back to the start of this thread,
but do you plan on going with SHA-160, SHA-1 or SHA1.  I'm in favor of
SHA-1 since that seems to be the proper name and the others are aliases.

Also, do you plan to have the client send { utf8(U) | utf8(I) } or {
utf8(I) | utf8(U) }.  FWIW, PLAIN and OTP use the latter.  DIGEST-MD5
uses the former but there is also a lot of other options wedged in
between.

Ken

---

From: [email-masked]
Date: Wed, 9 Jan 2002 15:24:46 +0200

> simplifies the implementation

This is a valid point.

There was a miscommunication from my part. Raif actually suggested that we have
the server send a list of MDAs and have the client choose one from the list.  I
suggested that the server choose the MDA and tell the client, as I posted to
this list earlier, thinking Raif agreed, which he didn't.

I'd like what I expect to be the common case to be simple, but as you rightly
point out, the server achieves the same effect by only sending a single MDA
option. So, I'm happy to go along with having the server send a list of MDAs and
have the client choose one from the list.

  - Keith

---

From: Ken Murchison <[email-masked]>
Date: Wed, 02 Jan 2002 10:55:00 -0500

Ken

---

From: "Raif S. Naffah" <[email-masked]>
Date: Thu, 03 Jan 2002 21:02:19 +1100

hello Ken,

---

From: Ken Murchison <[email-masked]>
Date: Thu, 03 Jan 2002 09:48:48 -0500

Ken

---

From: [email-masked]
Date: Thu, 3 Jan 2002 18:13:46 +0200

- Keith

---

From: "Raif S. Naffah" <[email-masked]>
Date: Fri, 04 Jan 2002 06:08:00 +1100

cheers;
rsn

---

From: Ken Murchison <[email-masked]>
Date: Sat, 05 Jan 2002 23:44:49 -0500

Just a heads up...

Ken

---

From: [email-masked]
Date: Sun, 6 Jan 2002 13:01:48 +0200

Thanks for the heads-up.

  - Keith

---

From: Ken Murchison <[email-masked]>
Date: Sun, 06 Jan 2002 09:19:29 -0500

[...]

Ken

---

From: [email-masked]
Date: Sun, 6 Jan 2002 17:56:16 +0200

- Keith

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 06 Jan 2002 08:26:05 -0800

Kurt

---

From: [email-masked]
Date: Sun, 6 Jan 2002 19:19:12 +0200

- Keith

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 06 Jan 2002 09:38:48 -0800

---

From: [email-masked]
Date: Sun, 6 Jan 2002 19:41:16 +0200

I talk too much.

  - Keith

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Sun, 6 Jan 2002 09:44:57 -0800 (PST)

- RL "Bob"

---

From: [email-masked]
Date: Sun, 6 Jan 2002 19:50:18 +0200

- Keith

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Sun, 6 Jan 2002 10:05:34 -0800 (PST)

- RL "Bob"

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 06 Jan 2002 10:09:36 -0800

For clarify, I meant:

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 06 Jan 2002 10:15:39 -0800

Kurt

---

From: Lawrence Greenfield <[email-masked]>
Date: Mon, 7 Jan 2002 00:05:09 -0500

Larry

---

From: [email-masked]
Date: Mon, 7 Jan 2002 13:50:17 +0200

- Keith

---

From: [email-masked]
Date: Mon, 7 Jan 2002 22:02:40 +0200

- Keith

---

From: Ken Murchison <[email-masked]>
Date: Mon, 07 Jan 2002 16:52:16 -0500

Ken

---

From: [email-masked]
Date: Tue, 8 Jan 2002 18:49:36 +0200

Agreed.

  - Keith

---

From: Ken Murchison <[email-masked]>
Date: Tue, 08 Jan 2002 14:26:15 -0500

Ken

---

From: [email-masked]
Date: Tue, 8 Jan 2002 22:05:54 +0200

- Keith

---

From: Ken Murchison <[email-masked]>
Date: Tue, 08 Jan 2002 15:09:02 -0500

Ken

---

From: Ken Murchison <[email-masked]>
Date: Tue, 08 Jan 2002 16:28:32 -0500

Ken

---

From: [email-masked]
Date: Wed, 9 Jan 2002 15:24:46 +0200

This is a valid point.

  - Keith