Re: [mile] Benjamin Kaduk's Discuss on draft-ietf-mile-xmpp-grid-09: (with DISCUSS and COMMENT)

[Peter Saint-Andre <[e-mail]>]

On 1/24/19 6:04 AM, Alexey Melnikov wrote:
> Hi Dave,
> 
> On Thu, Jan 24, 2019, at 12:43 PM, Dave Cridland wrote:
>> On Thu, 24 Jan 2019 at 12:04, Alexey Melnikov <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>     Hi Benjamin,
>>     > I also think this document does not adequately justify
>>     restricting to just
>>     > the EXTERNAL and SCRAM families of SASL mechanisms;
>>
>>     I want to push back on this. The document is adding new
>>     requirement on top of what RFC 6120 requires, this is effectively
>>     new mandatory to implement SASL mechanisms for use XMPP with
>>     grids. Ideally this would be a single SASL mechanism, but I think
>>     one password based and one X.509 based is a good compromise here.
>>
>>
>> So I see Benjamin's point here. The document does introduce a new MTI
>> SASL mechanism cohort of EXTERNAL, SCRAM-SHA1, and SCRAM-SHA-256. This
>> is fine, but one has to wonder why we don't do this universally
> I think any effort to update RFC 6120 needs to proceed independently: it
> can't hold this document hostage.
> 
>> - I might try to address this. (RFC 6120 has an MTI of SCRAM-SHA1,
>> EXTERNAL, and PLAIN+TLS for comparison).
>>
>> But as Benjamin says, it also mandates their exclusive usage. From §8.3.1:
>>
>>    completing the TLS handshake.  The XMPP-Grid Controller MUST
>>    authenticate the XMPP-Grid Platform either using the SASL EXTERNAL
>>    mechanism [RFC4422] or using the SASL SCRAM mechanism (with the
>>    SCRAM-SHA-256-PLUS variant being preferred over the SCRAM-SHA-256
>>    variant and SHA-256 variants [RFC7677] being preferred over SHA-1
>>    varients [RFC5802]).  XMPP-Grid Platforms and XMPP-Grid Controllers
>>
>> (Also, typo in "varients").
>>
>> There are, indeed, other SASL mechanisms which could be used to good
>> effect here - and indeed weaker ones that might be appropriate in some
>> circumstances. But, as written, the document prohibits these.
> 
> I suspect prohibition of others is not intentional. So what is the best
> way of addressing this? Change the MUST to the SHOULD and possibly
> change "MUST authenticate" to "SHOULD support"?

Ben already proposed some text:

  I think we could move away from the "MUST authenticate [...] using"
  language to a combination of "MUST authenticate using a mechanism that
  provides strong authentication, transport encryption, ...", and "in
  order to establish a common baseline for XMPP-Grid usage, participants
  MUST implement [EXTERNAL and SCRAM]".

Something like that seems sensible.

Peter