[Standards-JIG] Re: Call for Experience: JEP-0078 (Non-SASL Authentication)

Peter Saint-Andre stpeter at jabber.org
Tue Oct 12 20:58:32 UTC 2004


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

/psa




More information about the Standards mailing list