[Standards-JIG] Re: Call for Experience: JEP-0078 (Non-SASL Authentication)
stpeter at jabber.org
Tue Oct 12 20:58:32 UTC 2004
<8CDC3525190B624F8F740435C7B9A01D595A at heineken.winfessor.com>,
"JD Conley" <jconley at winfessor.com> wrote:
> Section 2: The list should tell you what kind of digest up front:
> 1. plaintext
> 2. digest (SHA1)
Done, and I've added a reference to RFC 3174.
> Section 4 reads "Upon receiving a stream header qualified by the
> 'jabber:client' namespace, a server that returns stream features MUST
> also announce support for non-SASL authentication by including the
> relevant stream feature whenever it also sends SASL authentication
> features that are safe over TLS or SSL (e.g., SASL PLAIN)."
> Saying "features that are safe over TLS or SSL" isn't quite correct. An
> implementation could allow PLAIN over an unsecured channel
> (unfortunately it does happen in the real world). An implementation may
> also support non-sasl digest and not plaintext. In which case the
> credentials are safe to travel an unsecured channel.
True. I've changed the text to read:
Upon receiving a stream header qualified by the 'jabber:client'
namespace, a server that returns stream features SHOULD also announce
support for non-SASL authentication by including the relevant stream
feature. Exactly when a server advertises the iq-auth stream feature is
up to the implementation or deployment (e.g., a server MAY advertise
this feature only after successful TLS negotiation or if the channel is
encrypted via the older SSL method).
> Section 6
> Paragraph 1, third sentence: This should be in the protocol flow
> somewhere and include an example, not just in security considerations (I
> didn't notice that error case until now).
I've described it but have not provided a protocol example, since such
examples should be clear from XMPP Core.
Other editorial comments incorporated as well.
More information about the Standards