Subject: [Simple] Impending WGLC: msrp relays

From: Robert Sparks <[email-masked]>
Date: Wed, 9 Mar 2005 09:28:50 -0600

The relay draft will undergo some minor changes as discussed in
the SIMPLE meetings this week in Minneapolis. The changes are
mostly simple editorial changes. One major change will be the
removal of the appendix describing stateless relay behavior.

This revision will be posted after the I-D blackout. When it appears,
it will be WGLCed. Please feel free to send comments against
the current draft (minus the appendix mentioned above) this week
if you have time to provide them.

RjS

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Orit Levin" <[email-masked]>
Date: Mon, 21 Mar 2005 09:30:35 -0800

The text in 9.1 is very clear about the limitations being introduced by
using Basic.

The draft says: <When used over TLS-protected channels, the only
weakness of Basic authentication in MSRP is that "inner" relays can view
the credentials used to authenticate with "outer" relays. When multiple
relays are under the administration of a single domain, this is unlikely
to be a major problem. ......>

This language is a little ambiguous because "ideally" MSRP should work
in both directions :-) which would mean that each relay can in clear see
passwords being exchanged with the others.

As the draft says, the Basic mechanism (may be somehow) can make sense
for deployments restricted to a single relay provider ... BUT even
"closed" clouds being deployed today don't build on this limitation. Not
mentioning that we are moving towards inter-domain communications. Not
mentioning that it doesn't fit the IETF spirit in general.

Orit.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Hisham Khartabil
> Sent: Monday, March 21, 2005 1:56 AM
> To: Orit Levin
> Cc: Miguel Garcia; Avshalom Houri; Simple WG
> Subject: Re: [Simple] Impending WGLC: msrp relays
> 
> Please finish your sentence below by stating the limitations of basic
> (not in general, but in this specific MSRP relay instance where TLS is
> used). If something is broken, we fix it NOW.
> 
> Regards,
> Hisham
> 
> On Mar 20, 2005, at 9:25 PM, Orit Levin wrote:
> 
> > I don't understand why we are going back and arguing about the
> > requirements at this point. Especially since the Basic
"simplification"
> > has been introduced just recently with the -10 version...
> >
> > What would be wrong with stating in the document that
> >
> > <Basic is the first standardized authentication method to be used
with
> > MSRP as specified by this spec. These are the limitations to pay
> > attention to when using Basic... Future specifications can
standardize
> > how additional authentication algorithms are applied to MSRP and
> > negotiated using the AUTH method transaction.>
> >
> > More inline.
> > Orit.
> >
> >> -----Original Message-----
> >> From: Miguel Garcia [mailto:[email-masked]]
> >> Sent: Sunday, March 20, 2005 1:26 AM
> >> To: Avshalom Houri
> >> Cc: Orit Levin; Simple WG
> >> Subject: Re: [Simple] Impending WGLC: msrp relays
> >>
> >> Avshalom:
> >>
> >> Isn't it so that, in any case, no matter whether you use Basic or
> > Digest
> >> authentication, the administrator of the relay can always see the
> > users'
> >> password?
> > [OL] No, it is not. For example, when using Digest, there is no
> > password
> > in clear that can be seen by an intermediate relay.
> >> I can imagine that the administrator has the tools and control
> >> to enable eavesdropping of password at the relay.
> > [OL] Existing commercial systems today have invested a lot of
efforts
> > to
> > design mechanisms that would prevent any possible (close to
> > unimaginable) malicious behavior. Here once again we are trying to
> > standardize a mechanism that is weaker than the existing solutions
> > today.
> >> The basic assumption
> >> is that users trust the relay, the same way that users trust
existing
> >> commertial e-mail or presence services for storing
username/password
> >> combinations.
> > [OL] There is a big difference between trusting a relay for routing
the
> > data and trusting the same relay for not looking at it.
> >>
> >> /Miguel
> >>
> >> Avshalom Houri wrote:
> >>>
> >>> Actually Orit may be raising an issue that we have not thought
> > about.
> >>> Basic authentication enables the relay administrator to see the
> >>> passwords of
> >>> the users. This is not acceptable by many organizations.
> >>>
> >>> Can we say that the relay will accept digest authentication also
or
> >> enable
> >>> an extensibility mechanism?
> >>> Adding digest authentication may be easier to do but it may not be
> >>> acceptable
> >>> to organizations like 3GPP that use different authentication
method
> > for
> >>> SIP.
> >>>
> >>> Avshalom
> >>>
> >>> [email-masked] wrote on 10/03/2005 01:06:50 AM:
> >>>
> >>>> Guys,
> >>>>
> >>>> One of the open issues mentioned during the meeting was
> > addressing
> >> the
> >>>> MSRP Relay extensibility mechanism.
> >>>>
> >>>> With the latest simplification of the authentication to be
> > limited to
> >>>> Basic only, it becomes a major topic that needs to be nailed down
> >> before
> >>>> the spec closure. (Although the Basic over encrypted hop-by-hop
> > links
> >>>> may be OK for some deployments - it will not be acceptable for
> >> others.)
> >>>>
> >>>> It is absolutely necessarily to define a mechanism that will
> > allow
> >> for
> >>>> signaling alternative authentication methods (potentially among
> > other
> >>>> features). Without it, I don't think MSRP can be deployed and
> > remain
> >>>> interoperable.
> >>>>
> >>>> Orit.
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: [email-masked] [mailto:[email-masked]]
> > On
> >>>> Behalf
> >>>>> Of Robert Sparks
> >>>>> Sent: Wednesday, March 09, 2005 7:29 AM
> >>>>> To: Simple WG
> >>>>> Subject: [Simple] Impending WGLC: msrp relays
> >>>>>
-----------------------------------------------------------------------
> > -
> >> --
> >> Miguel A. Garcia           tel:+358-50-4804586
> >> Nokia Research Center      Helsinki, Finland
> >
> >