Peter
Ralph Meijer wrote:
Hi all, While attempting to implement SASL authentication in Twisted, I discovered a discrepancy between RFC 2831 (Using Digest Authentication as a SASL Mechanism) and the examples 6.5 and 6.6 in RFC 3920 (XMPP Core) that do DIGEST-MD5 SASL authentication. The discrepancy is about Step 3 (section 2.1.3) of RFC 2831. After the server having sent a challenge in Step 1 and the client sending a response in Step 2, Step 3 is the server checking this response and sending an 'rspauth'. This is not a challenge, but extra information for subsequent authorization, sent along with the affirmation of a succesful authentication. The ACAP example in section 4 of RFC 2831 shows this. However, the IMAP example needs an extra roundtrip because there is no way in IMAP to do both an 'OK' and send along this rspauth information. Probably the IMAP example was taken to erroneously craft the example in XMPP Core. Peter Saint-Andre made mention of this error in the notes for RFC3920bis. You can find that here: http://www.xmpp.org/xmppbis.html#sasl. For the correct authentication sequence of example 6.5, step 7 is changed and steps 8 and 9 removed: Step 7: Server informs client of successful authentication and sends the [BASE64] encoded value for subsequent authentication to client: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= </success> The decoded value for subsequent authentication is: rspauth=ea40f60335c427b5527b84dbabcdfffd
smime.p7s
Description: S/MIME Cryptographic Signature
