Subject: Re: SRP CP/IP/RD options

From: "Raif S. Naffah" <[email-masked]>
Date: Wed, 30 Jan 2002 21:00:36 +1100

At 02:44 PM 1/22/02 -0800, Kurt D. Zeilenga wrote:
>At 10:08 AM 2002-01-22, Lawrence Greenfield wrote:
> >I'd at least like to see a strong recommendation in the document that
> >security be accompanied by integrity, but I guess I'd like to see an
> >example of a real world SASL using application that _needs_
> >confidentiality without integrity.
>
>Personally, it seems quite pointless to go through the expense
>of SRP and then to through away its value by not using
>providing replay/integrity protection for the stream.  For
>non-Internet applications, I can see where no-replay/no-integrity
>might be appropriate. But, for the Internet, both SHOULD be
>used (regardless of confidentiality protection).

as per the latest discussion, the SRP mechanism now offers a security layer 
with IP (Integrity) and CP (Confidentiality), independantly settable; i.e.

       CP   IP   Peer sends/receives

       I    I    { eos(p) }
       I    A    { eos(p) | os( IALG(K)( bytes(p) | bytes(q)) ) }
       A    I    { eos(c) }
       A    A    { eos(c) | os( IALG(K)((bytes(c) | bytes(q)) ) }

as we understand it, the discussion is now whether to allow the first 
option or not as a valid combination.

what feature to activate and when to do so is the responsibility of the 
user.  there's nothing inherently insecure about each individual 
combination.  in all of them, the mechanism has achieved its first 
objective which is authentication of the client, and depending on the 
selected feature, authentication of the server as well.

if the user is willing to assume that, among other factors, the risk of 
session hijacking is minimal and high speed is important, then the first 
combination is a solution.

we agree that a security layer with integrity protection should be the 
default configuration.  we therefore will state, in the next draft, that at 
least one integrity algorithm MUST be offered by the server and that 
integrity protection SHOULD be chosen by the client.

thank you for your comments + cheers;
Keith + Raif

---

From: Lawrence Greenfield <[email-masked]>
Date: Wed, 30 Jan 2002 12:58:21 -0500

Date: Wed, 30 Jan 2002 21:00:36 +1100
   From: "Raif S. Naffah" <[email-masked]>
[...]
   as per the latest discussion, the SRP mechanism now offers a security layer 
   with IP (Integrity) and CP (Confidentiality), independantly settable; i.e.

	  I    I    { eos(p) }

Actually, I disagree with this option:
	  A    I    { eos(c) }

The first option is fine.  I think it's silly, but I doubt people
would misuse it.  I'd like an example of a real application that would
want SRP authentication, want encryption, but not want integrity.
I think supplying encryption without integrity is asking for people to
use it wrong.  I think our library will refuse to negotiate that
mode.

If you're willing to pay for SRP, pay for encryption, is it really
that burdensome to do a hash algorithm?

Larry

---

From: "Raif S. Naffah" <[email-masked]>
Date: Thu, 31 Jan 2002 05:34:05 +1100

At 12:58 PM 1/30/02 -0500, Lawrence Greenfield wrote:
>...I'd like an example of a real application that would
>use it wrong...

i dont have an axample but i would appreciate it if you can provide 
references that prove that using encryption without integrity _within a 
protocol that authenticate both ends_ is a security weakness or is open to 
attacks.

>that burdensome to do a hash algorithm?

adding integrity protection implies adding between 16 to 64 bytes to each 
SASL buffer, depending on the HMAC's underlying hash function (eg. 128-bit 
MD5 and 512-bit Whirlpool).  this is a cost that an architect may consider 
prohibitive in some applications.

cheers;
rsn

---

From: Lawrence Greenfield <[email-masked]>
Date: Wed, 30 Jan 2002 13:39:45 -0500

Date: Thu, 31 Jan 2002 05:34:05 +1100
   From: "Raif S. Naffah" <[email-masked]>
[...]

Sure, without integrity protection I can modify arbitrary data to be
random.  Here's a stupid but possible example: I modify the envelope
in an SMTP exchange, causing a bounce message that goes over the
clear, allowing me to see the headers of the message (even if the
message is end-to-end protected using S/MIME).

I guess I'm having trouble envisioning an application where the 4-byte
sasl-blob-length is acceptable but a 16 byte hash isn't.

Larry

---

From: "Raif S. Naffah" <[email-masked]>
Date: Thu, 31 Jan 2002 05:45:46 +1100

>message is end-to-end protected using S/MIME).

and how integrity protection allows you to work around that?

cheers;
rsn

---

From: Lawrence Greenfield <[email-masked]>
Date: Wed, 30 Jan 2002 13:49:10 -0500

Date: Thu, 31 Jan 2002 05:45:46 +1100
   From: "Raif S. Naffah" <[email-masked]>

With integrity protection, the server isn't able to decode the sasl
blob that got modified.  The connection is therefore dropped and the
message is never sent (and therefore never bounced).

Without integrity protection, neither the client nor the server have
any idea that the data was changed in transit.

Larry

---

From: Lawrence Greenfield <[email-masked]>
Date: Wed, 30 Jan 2002 14:32:02 -0500

Please reread my example.  My imaginary attack depends only on needing
to corrupt data at a certain location in the protocol (but SMTP is
highly predictable).  I also don't corrupt the headers but the SMTP
envelope (part of the protocol).

I don't require the data to be at all comprehensible, merely
incorrect.

The example illustrates one way in which, lacking integrity, a
software system might breach confidentiality.

Larry

   Date: Wed, 30 Jan 2002 21:26:57 +0200
   From: [email-masked]

   > any idea that the data was changed in transit.

   You provide a good reason for always having integrity protection,
   which I definitely support. But, if the SMTP exchange is encrypted, 
   how do you modify the headers? Sure, you can corrupt the data,
   but the server is likely to notice.

   > Larry

     - Keith

---

From: [email-masked]
Date: Wed, 30 Jan 2002 21:26:57 +0200

- Keith

---

From: [email-masked]
Date: Wed, 30 Jan 2002 21:57:23 +0200

> envelope (part of the protocol).

The envelope is still under the security layer. Consider the following
SMTP example:

 S: 220 smtp.example.com ESMTP server ready
 C: EHLO zaau.example.com
 S: 250-smtp.example.com
 S: 250 AUTH SRP CRAM-MD5 DIGEST-MD5
 C: AUTH SRP AAAADAAEdGVzdAAEdGVzdA==
  ......
 S: 235 Authentication successful
 C: MAIL FROM: [email-masked]
 S: 250 [email-masked]... Sender ok
 C: RCPT TO: [email-masked]
 S: 250 [email-masked]... Recipient ok
 C: DATA
 S: 354 Enter mail, end with "." on a line by itself
 C: From: [email-masked]
 C: To: [email-masked]
 C: Subject: blah
 C:
 C: ook?
 C: .
 S: 250 Message accepted for delivery
 C: QUIT
 S: 221 Closing connection

After the "235 Authentication successful" everything goes through the
security layer. The envelope (RCPT TO) and the headers (in the DATA 
section) will be encrypted if that's what we negotiated as part of the 
security layer.

Also, RFC 2554 says:

  "If a security layer is negotiated through the SASL authentication 
   exchange, it takes effect immediately following the CRLF that 
   concludes the authentication exchange for the client, and the 
   CRLF of the success reply for the server. Upon a security layer's 
   taking effect, the SMTP protocol is reset to the initial state (the 
   state in SMTP after a server issues a 220 service ready greeting).  
   The server MUST discard any knowledge obtained from the client,
   such as the argument to the EHLO command, which was not 
   obtained from the SASL negotiation itself.

> software system might breach confidentiality.

If a security layer with encryption is active then this does not hold.

  - Keith

---

From: Lawrence Greenfield <[email-masked]>
Date: Wed, 30 Jan 2002 12:58:21 -0500

I    I    { eos(p) }

Larry

---

From: "Raif S. Naffah" <[email-masked]>
Date: Thu, 31 Jan 2002 05:34:05 +1100

cheers;
rsn

---

From: Lawrence Greenfield <[email-masked]>
Date: Wed, 30 Jan 2002 13:39:45 -0500

Larry

---

From: "Raif S. Naffah" <[email-masked]>
Date: Thu, 31 Jan 2002 05:45:46 +1100

cheers;
rsn

---

From: Lawrence Greenfield <[email-masked]>
Date: Wed, 30 Jan 2002 13:49:10 -0500

Larry

---

From: Lawrence Greenfield <[email-masked]>
Date: Wed, 30 Jan 2002 14:32:02 -0500

Larry

     - Keith

---

From: [email-masked]
Date: Wed, 30 Jan 2002 21:26:57 +0200

- Keith

---

From: [email-masked]
Date: Wed, 30 Jan 2002 21:57:23 +0200

Also, RFC 2554 says:

  - Keith

>    but the server is likely to notice.

Date: Wed, 30 Jan 2002 21:57:23 +0200
From: [email-masked]
To: Lawrence Greenfield <[email-masked]>
Cc: [email-masked], "Kurt D. Zeilenga" <[email-masked]>, "Raif S. Naffah" <[email-masked]>
Subject: Re: SRP CP/IP/RD options
Sender: [email-masked]

Also, RFC 2554 says:

  - Keith

>    but the server is likely to notice.

Date: Wed, 30 Jan 2002 14:32:02 -0500
From: Lawrence Greenfield <[email-masked]>
To: [email-masked]
Cc: [email-masked], "Kurt D. Zeilenga" <[email-masked]>, "Raif S. Naffah" <[email-masked]>
Subject: Re: SRP CP/IP/RD options
Sender: [email-masked]

Larry

     - Keith

Date: Wed, 30 Jan 2002 21:26:57 +0200
From: [email-masked]
To: Lawrence Greenfield <[email-masked]>
Cc: "Raif S. Naffah" <[email-masked]>, "Kurt D. Zeilenga" <[email-masked]>, [email-masked]
Subject: Re: SRP CP/IP/RD options
Sender: [email-masked]

  - Keith

Date: Wed, 30 Jan 2002 13:49:10 -0500
From: Lawrence Greenfield <[email-masked]>
To: "Raif S. Naffah" <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, [email-masked], Keith Burdis <[email-masked]>
Subject: Re: SRP CP/IP/RD options
Sender: [email-masked]

Larry

Date: Thu, 31 Jan 2002 05:45:46 +1100
To: Lawrence Greenfield <[email-masked]>
From: "Raif S. Naffah" <[email-masked]>
Subject: Re: SRP CP/IP/RD options
Cc: Keith Burdis <[email-masked]>, [email-masked], "Kurt D. Zeilenga" <[email-masked]>
Sender: [email-masked]

cheers;
rsn

Date: Wed, 30 Jan 2002 13:39:45 -0500
From: Lawrence Greenfield <[email-masked]>
To: "Raif S. Naffah" <[email-masked]>
Cc: Keith Burdis <[email-masked]>, [email-masked], "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: SRP CP/IP/RD options
Sender: [email-masked]

Larry

Date: Thu, 31 Jan 2002 05:34:05 +1100
To: Lawrence Greenfield <[email-masked]>
From: "Raif S. Naffah" <[email-masked]>
Subject: Re: SRP CP/IP/RD options
Cc: "Kurt D. Zeilenga" <[email-masked]>, [email-masked], Keith Burdis <[email-masked]>
Sender: [email-masked]

cheers;
rsn

Date: Wed, 30 Jan 2002 12:58:21 -0500
From: Lawrence Greenfield <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>, "Raif S. Naffah" <[email-masked]>
Cc: [email-masked], Keith Burdis <[email-masked]>
Subject: Re: SRP CP/IP/RD options
Sender: [email-masked]

	  I    I    { eos(p) }

Larry

Date: Wed, 30 Jan 2002 21:00:36 +1100
To: "Kurt D. Zeilenga" <[email-masked]>
From: "Raif S. Naffah" <[email-masked]>
Subject: Re: SRP CP/IP/RD options
Cc: Lawrence Greenfield <[email-masked]>, Keith Burdis <[email-masked]>, [email-masked]
Sender: [email-masked]

       I    I    { eos(p) }

Date: Tue, 22 Jan 2002 14:44:20 -0800
To: Lawrence Greenfield <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: SRP CP/IP/RD options
Cc: "Raif S. Naffah" <[email-masked]>, Keith Burdis <[email-masked]>, [email-masked]
Sender: [email-masked]

Kurt

Date: Tue, 22 Jan 2002 13:08:10 -0500
From: Lawrence Greenfield <[email-masked]>
To: "Raif S. Naffah" <[email-masked]>
Cc: Keith Burdis <[email-masked]>, [email-masked]
Subject: Re: SRP CP/IP/RD options
Sender: [email-masked]

   Date: Sun, 20 Jan 2002 10:24:56 +1100
   From: "Raif S. Naffah" <[email-masked]>
[...]
   We agree that integrity protection without replay detection is not that 
   useful. It also results in messages of the same size and adds little 
   processing overhead, so we will remove the "replay detection" option and 
   combine it with integrity protection, as suggested.

Good.

   However, we believe that there are some situations that justify
   confidentiality protection without integrity protection
   --e.g. short-lived confidential exchanges or applications concerned
   with the number of bits on the wire. If the recepient does not hold
   a valid session key, he/she will not be able to access the
   plaintext, so integrity protection is not strictly necessary.

It's not clear to me that application programmers will frequently make
the right choice on this.  We'll probably force the Cyrus SASL library
to always negotiate integrity if confidentiality is desired simply
because this is a genuine pain.

Remember, the first in SASL standards for "Simple"; let's try to keep
the mechanisms as simple as possible to use correctly.

Larry

Date: Sun, 20 Jan 2002 13:19:21 +0200
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: draft-burdis-cat-srp-sasl-06
Sender: [email-masked]

Greetings

A rather belated announcement that Raif and I released a new version of
the SRP SASL draft on 12 January. Below are the changes from the
previous draft:

   The underlying message digest algorithm for SRP calculations is now
   selected during an exchange between the server and client. Section
   4.2 and Section 4.3 have been amended to reflect this change.

   Changed "mechanisms" to "mechanism" in various places and fixed the
   mechanism name to "SRP."

   Removed "Mechanism Names" section, since it is no longer needed, and
   replaced with "Introduction."

   Changed the mechanism data exchanges in Section 4 so that the
   authorisation identity (I) is sent with the authentication identity
   (U).

   Added a new bullet point to Section 7.1 justifying the selection of
   SHA-160 as the MANDATORY Message Digest Algorithm for SRP
   calculations.

   Added a new paragraph to Section 8 giving Tom Wu's response to the
   SRP password-guessing attack pointed out by Robert Moskowitz.

   Added Ken Murchison to Section 9.

   Used "**" consistently as the symbol for the exponentiation operator.

   Re-ordered the references alphabetically.

Thanks to everyone who contributed to this revision.

 - Keith and Raif

Date: Sun, 20 Jan 2002 10:24:56 +1100
To: Lawrence Greenfield <[email-masked]>, Ken Murchison <[email-masked]>
From: "Raif S. Naffah" <[email-masked]>
Subject: Re: SRP CP/IP/RD options
Cc: [email-masked], Keith Burdis <[email-masked]>
Sender: [email-masked]

At 01:51 PM 1/15/02 -0500, Lawrence Greenfield wrote:

>I'm confused why there are options to negotiate encryption but not
>integrity, etc.  Is there some feature that's served by allowing
>people to negotiate somewhat nonsensical options?  Shouldn't we
>require replay detection if you're going through the trouble of
>integrity?  Shouldn't we require integrity protection if you're going
>through the trouble of encryption?...

Later, at 02:03 PM 1/17/02 -0500, Ken Murchison wrote:

 > ...I tend to agree with Larry...

We agree that integrity protection without replay detection is not that 
useful. It also results in messages of the same size and adds little 
processing overhead, so we will remove the "replay detection" option and 
combine it with integrity protection, as suggested.

However, we believe that there are some situations that justify 
confidentiality protection without integrity protection --e.g. short-lived 
confidential exchanges or applications concerned with the number of bits on 
the wire. If the recepient does not hold a valid session key, he/she will 
not be able to
access the plaintext, so integrity protection is not strictly necessary.

Keith + Raif

Date: Thu, 17 Jan 2002 14:03:15 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: [email-masked]
CC: Lawrence Greenfield <[email-masked]>, Keith Burdis <[email-masked]>, "Raif S. Naffah" <[email-masked]>
Subject: Re: SRP CP/IP/RD options
Sender: [email-masked]

Lawrence Greenfield wrote:
> 
> I'm confused why there are options to negotiate encryption but not
> integrity, etc.  Is there some feature that's served by allowing
> people to negotiate somewhat nonsensical options?  Shouldn't we
> require replay detection if you're going through the trouble of
> integrity?  Shouldn't we require integrity protection if you're going
> through the trouble of encryption?
> 
> I think there should be a substantial benefit to these options if
> they're going to be left in.  In my view, they'll just cause
> interoperability and testing headaches without serving any useful
> purpose.
> 
> I therefore propose that the chart in 5.4:
> 
>       CP   IP   RD   Peer sends/receives
> 
>       I    I    I    { eos(p) }
>       I    A    I    { eos(p) | os( IALG(K)( bytes(p) ) ) }
>       I    A    A    { eos(p) | os( IALG(K)( bytes(p) | bytes(q)) ) }
>       A    I    I    { eos(c) }
>       A    A    I    { eos(c) | os( IALG(K)( bytes(c) ) ) }
>       A    A    A    { eos(c) | os( IALG(K)((bytes(c) | bytes(q)) ) }
> 
> should be just:
> 
>       CP   IP   RD   Peer sends/receives
> 
>       I    I    I    { eos(p) }
>       I    A    A    { eos(p) | os( IALG(K)( bytes(p) | bytes(q)) ) }
>       A    A    A    { eos(c) | os( IALG(K)((bytes(c) | bytes(q)) ) }

Since I'm updating the CMU SASL implementation to draft -06, and would
like to make any other proposed changes at the same time, I thought I'd
try to spark this thread to see if we can get a resolution.

I tend to agree with Larry.

This scheme will greatly simplify implementations and reduce the amount
of option "chatter" in the exchanges.  The "reply detection" option can
go away, since it would always be done as part of integrity protection. 
Also, the server would only have to use either "mandatory=integrity" or
"mandatory=confidentiality" since "confidentiality" implies "integrity"
and "integrity" implies "replay detection".

FWIW, this same scheme is also used in DIGEST-MD5.

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

Date: Tue, 15 Jan 2002 12:11:17 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: [saag] Algorithm Naming
Cc: "Raif S. Naffah" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 1:34 PM +0200 1/15/02, [email-masked] wrote:
>Quoting Stephen Kent <[email-masked]>:
>
>>  A number of algorithms/modes are identified by OIDs, which are issued
>>  by various organizations under the overall ITU umbrella. I think IANA
>>  manages a tree arc for this purpose and we make use of it in several
>>  WGs already, e.g., S/MIME and PKIX. These WGs also make use of OIDs
>>  issued by other organizations (e.g., IEEE, RSA, NIST, DoD) who have
>>  arcs in the tree, to avoid duplication.
>
>This is an interesting idea. Are there unique names associated with 
>these OIDs?
>
>While OIDs themselves are unique, we don't want to have to use:
>
>   integrity=1.3.6.1.5.5.8.1.1
>
>We'd rather use:
>
>   integrity=HMAC-MD5
>
>>  Steve
>
>   - Keith

There is a name associated with each registered algorithm, but it is 
not a requirement that the name be unique. also, in many instances, 
the form of the name will need to be more complex than your example, 
because of additional parameters of the algorithms. For example, 
HMAC-MD5 doesn't say whether the full 128-bit output is employed, or 
whether a truncated output is used, as in the case of current IPsec 
use in ESP and AH. I may have missed the usage context details that 
make use of OIDs impractical; could you restate the requirements re 
the form of the "name?"

Steve

Date: Wed, 16 Jan 2002 09:49:05 +1100
To: Stephen Kent <[email-masked]>
From: "Raif S. Naffah" <[email-masked]>
Subject: Re: [saag] Algorithm Naming
Cc: [email-masked], [email-masked], Keith Burdis <[email-masked]>
Sender: [email-masked]

At 01:34 PM 1/15/02 +0200, [email-masked] wrote:

>Quoting Stephen Kent <[email-masked]>:
>
> > A number of algorithms/modes are identified by OIDs, which are issued
> > by various organizations under the overall ITU umbrella. I think IANA
> > manages a tree arc for this purpose and we make use of it in several
> > WGs already, e.g., S/MIME and PKIX. These WGs also make use of OIDs
> > issued by other organizations (e.g., IEEE, RSA, NIST, DoD) who have
> > arcs in the tree, to avoid duplication.
>
>This is an interesting idea. Are there unique names associated with these 
>OIDs?
>
>While OIDs themselves are unique, we don't want to have to use:
>
>   integrity=1.3.6.1.5.5.8.1.1
>
>We'd rather use:
>
>   integrity=HMAC-MD5

furthermore, OID-to-name associations lack the other aspect of the proposed 
registry: the specification of  the algorithm itself; i.e. what (exactly) 
is referred to by the name.

cheers;
rsn

Date: Tue, 15 Jan 2002 13:51:50 -0500
From: Lawrence Greenfield <[email-masked]>
To: [email-masked]
Subject: SRP CP/IP/RD options
Sender: [email-masked]

I'm confused why there are options to negotiate encryption but not
integrity, etc.  Is there some feature that's served by allowing
people to negotiate somewhat nonsensical options?  Shouldn't we
require replay detection if you're going through the trouble of
integrity?  Shouldn't we require integrity protection if you're going
through the trouble of encryption?

I think there should be a substantial benefit to these options if
they're going to be left in.  In my view, they'll just cause
interoperability and testing headaches without serving any useful
purpose.

I therefore propose that the chart in 5.4:

      CP   IP   RD   Peer sends/receives

      I    I    I    { eos(p) }
      I    A    I    { eos(p) | os( IALG(K)( bytes(p) ) ) }
      I    A    A    { eos(p) | os( IALG(K)( bytes(p) | bytes(q)) ) }
      A    I    I    { eos(c) }
      A    A    I    { eos(c) | os( IALG(K)( bytes(c) ) ) }
      A    A    A    { eos(c) | os( IALG(K)((bytes(c) | bytes(q)) ) }

should be just:

      CP   IP   RD   Peer sends/receives

      I    I    I    { eos(p) }
      I    A    A    { eos(p) | os( IALG(K)( bytes(p) | bytes(q)) ) }
      A    A    A    { eos(c) | os( IALG(K)((bytes(c) | bytes(q)) ) }

Larry

Date: Tue, 15 Jan 2002 13:34:55 +0200
From: [email-masked]
To: Stephen Kent <[email-masked]>
Cc: "Raif S. Naffah" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [saag] Algorithm Naming
Sender: [email-masked]

Quoting Stephen Kent <[email-masked]>:

> A number of algorithms/modes are identified by OIDs, which are issued 
> by various organizations under the overall ITU umbrella. I think IANA 
> manages a tree arc for this purpose and we make use of it in several 
> WGs already, e.g., S/MIME and PKIX. These WGs also make use of OIDs 
> issued by other organizations (e.g., IEEE, RSA, NIST, DoD) who have 
> arcs in the tree, to avoid duplication.

This is an interesting idea. Are there unique names associated with these OIDs?

While OIDs themselves are unique, we don't want to have to use:

  integrity=1.3.6.1.5.5.8.1.1

We'd rather use:

  integrity=HMAC-MD5

> Steve

  - Keith

Date: Tue, 15 Jan 2002 00:05:30 -0500
To: "Raif S. Naffah" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: [saag] Algorithm Naming
Cc: [email-masked], [email-masked], Keith Burdis <[email-masked]>
Sender: [email-masked]

A number of algorithms/modes are identified by OIDs, which are issued 
by various organizations under the overall ITU umbrella. I think IANA 
manages a tree arc for this purpose and we make use of it in several 
WGs already, e.g., S/MIME and PKIX. These WGs also make use of OIDs 
issued by other organizations (e.g., IEEE, RSA, NIST, DoD) who have 
arcs in the tree, to avoid duplication.

Steve

Date: Sun, 13 Jan 2002 18:51:22 -0500 (EST)
From: Scott  Bradner <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [saag] Algorithm Naming
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

>         Before IETF goes off to create another registry, ought we not
> check and see if there is one existant elsewhere that we could
> just reuse 

as long as entry to those lists is not unduely restricted

Scott

Date: Mon, 14 Jan 2002 09:36:05 +1100
To: [email-masked], [email-masked]
From: "Raif S. Naffah" <[email-masked]>
Subject: Algorithm Naming
Cc: Keith Burdis <[email-masked]>
Sender: [email-masked]

We are faced with the problem of referencing algorithm names in
our specification (SRP SASL mechanism).  Related to algorithm
naming, http://www.ietf.org/ID-nits.html states:

   Variant Algorithm Definitions

   If you specify multiple algorithms for a particular function:
   For example, if there are multiple compression algorithms,
   encryption algorithms, representation formats, etc., consider

     * A robust way to enumerate these, preferably with space
     for future assignments by the Internet Assigned Number
     Authority

     * Consider re-using an existing IANA registry instead of
     creating a new one, since this leads to less confusion
     between different registries that have similar items.

Current IANA registries related to algorithm naming include:

   "Magic Numbers" for ISAKMP Protocol
   http://www.iana.org/assignments/isakmp-registry

   ONE TIME PASSWORD PARAMETERS
   http://www.iana.org/assignments/otp-parameters

   TELNET OPTIONS
   http://www.iana.org/assignments/telnet-options

All of these are references for a certain specification and/or
protocol.  None of them provide a central reference that can
be used by current or future IETF drafts/RFCs to unambiguously
reference algorithms/primitives used within their
specifications.

Rather than create a new IANA registry solely for our
specification, we propose that a new IANA registry be created
to store security-related naming information that can be
referenced by multiple specifications.  This registry would
hold information such as the names of message digest
algorithms, integrity protection algorithms, ciphers, cipher
modes of operations, key negotiation algorithms etc. (the
name), as well as the reference to some published
specifications of their design (the specification).

The initiation of this process may be through an informational
RFC that (a) describes the problem in more details, (b) gives
an initial list of algorithm names, and (c) guidelines for
registring more names with IANA.

Keith Burdis and Raif S. Naffah

Date: Wed,  9 Jan 2002 15:24:46 +0200
From: [email-masked]
To: Ken Murchison <[email-masked]>
Cc: SASL mailing list <[email-masked]>, "Raif S. Naffah" <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Sender: [email-masked]

Quoting Ken Murchison <[email-masked]>:
> 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

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.

> Ken

  - Keith

Date: Tue, 08 Jan 2002 16:28:32 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: [email-masked]
CC: SASL mailing list <[email-masked]>, "Raif S. Naffah" <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Sender: [email-masked]

[email-masked] wrote:
> 
> Quoting Ken Murchison <[email-masked]>:
> > 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.
> 
> 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.

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

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

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

Date: Tue, 08 Jan 2002 15:09:02 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: [email-masked], SASL mailing list <[email-masked]>, "Raif S. Naffah" <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Sender: [email-masked]

Ken Murchison wrote:
> 
> [email-masked] wrote:
> >
> > Quoting Ken Murchison <[email-masked]>:
> > > [email-masked] wrote:
> > > > 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.
> > >
> > > 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.
> >
> > 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?
> >
> > > 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.
> >
> > Agreed.
> 
> 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.

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

Date: Tue,  8 Jan 2002 22:05:54 +0200
From: [email-masked]
To: Ken Murchison <[email-masked]>
Cc: SASL mailing list <[email-masked]>, "Raif S. Naffah" <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Sender: [email-masked]

Quoting Ken Murchison <[email-masked]>:
> 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.

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.

> Ken

  - Keith

Date: Tue, 08 Jan 2002 14:26:15 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: [email-masked]
CC: SASL mailing list <[email-masked]>, "Raif S. Naffah" <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Sender: [email-masked]

[email-masked] wrote:
> 
> Quoting Ken Murchison <[email-masked]>:
> > [email-masked] wrote:
> > > 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.
> >
> > 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.
> 
> 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?
> 
> > 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.
> 
> Agreed.

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

Date: Tue,  8 Jan 2002 18:49:36 +0200
From: [email-masked]
To: Ken Murchison <[email-masked]>
Cc: SASL mailing list <[email-masked]>, "Raif S. Naffah" <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Sender: [email-masked]

Quoting Ken Murchison <[email-masked]>:
> [email-masked] wrote:
> > 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.
> 
> 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.

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

Agreed.

> Ken

  - Keith

Date: Mon, 07 Jan 2002 16:52:16 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: [email-masked]
CC: Lawrence Greenfield <[email-masked]>, SASL mailing list <[email-masked]>, "Raif S. Naffah" <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Sender: [email-masked]

[email-masked] wrote:
> >    Date: Sun,  6 Jan 2002 17:56:16 +0200
> >    > 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...
> >
> >    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.
> 
> 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.

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

Date: Mon,  7 Jan 2002 22:02:40 +0200
From: [email-masked]
To: Lawrence Greenfield <[email-masked]>
Cc: SASL mailing list <[email-masked]>, "Raif S. Naffah" <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Sender: [email-masked]

Quoting Lawrence Greenfield <[email-masked]>:
>    Date: Sun,  6 Jan 2002 17:56:16 +0200
>    > 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...
> 
>    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.

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

Date: Mon,  7 Jan 2002 13:50:17 +0200
From: [email-masked]
To: "RL 'Bob' Morgan" <[email-masked]>, [email-masked]
Cc: SASL mailing list <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Sender: [email-masked]

Quoting "Kurt D. Zeilenga" <[email-masked]>:
>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.

Quoting RL 'Bob' Morgan <[email-masked]>:
> 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"

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

Date: Mon, 7 Jan 2002 00:05:09 -0500
From: Lawrence Greenfield <[email-masked]>
To: [email-masked]
Cc: SASL mailing list <[email-masked]>, "Raif S. Naffah" <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Sender: [email-masked]

   Date: Sun,  6 Jan 2002 17:56:16 +0200
   From: [email-masked]
[...]
   > 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...

   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

Date: Sun, 06 Jan 2002 10:15:39 -0800
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Cc: Ken Murchison <[email-masked]>, "Raif S. Naffah" <[email-masked]>, SASL mailing list <[email-masked]>
Sender: [email-masked]

At 09:50 AM 2002-01-06, [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.

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

Date: Sun, 06 Jan 2002 10:09:36 -0800
To: SASL mailing list <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Cc: [email-masked], Ken Murchison <[email-masked]>, "Raif S. Naffah" <[email-masked]>
Sender: [email-masked]

At 09:38 AM 2002-01-06, Kurt D. Zeilenga wrote:

>At 09:19 AM 2002-01-06, [email-masked] wrote:
>
>>Quoting "Kurt D. Zeilenga" <[email-masked]>:
>>> 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.
>>
>>According to the current draft, mandatory means "mandatory to advertise", so to
>>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.

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

Date: Sun, 6 Jan 2002 10:05:34 -0800 (PST)
From: "RL 'Bob' Morgan" <[email-masked]>
Reply-To: "RL 'Bob' Morgan" <[email-masked]>
To: [email-masked]
cc: SASL mailing list <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Sender: [email-masked]

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

> Quoting "Kurt D. Zeilenga" <[email-masked]>:
> >
> > 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.
>
> 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"

Date: Sun,  6 Jan 2002 19:50:18 +0200
From: [email-masked]
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Ken Murchison <[email-masked]>, "Raif S. Naffah" <[email-masked]>, SASL mailing list <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Sender: [email-masked]

Quoting "Kurt D. Zeilenga" <[email-masked]>:

> At 09:19 AM 2002-01-06, [email-masked] wrote:
> 
> >Quoting "Kurt D. Zeilenga" <[email-masked]>:
> >> 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.
> >
> >According to the current draft, mandatory means "mandatory to advertise", so
> to
> >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.

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

Date: Sun, 6 Jan 2002 09:44:57 -0800 (PST)
From: "RL 'Bob' Morgan" <[email-masked]>
Reply-To: "RL 'Bob' Morgan" <[email-masked]>
To: [email-masked]
cc: SASL mailing list <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Sender: [email-masked]

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

> Quoting "Kurt D. Zeilenga" <[email-masked]>:
> > 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.
>
> 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"

Date: Sun,  6 Jan 2002 19:41:16 +0200
From: [email-masked]
To: SASL mailing list <[email-masked]>
Cc: Ken Murchison <[email-masked]>, "Raif S. Naffah" <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Sender: [email-masked]

Quoting [email-masked]:
> Quoting Ken Murchison <[email-masked]>:
> > 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.
>
> 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?

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

Date: Sun, 06 Jan 2002 09:38:48 -0800
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Cc: Ken Murchison <[email-masked]>, "Raif S. Naffah" <[email-masked]>, SASL mailing list <[email-masked]>
Sender: [email-masked]

At 09:19 AM 2002-01-06, [email-masked] wrote:

>Quoting "Kurt D. Zeilenga" <[email-masked]>:
>> 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.
>
>According to the current draft, mandatory means "mandatory to advertise", so to
>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.

Date: Sun,  6 Jan 2002 19:19:12 +0200
From: [email-masked]
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Ken Murchison <[email-masked]>, "Raif S. Naffah" <[email-masked]>, SASL mailing list <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Sender: [email-masked]

Quoting "Kurt D. Zeilenga" <[email-masked]>:
> 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.

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

> Kurt

  - Keith

Date: Sun, 06 Jan 2002 08:26:05 -0800
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Cc: Ken Murchison <[email-masked]>, "Raif S. Naffah" <[email-masked]>, SASL mailing list <[email-masked]>
Sender: [email-masked]

At 07:56 AM 2002-01-06, [email-masked] wrote:
>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.

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

Date: Sun,  6 Jan 2002 17:56:16 +0200
From: [email-masked]
To: Ken Murchison <[email-masked]>
Cc: "Raif S. Naffah" <[email-masked]>, SASL mailing list <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Sender: [email-masked]

Quoting Ken Murchison <[email-masked]>:
> [email-masked] wrote:
> > 
> > Quoting Ken Murchison <[email-masked]>:
> 
> [...]
> 
> > >
> > > There are two ways that the server can simplify 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).
> > 
> > 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.).
> 
> 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...

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

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

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.

> Ken

  - Keith

Date: Sun, 06 Jan 2002 09:19:29 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: [email-masked]
CC: "Raif S. Naffah" <[email-masked]>, SASL mailing list <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Sender: [email-masked]

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

[...]

> >
> > There are two ways that the server can simplify 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).
> 
> 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.).

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

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

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

Date: Sun,  6 Jan 2002 13:01:48 +0200
From: [email-masked]
To: Ken Murchison <[email-masked]>
Cc: "Raif S. Naffah" <[email-masked]>, SASL mailing list <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Sender: [email-masked]

Quoting Ken Murchison <[email-masked]>:
> 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.

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.

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

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.

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

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

> 2. It stores plaintext (or equivalent) passwords so that it can
> 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
> further if necessary.

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.

> Ken

  - Keith

Date: Sat, 05 Jan 2002 23:44:49 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: "Raif S. Naffah" <[email-masked]>, [email-masked], SASL mailing list <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Sender: [email-masked]

"Raif S. Naffah" wrote:
> 
> hello Ken,
> 
> At 10:55 AM 1/2/02 -0500, Ken Murchison wrote:
> 
> >"Raif S. Naffah" wrote:
> > >
> > > 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?...
> > >
> > > 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...
> >
> >I see a couple of other options, both of which eliminate the need for
> >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.

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
-- 
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: "Marshall T. Rose" <[email-masked]>
To: "Rob Siemborski" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "Marshall Rose" <[email-masked]>
Subject: Re: SASL C API and BEEP C API
Date: Fri, 4 Jan 2002 18:32:13 -0800
Sender: [email-masked]

> Marshall, if I misunderstood anything, please feel free to clarify the
> problems.

looks fine to me.

/mtr

Date: Fri, 4 Jan 2002 16:56:41 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
cc: [email-masked], <[email-masked]>
Subject: SASL C API and BEEP C API
Sender: [email-masked]

Hi guys,

I've been having some discussions with Marshall Rose about beepcore-c's
use of the SASL C API to implement the SASL part of RFC3080 in their
library.  We've run across a few limitations in the current C API, and I
have work arounds, but I'd like to hear other opinions on them.

The first is fairly easy.  BEEP (as a protocol) needs to know if security
layer negotiation took place, regardless of whether authentication
succeeded or failed, because if the negotiation is attempted, it is
required that all open BEEP channels are closed.  My "easy" solution to
this is that the ssf part of the oparams structure would be set by the
mechanism if negotiation was attempted at all, regardless of the result.
(obviously, if negotiation fails and a failure is returned to the
application, the security layer is unusable regardless of the SSF value).
This would allow applications to do a sasl_getprop(SASL_SSF) after a
failed authentication to determine if a security layer negotiation had
occurred.

The second problem is a slightly more messy problem.  The two APIs work in
very conflicting ways with regards to how profiles are registered and when
this occurs.  The main problem is that the beepcore API needs to have a
complete list of all possible mechanisms before any connection is
established that might possibly need them.  This is for both servers and
clients.  The SASL API is built around much more "traditional" SASL
profiles where such a list is not needed until after a connection occurs.
Later, on a per connection basis, the mechanisms that are advertised can
be determined, but they must have been registered beforehand.

After some discussion between Marshall and myself, I believe that the
easiest way to satisfy both APIs is to make a slight modification to the
definition of sasl_listmech().

Basically, I would clarify the definition to:
1. Allow it to be called for client sasl_conn_t's as well as server
sasl_conn_ts.
2. Allow it to take a NULL sasl_conn_t, which would indicate that it
should list all mechanisms that the library is capable of providing, even
if they may not be available in all cases.

#2 is the really important one, I believe that Marshall found a way around
#1.  Of course, it feels like it is breaking some of the abstraction that
the library is providing, and therefore leaves a slightly bad taste in my
mouth.

If others had ideas about better ways to proceed here, I'd like to hear
them.  Obviously avoiding major changes to either API is preferred.

Marshall, if I misunderstood anything, please feel free to clarify the
problems.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | W3VC President * Scotch & Soda Technical Coordinator
Andrew Systems Group * Cyert Hall 235 * 412-CMU-TREK | ABTech Exec
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/CC/PA d- s+: a-- C++++$ UBLS++++$ P+++$ L++(+++) E W- N- o?
K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-- b+ DI+++ G e h r y?
------END GEEK CODE BLOCK-----

Date: Fri, 04 Jan 2002 18:57:33 -0800
From: Chris Newman <[email-masked]>
To: Rob Siemborski <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: Re: SASL C API and BEEP C API
Sender: [email-masked]

I can live with those changes.

		- Chris

From: "Marshall T. Rose" <[email-masked]>
To: "Rob Siemborski" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "Marshall Rose" <[email-masked]>
Subject: Re: SASL C API and BEEP C API
Date: Fri, 4 Jan 2002 18:32:13 -0800
Sender: [email-masked]

> Marshall, if I misunderstood anything, please feel free to clarify the
> problems.

looks fine to me.

/mtr

Date: Fri, 04 Jan 2002 06:08:00 +1100
To: Ken Murchison <[email-masked]>
From: "Raif S. Naffah" <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Cc: [email-masked], SASL mailing list <[email-masked]>
Sender: [email-masked]

At 09:48 AM 1/3/02 -0500, Ken Murchison wrote:
>"Raif S. Naffah" wrote:
> > At 10:55 AM 1/2/02 -0500, Ken Murchison wrote:
> > >"Raif S. Naffah" wrote:
> > > > At 11:17 AM 12/7/01 -0500, Ken Murchison wrote:
> > > > >What is the expected behavior of an implementation with respect to MDA
> > > > >names?...
> > > >
> > > > 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...
> > >
> > >I see a couple of other options, both of which eliminate the need for
> > >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.
>
>Agreed.  Will this be something along the lines of the integrity option,
>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

Date: Thu,  3 Jan 2002 18:13:46 +0200
From: [email-masked]
To: Ken Murchison <[email-masked]>
Cc: "Raif S. Naffah" <[email-masked]>, SASL mailing list <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Sender: [email-masked]

Quoting Ken Murchison <[email-masked]>:

> 
> 
> 
> "Raif S. Naffah" wrote:
> > 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.
> 
> Agreed.  Will this be something along the lines of the integrity option,
> where if not specified, SHA-1 is the implied underlying hash?

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.

> 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?

I'm not involved with this effort.

> Ken

  - Keith

Date: Thu, 03 Jan 2002 09:48:48 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: "Raif S. Naffah" <[email-masked]>
CC: [email-masked], SASL mailing list <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Sender: [email-masked]

"Raif S. Naffah" wrote:
> 
> hello Ken,
> 
> At 10:55 AM 1/2/02 -0500, Ken Murchison wrote:
> 
> >"Raif S. Naffah" wrote:
> > >
> > > 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?...
> > >
> > > 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...
> >
> >I see a couple of other options, both of which eliminate the need for
> >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.

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

Date: Thu, 03 Jan 2002 21:02:19 +1100
To: Ken Murchison <[email-masked]>
From: "Raif S. Naffah" <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Cc: [email-masked], SASL mailing list <[email-masked]>
Sender: [email-masked]

hello Ken,

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

>"Raif S. Naffah" wrote:
> >
> > 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?...
> >
> > 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...
>
>I see a couple of other options, both of which eliminate the need for
>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.

Date: Wed, 02 Jan 2002 10:55:00 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: "Raif S. Naffah" <[email-masked]>
CC: [email-masked], [email-masked], SASL mailing list <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-05: MDA name
Sender: [email-masked]

"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