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

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Mon, 4 Mar 2019 21:25:23 +0000

Apologies for the prolonged delay in responding.  Please see below:

On 1/24/19, 06:39, "Benjamin Kaduk" <[email-masked]> wrote:

    On Thu, Jan 24, 2019 at 12:04:31PM +0000, Alexey Melnikov wrote:
    > Hi Benjamin,
    > 
    > Thank you for your comments.
    > 
    > I will let editors reply to your comments, but I will quickly comment one part of your DISCUSS:
    > 
    > On Thu, Jan 24, 2019, at 3:59 AM, Benjamin Kaduk wrote:
    > > ----------------------------------------------------------------------
    > > DISCUSS:
    > > ----------------------------------------------------------------------
    > > 
    > > In the vein of Alissa's comments, I think this document does not adequately
    > > present the normative requirements for an implementation of the "XMPP
    > > Grid".  As far as I can tell, these requirements are just relating to the
    > > communications security measures used to protect XMPP traffic, per Section
    > > 8.3.  (Adhering to the MTI and MTN requirements of RFC 6120 does not seem
    > > like a new requirement.)  The main bulk of the document consists of
    > > examples that show how to use standard XMPP functionality to discover
    > > pubsub streams that convey data (types) that are of relevance for the types
    > > of behavior that MILE is interested in (e.g., security incident reporting
    > > and discovery), with inline mention of which XMPP features are used to
    > > negotiate and discover the streams in question.  (Several of my comments
    > > are related to this Discuss point.)
    > 
    > I think you and Alissa are right that the document needs to be clearer on whether it just relies on RFC 6120 and various XEP requirements or whether it adds any of its own.
[NCW] I have updated the draft to make it explicit that it solely relies on XMPP....nothing new is added other than implementation guidelines and applicability to sharing security information.
    > 
    > > 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.
    
    Dave has correctly inferred that my objection is to the "mandatory to use"
    -- these are fine mandatory-to-implement choices.  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]".
[NCW] That is fair.  I've removed the offending sentence and also made more clear the MTI
For SASL EXTERNAL or SCRAM.
    
    >  there are other
    > > mechanisms in use that provide equivalent or better security properties,
    > > and this sort of unjustified restriction is detrimental to the evolution of
    > > the Internet.
    > 
    > Let's not exaggerate here. If you want to suggest one or two alternative choices for mandatory to implement SASL mechanism for XMPP grids, I think you need to make a better argument in front of the WG.
    
    (possibly OBE) My point here is something like "suppose I already have
    Kerberos set up, or whatever the latest hotness in authentication is.  Why
    do I have to set up some SCRAM infrastructure or try to shim my thing into
    EXTERNAL instead of using it as native SASL?"
[NCW] Hopefully the updates address this, if not, please provide suggestions to improve intent for interoperability given what XMPP has defined.
    
    -Benjamin
    
    > > The current requirements on SASL mechanisms also seem inconsistent with the
    > > claims in the threat model that the controller can obtain credentials to
    > > allow impersonation of platforms; RFC 5802 (SCRAM) is quite explicit that
    > > "The server does not gain the ability to impersonate the client to other
    > > servers", and my understanding is that usage of EXTERNAL is generally not
    > > susceptible to this threat.  (A bit more discussion in the COMMENT section.)
    > 
    > I agree that this needs to be reviewed.
    > 
    > Best Regards,
    > Alexey

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 4 Mar 2019 19:55:59 -0700

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 <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>     Hi Benjamin,
>>     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