Re: LAST CALL: Simple Authentication and Security Layer (SASL)

[Simon Josefsson <[e-mail]>]

Hello all,

In general, I think the document is pretty good.  It could use a
re-read, to fix editorial flaws.  I only reviewed my pet problem-area
of SASLprep below.

Section 4, Protocol Requirements:

     Specifications are encouraged to prescribe use of existing
     authorization identity forms as well as existing string
     representations, such as simple user names [RFC4013].  Protocols
     whose authorization identities are simple user names SHOULD use of
     SASLprep [RFC4013] (a profile of the StringPrep [RFC3454]
     preparation algorithm) as their preparation algorithm.

The intention of the requirement appear unclear to me.  For example,
take IMAP or SMTP authentication, with simple username+password.  Is
the intention that the transferred authorization identity should be in
SASLprep:ed form?  If so, I believe it is better to preserve as much
as possible of what the user typed as long as possible.  Having the
client apply SASLprep to the authorization identity would violate
that.

On the other hand, requiring the server to apply SASLprep may be too
expensive.  There are resource-starvation issues to consider here.
Customers are asking for optimized versions of my StringPrep
implementation to be able to use it in a server.

If the above requirement is going to be present, I believe it should
either be clear on what is intended, or acknowledge that it is meant
to be fuzzy and that is leaves things open.  To me, I get the
impression that it is meant to be fuzzy.  Adopting parts of the
following paragraph, from Mechanism Requirements, would acknowledge
that the fuzziness is intended, and that protocol specifications must
clarify the details.  What do you think?

  In order to avoid interoperability problems due to differing
  normalizations, when a mechanism calls for character data is to be
  used as input to a cryptographic and/or comparison function, the
  specification MUST detail precisely how and where (client or server)
  the character data is to be prepared, including all normalizations,
  for input into the function to ensure proper operation.

Also, there is a typo, s/SHOULD use of/SHOULD use/.

Section 5, Mechanism Requirements:

  The mechanism SHOULD NOT use the authorization identity string in
  generation of any long-term cryptographic keys or hashes as there is
  no requirement that the authorization identity string be be
  non-canonical.

I might be picking words here, but 'non-canonical'?  Shouldn't that be
'canonical'?  Even so, if I understand correctly, what is intended is
that one user may have different authorization identities in different
protocols, and that is why mechanisms shouldn't use the authorization
identities as input to hash functions etc.  If so, I don't think
"canonical" is a good word here, since one protocol's authzid is as
good as another protocol's authzid.  There is no "canonical" authzid
to speak of.

Also, there is a typo, s/be be/to be/.

Cheers,
Simon