Subject: Re: [tram] Comments on draft-ietf-tram-stunbis-04

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 26 Jan 2016 19:39:50 -0800

Thanks again for the review, and sorry for the delay in processing it.  See inline.

On 07/20/2015 04:11 PM, Jonathan Lennox wrote:
> Inspired by the pleas in the TRAM working group today, I decided read
> over draft-ietf-tram-stunbis-04.
> 
> (Note that I’ve only reviewed the diff from RFC 5389, not re-reading
> the document from scratch, so this only catches new problems, not old
> problems.)
> 
> Section 8.1: "The DNS SRV service name is the content of the <host>
> part.” This is wrong — the DNS SRV service name is “stun” or “stuns”.
> This seems to have gotten mangled in the conversion to describing the
> resolution process in terms of the URL.

Fixed.

> 
> Section 9.1.3:
> 
> “If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the 
> value for the message integrity as described in Section 14.5, using
> the password associated with the username. If the MESSAGE- 
> INTEGRITY-SHA256 attribute is not present, and using the same 
> password, compute the value for the message integrity as described in
> Section 14.4. If the resulting value does not match the contents of
> the MESSAGE-INTEGRITY-SHA256 attribute or the MESSAGE- INTEGRITY
> attribute:”
> 
> Is this saying that a SHA-1 message integrity value (described in
> Section 14.4) can be carried in a MESSAGE-INTEGRITY-SHA256 attribute?
> That doesn’t seem right.
> 

Can you please suggest some text that would make it clearer that this is not the intended meaning?  We fail to see how this conclusion can be made from the text.

> Section 9.1.4:
> 
> “The client looks for the MESSAGE-INTEGRITY-SHA256 or the MESSAGE- 
> INTEGRITY attribute in the response. If present, the client computes
>  the message integrity over the response as defined in Section 14.4
> or Section 14.5, using the same password it utilized for the request.
>  If the resulting value matches the contents of the MESSAGE-INTEGRITY
>  or MESSAGE-INTEGRITY-SHA256 attribute, the response is considered 
> authenticated. If the value does not match, or if both MESSAGE- 
> INTEGRITY and MESSAGE-INTEGRITY-SHA256 were absent, the response MUST
>  be discarded, as if it was never received. This means that 
> retransmits, if applicable, will continue.”
> 
> Parallelism failure. Sometimes MESSAGE-INTEGRITY is listed first, and
> sometimes MESSAGE-INTEGRITY-SHA256.  If read literally it would seem
> to imply you were swapping the values.  The two algorithms should be
> consistently listed in order, and it should be made clear that they
> apply respectively.

Fixed.

> 
> Additionally, it should say that if the client only sent one
> algorithm in the request (because of the external indication in
> section 9.1.2, or this being a subsequent request as defined in
> 9.1.5) the algorithm in the response has to match.

Fixed.

> 
> Section 9.1.5:
> 
> “A client sending subsequent requests to the same server a MAY choose
>  to send only the MESSAGE-INTEGRITY-SHA256 or the MESSAGE-INTEGRITY 
> attribute depending upon the attribute that was received in the 
> response to the initial request.”
> 
> This should probably be required to be the literal same server —i.e.,
> the same IP and port — not just the same URL or SRV lookup.

Fixed.

> 
> Section 9.2.3:
> 
> There seems to be a random github URL pasted into the document.

Fixed :-)

> 
> “If the NONCE attribute starts with the value "obMatJos2" but the 
> PASSWORD-ALGORITHMS attribute is not present or is not identical to
> the PASSWORD-ALGORITHMS attribute sent in the response, the server
> MUST generate an error response with an error code of 400 (Bad
> Request). This response SHOULD NOT include a USERNAME, NONCE, REALM,
> MESSAGE-INTEGRITY, or MESSAGE-INTEGRITY-SHA256 attribute.”
> 
> Doesn’t this break backward compatibility with RFC 5389 (i.e.,
> MD5-algorithm-only) clients?  It’s a server’s choice whether to
> support MD5 as a password algorithm, but presumably if it does it’s
> doing so for a reason (i.e. an old password database or supporting
> old clients).
> 
> I think this should say that if PASSWORD-ALGORITHMS doesn’t match,
> the request is dropped; but if the request contains neither
> PASSWORD-ALGORITHMS nor PASSWORD-ALGORITHM, the request is processed
> as though PASSWORD-ALGORITHM were MD5.  (And MD5 should be added to
> PASSWORD-ALGORITHMS, see below.)  Depending on the list in
> PASSWORD-ALGORITHMS, this may either be supported, or trigger a 400.
> 
> It’s a 400 if only one of PASSWORD-ALGORITHM or PASSWORD-ALGORITHMS
> is present, or if PASSWORD-ALGORITHM doesn’t match one of the entries
> in PASSWORD-ALGORITHMS.
> 
> Meanwhile, to prevent bid-down, the *client* requirements should say
> that if the nonce begins with obMatJos2 but PASSWORD-ALGORITHMS is
> not present, the response should be ignored.
> 
> 
> “If these checks pass, the server continues to process the request. 
> Any response generated by the server (excepting the cases described 
> above) MUST include both the MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-
>  SHA256 attributes, computed using the username and password utilized
>  to authenticate the request.”
> 
> Why do you want both?  For short-term you only send
> MESSAGE-INTEGRITY-SHA256 if the client supported it.
> 

These were tough, but we think that we captured the essence of your concerns. But please have a look at the new text.

> Section 9.2.4:
> 
> “If the response is an error response with an error code of 401 
> (Unauthorized), the client SHOULD retry the request with a new 
> transaction. This request MUST contain a USERNAME, determined by the
>  client as the appropriate username for the REALM from the error 
> response. The request MUST contain the REALM, copied from the error 
> response. The request MUST contain the NONCE, copied from the error 
> response. If the response contains a PASSWORD-ALGORITHMS attribute, 
> the request MUST contain the PASSWORD-ALGORITHMS attribute with the 
> same content. If the response contains a PASSWORD-ALGORITHMS 
> attribute, and this attribute contains at least one algorithm that is
>  supported by the client then the request MUST contain a PASSWORD- 
> ALGORITHM attribute with the first algorithm supported on the list.”
> 
> This text seems to imply that if the PASSWORD-ALGORITHMS list
> contains only algorithms the client doesn’t recognize, the client
> goes ahead and uses MD5. Does this make sense? I think the client
> should give up if it doesn’t support any of the algorithms.

Fixed.

> 
> "if the response contains a MESSAGE-INTEGRITY-SHA256 attribute then 
> the request MUST contain a MESSAGE-INTEGRITY-SHA256 attribute, 
> computed using the password associated with the username in the 
> USERNAME attribute. Else the request MUST contain the MESSAGE- 
> INTEGRITY attribute, computed using the password associated with the
>  username in the USERNAME attribute. The client MUST NOT perform this
>  retry if it is not changing the USERNAME or REALM or its associated
>  password, from the previous attempt.”
> 
> We’re still talking about the 401 Unauthorized here, right? The text
> says the response SHOULD NOT contain MESSAGE-INTEGRITY-SHA256, since
> there’s no way to know the username to use.

Fixed.

> 
> That said, it seems to me to be reasonable to say that if the
> response contains PASSWORD-ALGORITHMS, the followup request should be
> authenticated using MESSAGE-INTEGRITY-SHA256 only, since we know that
> both the client and server are stunbis.
> 

Done.

> 
> 
> Section 14.10:
> 
> “The PASSWORD-ALGORITHMS attribute is present only in responses.”
> 
> Not true, it’s in followup requests, as mentioned, to prevent
> bid-down.

Fixed.

> 
> Section 17.4:
> 
> Salted SHA-256 is still listed in the password algorithms table,
> despite being otherwise deleted from the document.

Fixed.

> 
> Should we define MD5 as a PASSWORD-ALGORITHM value? The use case is a
> server that wants to upgrade to stunbis, but wants to keep using its
> existing (md5-hashed) password database without forcing users to
> re-enter their password.  (This would mean a case where long-term
> authentication uses the MD5 password algorithm, but
> MESSAGE-INTEGRITY-SHA256 integrity.)
> 

OK.

> 
> Section 17.5:
> 
> Should register the stuns over UDP port.

My understanding (following a discussion with IANA in Dallas, IIRC) is that as we should only update the RFC 5389 registrations, and not the RFC 7350 registration.

> 
> 
> A general question about the PASSWORD-ALGORITHM transition process:
> do we want to support the use case where a server is gradually
> transitioning its existing database to have SHA-256 as the password
> hash algorithm (as users change passwords)?  This might result in a
> case where some users have MD5-hashed passwords in the database, and
> some have SHA-256 — but the server doesn’t yet know when responding
> to the initial request which user is making the request, and thus
> which password algorithms are actually supported for this specific
> user.  Supporting this would require either putting USERNAME in the
> initial request (which seems bad in the absence of a known realm), or
> else allowing a server to respond to a followup request with another
> 401 Unauthorized response, with a shorter PASSWORD-ALGORITHMS list
> (resulting in long-term authentication requiring three transactions
> for stunbis clients whose users who are still on MD5).  Despite the
> triple transaction, I’m inclined to recommend the latter.

Interesting use case regarding the management of an hybrid database containing mixed MD5/SHA256 users, but is it worth adding that complexity to the protocol?  We're willing to listen to opinion from the working group, especially people with large deployments.

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 27 Jan 2016 16:29:57 +0000

> On Jan 26, 2016, at 10:39 PM, Marc Petit-Huguenin <[email-masked]> wrote:
> 
>> 
>> Section 9.1.3:
>> 

My problem is with the phrase “If the resulting value does not match the contents of the MESSAGE-INTEGRITY-SHA256 attribute or the MESSAGE-INTEGRITY attribute,” which implies to me that the calculated message integrity value is compared with the content of both attributes.

Perhaps “If the resulting value does not match the contents of the corresponding attribute (MESSAGE-INTEGRITY-SHA256 or MESSAGE-INTEGRITY):"

>> consistently listed in order, and it should be made clear that they

I would also add “,respectively,” twice, once after “Section 14.5” and once before “the response is considered”.

>> 9.1.5) the algorithm in the response has to match.

I would add “otherwise the response MUST be discarded” to the new sentence you added.

>> [My original comments on password algorithm omitted]
> 

These generally seem a lot better.  A few comments on the new content:

“If the NONCE attribute starts with the value "obMatJos2" but	
PASSWORD-ALGORITHMS does not match, then the server MUST generate	
an error response with an error code of 400 (Bad Request).”

This doesn’t say what the PASSWORD-ALGORITHMS has to match (it got lost in the conversion).  Presumably “does not match the value in sent in the response that sent this NONCE”?

“If the NONCE attribute starts with the value "obMatJos2" but the request contains neither PASSWORD-ALGORITHMS nor PASSWORD-ALGORITHM, then the request is processed as though PASSWORD-ALGORITHM were MD5.”

I might add “(Note that if the original PASSWORD-ALGORITHMS attribute did not contain MD5, this will result in a 400 Bad Request in a later step below.)”, but this is editorial and I leave it to your discretion.

"If the NONCE is no longer valid, the server MUST generate an error response with an error code of 438 (Stale Nonce).  This response MUST include NONCE and REALM attributes”

MUST include PASSWORD-ALGORITHMS as well.  Similarly for the generated 401.

“Any response generated by the server (excepting the cases where a	
server responds with an error code, which cannot be authenticated)”

Remove the comma — this should be a dependent clause, since some error codes can be authenticated.  

Actually, more generally, any response after this point will be able to be authenticated, since we’ve passed authentication.  Looking at the diff, I think the earlier language for the parenthetical phrase “(excepting in the cases described above)” was better, but more wordsmithing is possible.

“MUST include MESSAGE-INTEGRITY-SHA256 attribute, computed using the	
username and password utilized to authenticate the request, unless	
the request was processed as though PASSWORD-ALGORITHM was MD5. In	
that case the MESSAGE-INTEGRITY attribute MUST be used instead of the	
MESSAGE-INTEGRITY-SHA256 attribute.”

I understand what you’re saying but I think “was processed as though PASSWORD-ALGORITHM was MD5” is ambiguous.

And actually, thinking about it, it seems to me that for long-term auth, there’s never any need for clients to send both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256 — you send the latter if there was a PASSWORD-ALGORITHMS accompanying the nonce, otherwise the former.  In which case the server just mirrors the client.

“If the response is an error response with an error code of 401
(Unauthorized), the client MUST test if the NONCE attribute value
starts with the character string "obMatJos2".  If the test succeeds
and no PASSWORD-ALGORITHMS attribute is present, then the client MUST
NOT retry the request with a new transaction.”

I think this test needs to apply to 438 Stale Nonce too, to prevent it being used for bid-down.

>> MESSAGE-INTEGRITY-SHA256 integrity.)

Definition of the key is using SHA256. :-)

> My understanding (following a discussion with IANA in Dallas, IIRC) is that as we should only update the RFC 5389 registrations, and not the RFC 7350 registration.

Okay.

> Interesting use case regarding the management of an hybrid database containing mixed MD5/SHA256 users, but is it worth adding that complexity to the protocol?  We're willing to listen to opinion fr…

This is at the end of a long and editorial e-mail, so it’s probably worth calling this out in a standalone message.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 28 Jan 2016 11:07:32 -0800

Inline.

On 01/27/2016 08:29 AM, Jonathan Lennox wrote:
>>>  value for the message integrity as described in Section 14.5,
>>> using the password associated with the username. If the MESSAGE-
>>> password, compute the value for the message integrity as
>>> described in Section 14.4. If the resulting value does not match
>>> the contents of the MESSAGE-INTEGRITY-SHA256 attribute or the
>>> MESSAGE- INTEGRITY attribute:”
>>> 
>>> Is this saying that a SHA-1 message integrity value (described
>>> in Section 14.4) can be carried in a MESSAGE-INTEGRITY-SHA256
>>> attribute? That doesn’t seem right.
>>> 
>> 
>> Can you please suggest some text that would make it clearer that
>> this is not the intended meaning?  We fail to see how this
>> conclusion can be made from the text.
> 
> My problem is with the phrase “If the resulting value does not match
> the contents of the MESSAGE-INTEGRITY-SHA256 attribute or the
> MESSAGE-INTEGRITY attribute,” which implies to me that the calculated
> message integrity value is compared with the content of both
> attributes.
> 
> Perhaps “If the resulting value does not match the contents of the
> corresponding attribute (MESSAGE-INTEGRITY-SHA256 or
> MESSAGE-INTEGRITY):"

We used your text.

> 
>>> Section 9.1.4:
>>> 
>>> “The client looks for the MESSAGE-INTEGRITY-SHA256 or the
>>> MESSAGE- INTEGRITY attribute in the response. If present, the
>>> client computes the message integrity over the response as
>>> defined in Section 14.4 or Section 14.5, using the same password
>>> it utilized for the request. If the resulting value matches the
>>> contents of the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256
>>> attribute, the response is considered authenticated. If the value
>>> does not match, or if both MESSAGE- INTEGRITY and
>>> MESSAGE-INTEGRITY-SHA256 were absent, the response MUST be
>>> discarded, as if it was never received. This means that 
>>> Parallelism failure. Sometimes MESSAGE-INTEGRITY is listed first,
>>> and sometimes MESSAGE-INTEGRITY-SHA256.  If read literally it
>>> would seem to imply you were swapping the values.  The two
>>> algorithms should be consistently listed in order, and it should
>>> be made clear that they apply respectively.
>> 
>> Fixed.
> 
> I would also add “,respectively,” twice, once after “Section 14.5”
> and once before “the response is considered”.

Done.

Done.

>> These were tough, but we think that we captured the essence of your
>> concerns. But please have a look at the new text.
> 
> PASSWORD-ALGORITHMS does not match, then the server MUST generate an
> error response with an error code of 400 (Bad Request).”
> 
> This doesn’t say what the PASSWORD-ALGORITHMS has to match (it got
> lost in the conversion).  Presumably “does not match the value in
> sent in the response that sent this NONCE”?

Done.

> request contains neither PASSWORD-ALGORITHMS nor PASSWORD-ALGORITHM,
> then the request is processed as though PASSWORD-ALGORITHM were
> MD5.”
> 
> I might add “(Note that if the original PASSWORD-ALGORITHMS attribute
> did not contain MD5, this will result in a 400 Bad Request in a later
> step below.)”, but this is editorial and I leave it to your
> discretion.

We found this suggestion useful, so we applied it.

> 
> "If the NONCE is no longer valid, the server MUST generate an error
> response with an error code of 438 (Stale Nonce).  This response MUST
> include NONCE and REALM attributes”
> 

Done.

> Actually, more generally, any response after this point will be able
> to be authenticated, since we’ve passed authentication.  Looking at
> the diff, I think the earlier language for the parenthetical phrase
> “(excepting in the cases described above)” was better, but more
> wordsmithing is possible.

Ok, we took an alternative approach which may be a little clearer, please have a look.

> I understand what you’re saying but I think “was processed as though
> PASSWORD-ALGORITHM was MD5” is ambiguous.

What we did was copy the text from the 3rd bullet to make it explicitly clear the reason we process as MD5.

> 
> And actually, thinking about it, it seems to me that for long-term
> auth, there’s never any need for clients to send both
> MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256 — you send the latter
> if there was a PASSWORD-ALGORITHMS accompanying the nonce, otherwise
> the former.  In which case the server just mirrors the client.
> 
> and no PASSWORD-ALGORITHMS attribute is present, then the client
> MUST NOT retry the request with a new transaction.”
> 

Fixed.

> 
>>> 
>>> Should we define MD5 as a PASSWORD-ALGORITHM value? The use case
>>> is a server that wants to upgrade to stunbis, but wants to keep
>>> using its existing (md5-hashed) password database without forcing
>>> users to re-enter their password.  (This would mean a case where
>>> long-term authentication uses the MD5 password algorithm, but 

Fixed.

>> My understanding (following a discussion with IANA in Dallas, IIRC)
>> is that as we should only update the RFC 5389 registrations, and
>> not the RFC 7350 registration.
> 
> Okay.
> 
>>> A general question about the PASSWORD-ALGORITHM transition
>>> process: do we want to support the use case where a server is
>>> gradually transitioning its existing database to have SHA-256 as
>>> the password hash algorithm (as users change passwords)?  This
>>> might result in a case where some users have MD5-hashed passwords
>>> in the database, and some have SHA-256 — but the server doesn’t
>>> yet know when responding to the initial request which user is
>>> making the request, and thus which password algorithms are
>>> actually supported for this specific user.  Supporting this would
>>> require either putting USERNAME in the initial request (which
>>> seems bad in the absence of a known realm), or else allowing a
>>> server to respond to a followup request with another 401
>>> Unauthorized response, with a shorter PASSWORD-ALGORITHMS list 
>>> (resulting in long-term authentication requiring three
>>> transactions for stunbis clients whose users who are still on
>>> MD5).  Despite the triple transaction, I’m inclined to recommend
>>> the latter.
>> 
>> Interesting use case regarding the management of an hybrid database
>> containing mixed MD5/SHA256 users, but is it worth adding that
>> complexity to the protocol?  We're willing to listen to opinion
>> from the working group, especially people with large deployments.
> 
> This is at the end of a long and editorial e-mail, so it’s probably
> worth calling this out in a standalone message.
> 

- -- 
Marc Petit-Huguenin

---

From: Simon Perreault <[email-masked]>
Date: Thu, 28 Jan 2016 15:08:25 -0500

Starting a new thread, as requested...

>> worth calling this out in a standalone message.

Discuss! :D

Simon

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 29 Jan 2016 02:52:06 +0000

o  If the NONCE attribute starts with the value "obMatJos2" but the
      request contains neither PASSWORD-ALGORITHMS nor PASSWORD-
      ALGORITHM, then the request is processed as though PASSWORD-
      ALGORITHM were MD5 (Note that if the original PASSWORD-ALGORITHMS
      attribute did not contain MD5, this will result in a 400 Bad
      Request in a later step below).

The above rule could result in downgrade attack. If the server supports both password algorithms and MIM attacker removes PASSWORD-ALGORITHMS attribute from the response, forcing the client to pick MD5. How does the server detect such an attack ?

-Tiru

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Simon Perreault
> Sent: Friday, January 29, 2016 1:38 AM
> To: Marc Petit-Huguenin; Jonathan Lennox
> Cc: [email-masked]
> Subject: [tram] Transition to new password algorithm
> 
> >>> >>> might result in a case where some users have MD5-hashed
> >>> >>> passwords in the database, and some have SHA-256 — but the
> >>> >>> server doesn’t yet know when responding to the initial request
> >>> >>> which user is making the request, and thus which password
> >>> >>> algorithms are actually supported for this specific user.
> >>> >>> Supporting this would require either putting USERNAME in the
> >>> >>> initial request (which seems bad in the absence of a known
> >>> >>> realm), or else allowing a server to respond to a followup
> >>> >>> request with another 401 Unauthorized response, with a shorter
> >>> >>> PASSWORD-ALGORITHMS list (resulting in long-term authentication
> >>> >>> requiring three transactions for stunbis clients whose users who
> >>> >>> are still on MD5).  Despite the triple transaction, I’m inclined
> >>> >>> to recommend the latter.
> >> >>
> >> >> Interesting use case regarding the management of an hybrid
> >> >> database containing mixed MD5/SHA256 users, but is it worth adding
> >> >> that complexity to the protocol?  We're willing to listen to
> >> >> opinion from the working group, especially people with large
> deployments.
> >>
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Brandon Williams <[email-masked]>
Date: Fri, 29 Jan 2016 10:06:21 -0500

A client that supports PASSWORD-ALGORITHMS only accepts a NONCE with 
"obMatJos2" if PASSWORD-ALGORITHMS is present and it is required to echo 
back the same PASSWORD-ALGORITHMS attribute in the authenticated 
request. If PASSWORD-ALGORITHMS is not present in the new request, that 
can only mean that the client doesn't support it.

--Brandon

-- 
Brandon Williams; Chief Architect
Cloud Networking; Akamai Technologies Inc.

-- 
Brandon Williams; Chief Architect
Cloud Networking; Akamai Technologies Inc.

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 29 Jan 2016 15:13:16 +0000

> On Jan 28, 2016, at 9:52 PM, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:
> 

It doesn’t, the client does — if the client sees a nonce beginning with obMatJos2 but no PASSWORD-ALGORITHMS attribute in the response, it MUST ignore the response.

(If the client chooses not to follow this, it’s essentially behaving as an RFC 5389 client, which as long as you’re supporting backward compatibility is unavoidable behavior.  But a third-party can’t force a downgrade.)

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 30 Jan 2016 03:15:20 +0000

Got it, Thanks.

-Tiru

> From: Jonathan Lennox [mailto:[email-masked]]
> Sent: Friday, January 29, 2016 8:43 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: Simon Perreault; Marc Petit-Huguenin; [email-masked]
> Subject: Re: [tram] Transition to new password algorithm
> 
> 
> > The above rule could result in downgrade attack. If the server supports
> both password algorithms and MIM attacker removes PASSWORD-
> ALGORITHMS attribute from the response, forcing the client to pick MD5.
> How does the server detect such an attack ?
> 
> It doesn’t, the client does — if the client sees a nonce beginning with
> obMatJos2 but no PASSWORD-ALGORITHMS attribute in the response, it
> MUST ignore the response.
> 
> (If the client chooses not to follow this, it’s essentially behaving as an RFC
> 5389 client, which as long as you’re supporting backward compatibility is
> unavoidable behavior.  But a third-party can’t force a downgrade.)
> 
> >
> > -Tiru
> >
> >
> >>>>>>>> gradually transitioning its existing database to have SHA-256
> >>>>>>>> as the password hash algorithm (as users change passwords)?
> >>>>>>>> This might result in a case where some users have MD5-hashed
> >>>>>>>> requiring three transactions for stunbis clients whose users
> >>>>>>>> who are still on MD5).  Despite the triple transaction, I’m
> >>>>>>>> inclined to recommend the latter.
> >>>>>>
> >>>>>> database containing mixed MD5/SHA256 users, but is it worth
> >>>>>> adding that complexity to the protocol?  We're willing to listen
> >>>>>> to opinion from the working group, especially people with large
> >> deployments.
> >>>>