Folks,
I had a nice chat with Ralph Meijer, and we idly discussed replacing the
SASL profile in order to gain access to 2FA, fold in the Stream Resumption
(Florian Schmaus's design, in effect), and make it a little more
extensible, particularly with more detailed error messaging.
Since then I've found some fo these might be being addressed by work Adam
Roach and Matthew Miller are doing, so I thought I'd jot down a very
ill-thought-through design - it may very well be that Adam/M&M's design is
far superior, or it may be that we can borrow from each other to produce
something else. I'm not expecting this to be anything more than a
discussion starter.
Client sends:
<authenticate xmlns='urn:xmpp:sasl' mechanism='SASL-MECH-NAME'
[sm-id='SessionResumptionIdentifier' h='314']
>
T3B0aW9uYWwgYmFzZSA2NCBlbmNvZGVkIFNBU0wtSVIgZGF0YQ==
</authenticate>
Optional sequence of:
Server challenges:
<challenge xmlns='urn:xmpp:sasl'>
QmFzZSA2NCBlbmNvZGVkIFNBU0wgY2hhbGxlbmdlIGRhdGE=
</challenge>
Client responds:
<response xmlns='urn:xmpp:sasl'>
QmFzZSA2NCBlbmNvZGVkIFNBU0wgcmVzcG9uc2UgZGF0YQ==
</response>
Until server ends main SASL exchange with one of:
* Authentication is complete, no further action required. Possibly resumed
stream, last ack included (even if not resumed).
<success xmlns='urn:xmpp:sasl'
[ [ resumed='true' ] h='312' ]>
<success-data>
T3B0aW9uYWwgQmFzZSA2NCBlbmNvZGVkIFNBU0wgc3VjY2VzcyBkYXRh
</success-data>
</success>
Or:
* Authentication is successful, but further authentication is needed (2FA,
password change).
<continue xmlns='urn:xmpp:sasl'>
<success-data><!-- Optional -->
T3B0aW9uYWwgQmFzZSA2NCBlbmNvZGVkIFNBU0wgc3VjY2VzcyBkYXRh
</success-data>
<mechanisms>
<mechanism>HOTP</mechanism><!-- 2FA mechanism -->
<mechanism>PLAIN</mechanism><!-- Password change? -->
<mechanisms>
</continue>
In which case client sends:
<next-authenticate xmlns='urn:xmpp:sasl' mechanism='HOTP'>
MkZBIG9yIHBhc3N3b3JkIGNoYW5nZSBvciBzb21ldGhpbmc=
</next-authenticate>
And possibly enters a challenge/response game again until <success/> as
above or <failure/> as below.
Or, finally:
* Authentication (or next phase) fails, with varying forms of details
information. Note that a second-phase failure can be fairly detailed, since
the user has been partially authenticated.
<failure xmlns='urn:xmpp:sasl'>
<some-sasl-code xmlns='urn:ietf:disused:toilet:beware:leopard'/>
<optional-application-specific xmlns='urn:something:else'/>
<text>Human readable error message.</text>
</failure>
-
Note that when the SASL mechanism chosen initially is a single round-trip,
such as YAP (or PLAIN, or TLS session reuse implying authentication), and
the server chooses not to require 2FA etc, then the entire session
resumption becomes a single round-trip, as with Florian's original
proposal. Sites with different security requirements can trade round-trips
for threat mitigations as they choose.
Dave.
_______________________________________________
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
