[kitten] SASL's idea of "additional data" in a protocol

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[kitten] SASL's idea of "additional data" in a protocol

Rick van Rein (OpenFortress)
Hello,

RFC 4422 states that there may be additional data with a success.  I
don't think I have ever seen this in any protocol or mechanism.  Am I
correct that there is no reason in practice to add it to a protocol
embedding of SASL?

The text is,

   Some mechanisms specify that the server is to send additional data to
   the client when indicating a successful outcome.  Protocols may
   provide an optional additional data field in the outcome message to
   carry this data.  Where the mechanism specifies that the server is to
   return additional data with the successful outcome, the protocol
   provides an optional additional data field in the outcome message,
   and the server uses this field, the exchange is shortened by one
   round-trip:

Thanks,
 -Rick

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SASL's idea of "additional data" in a protocol

Alexey Melnikov
Hi Rick,

On 19/03/2020 08:49, Rick van Rein wrote:
> Hello,
>
> RFC 4422 states that there may be additional data with a success.  I
> don't think I have ever seen this in any protocol or mechanism.  Am I
> correct that there is no reason in practice to add it to a protocol
> embedding of SASL?

Actually, this is being used. Look for example at SCRAM (RFC 5802), the
last message from the server (containing the v= attribute) can be sent
as "additional data with success". It is always better to allow for this
in a SASL protocol profile in order to save an extra round trip. I.e. if
this feature is not supported by a protocol, the server will have to
send it as a regular SASL response, to which the client will have to
respond with an empty challenge, which will then be responded to by the
server with just successful outcome (with no data).


Best Regards,

Alexey

> The text is,
>
>     Some mechanisms specify that the server is to send additional data to
>     the client when indicating a successful outcome.  Protocols may
>     provide an optional additional data field in the outcome message to
>     carry this data.  Where the mechanism specifies that the server is to
>     return additional data with the successful outcome, the protocol
>     provides an optional additional data field in the outcome message,
>     and the server uses this field, the exchange is shortened by one
>     round-trip:
>
> Thanks,
>   -Rick
>
> _______________________________________________
> Kitten mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/kitten

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SASL's idea of "additional data" in a protocol

Rick van Rein (OpenFortress)
Hello Dave and Alexey,

> SCRAM does this, and it can be seen in profiles that support it like XMPP.

> Actually, this is being used. Look for example at SCRAM (RFC 5802),
> the last message from the server (containing the v= attribute) can be
> sent as "additional data with success".


Thanks, my feeling that this was not used at else has been falsified.  I
was beginning to wonder if I was being overzealously spec-compliant.
Apparently not :)

-Rick

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten