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

[Benjamin Kaduk <[e-mail]>]

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.
> 
> > 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]".

>  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?"

-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