Subject: RE: [Simple] Impending WGLC: msrp relays

From: "Orit Levin" <[email-masked]>
Date: Sun, 20 Mar 2005 12:25:18 -0800

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
> >  > >
> >  > > 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
> >  >
> >  > _______________________________________________
> >  > Simple mailing list
> >  > [email-masked]
> >  > https://www1.ietf.org/mailman/listinfo/simple
> >
> >
> >
------------------------------------------------------------------------
> >
> > _______________________________________________
> > Simple mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/simple
> 
> --
> Miguel A. Garcia           tel:+358-50-4804586
> Nokia Research Center      Helsinki, Finland

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

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 21 Mar 2005 10:28:20 +0200

Hi Orit:

I am nog bringing requirements anymore... I am discussing the current draft.

I understand that the diference between Basic and Digest is that in the 
former the password is sent in the clear whereas in Digest it isn't. 
However, the relay specification also mandates the usage of TLS when 
connecting to a relay, so no matter whether you use Basic o no, 
eavesdroppers will not see any password.

Our main goal is to avoid eavesdroppers to see passwords. I don't know 
which other trust requirements do we have (you seem to have more 
requirements than me ;-)) but your idea that the endpoints do not trust 
the relays seems a bit odd to me. Both Digest and Basic authentication 
are based on the knowledge of a common share secret, which is known by 
both parties, so both require this trust model.

/Miguel

---

From: Avshalom Houri <[email-masked]>
Date: Mon, 21 Mar 2005 11:57:16 +0200

It is a real requirement at systems that I know.
When using digest no one sees the real password.
The server only verifies that the hash value of the password is the same 
as
the stored hash value. No one can see the password itself.

Avshalom

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 21 Mar 2005 10:55:32 +0100

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

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 21 Mar 2005 12:31:42 +0200

Avshalom:

I understand you are saying. I believe you are trying to say that the 
user does not trust the MSRP relay for the storage of the password. I 
find this a bit odd, but I will leave it as is.

On the other hand, you made me think about a scenario where the 
authentication service is running in a centralized fashion (e.g., a 
central RADIUS server). The MSRP relay will need to retrieve a password 
from the central RADIUS server. And if the authentication is based 
Basic, then the interface from the MSRP relay to the RADIUS server will 
have to deliver that password (in the clear), thus, RADIUS should also 
be protected with some security.

Using Digest will allow the RADIUS server to deliver what RFC 2617 calls 
H(A1), which is a hash of the password. Then the MSRP relay need not 
know the password (but one can argue it knows the Hash used for digest).

In conclusion, I think Digest authentication has security properties 
that are needed in centralized authentication environments. In 
standalone instalations Basic authentication seems to be simpler and 
offers the same security properties than Digest.

/Miguel

Avshalom Houri wrote:

> The server only verifies that the hash value of the password is the same as