Subject: RE: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 28 Jun 2005 17:28:05 -0400

This is the crux of the matter. Are we admitting use cases in which there are intermediary relays that would have the opportunity to inspect Basic credentials? If so, then Basic over hop-by-hop TLS is not sufficient.

The motivation for these uses cases remains a bit murky to me, to be honest. I understand the argument that one might have a visited-network relay and a policy-enforcing relay in one's home network. At a high level, though, I tend to agree with Rohan that if you are unable to make a direct connection to a policy-enforcing relay, then the very policies that might be enforced by such a relay could be compromised by sending traffic through a visited-network relay. The odds that most sorts of visited networks are going to block VPNs, or indeed care about MSRP at all, seem quite slim to me. The sorts of visited networks that do care are likely to be unsympathetic to the policy needs of your home network.

That much said, I am ultimately not persuaded that it is so problematic to create a Digest system for MSRP. Doing so would certainly invite additional scrutiny from the Security Area, but that scrutiny is likely to be constructive. If people want to admit cases where there are intermediary relays, then I think it is unwise not to address this scenario in the protocol design.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of Orit Levin
> Sent: Tuesday, June 28, 2005 12:34 PM
> To: Cullen Jennings; Avshalom Houri; [email-masked]
> Cc: Aki Niemi
> Subject: RE: [Simple] OPEN ISSUE: Basic vs. Digest authentication
> inMSRPrelays extension
> 
> 
> I strongly support Avshalom's request for including in the 
> specification
> the ability to negotiate the security method to be used with a
> particular Relay.
> 
> We can say that Basic is MUST to implement but we can not 
> prescribe what
> level of security is going to be used in real deployments. If we want
> implementations from different vendors interoperate according to this
> standard - cutting the edges for "simplicity" will lead to opposite
> results.
> 
> I don't think that this list is the right place to have a serious
> security debate but some facts are obvious: the credentials for Basic,
> being sent in clear inside the hop-by-hop TLS connections, may be
> different for different Relays and you don't want to expose them to
> anyone who has an access to the relays in the middle. (And I hope that
> IETF is not addressing monolithic systems only that will be OK with a
> single method and a single password.)
> 
> Orit.
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Cullen Jennings
> > Sent: Tuesday, June 28, 2005 7:43 AM
> > To: Avshalom Houri; [email-masked]
> > Cc: Aki Niemi
> > Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest 
> > authentication in MSRPrelays extension
> > 
> > On 6/27/05 7:17 AM, "Avshalom Houri" <[email-masked]> wrote:
> > 
> > > In order to go ahead can we come with a way to enable a 
> > relay to offer 
> > > basic or digest or other method in its 401 response? This 
> > way servers 
> > > can be configured to use different methods according to the 
> > required 
> > > security level and clients can reject too weak method if 
> they want. 
> > > This will also enable clients that do not have enough 
> > memory/CPU and 
> > > that work in a protected environment to use only basic 
> > authentication.
> > 
> > Few trivial notes ...
> > 
> > I don't think there is a very good argument to be made that 
> > there are devices that are capable of TLS but can't do 
> > digest. (I know you are not making this argument but just 
> > tossing in this comment)
> > 
> > Thought I can live with either basic/digest I would really 
> > prefer one over both.
> > 
> > 
> > 
> > 
> > _______________________________________________
> > 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

---

From: "Orit Levin" <[email-masked]>
Date: Thu, 30 Jun 2005 09:23:33 -0700

We don't have to have both if we agree that we use Digest as the common
denominator for all purposes (including for issuing the token) instead
of Basic.

That being said, I agree that for issuing the MSRP forwarding tokens -
Basic syntax is enough. You could invent any other simple way of
exchanging a password forth and a token back - this is not exactly what
authentication is.

The draft must clarify WHAT the described Basic format is being used for
(i.e. for issuing the MSRP forwarding token only) instead of saying that
this is THE way for a Relay to authenticate a client.

Also the spec must say that in order for a Relay to securely
(confidentially) authenticate a client, additional authentication
mechanisms MAY be defined to be used with MSRP. The spec must specify
NOW how the "issuing a token Basic-based procedure" will coexist with
any other real authentication procedures that (most probably) will ALSO
use the HTTP methods and formats. (It is really about "co-existence"
rather than "negotiation".)

Orit.

> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Thursday, June 30, 2005 7:10 AM
> To: Orit Levin; [email-masked]
> Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication
> inMSRPrelays extension
> 
> 
> I can see the argument for basic does everything we need and is the
> simplest. I can see the argument for no basic is lacking and we need
> digest.
> But I'm not yet understanding why we would want both.
> 
> 
> On 6/29/05 3:33 PM, "Orit Levin" <[email-masked]> wrote:
> 
> > It seems to me that our disconnect is around what the purposeS for a
> > Relay to authenticate a certain client ARE.
> >
> > My point is that typically we will need to use BOTH Basic and Digest
> > (and may be others to come) even for the same user for the same MSRP
> > connection: first just for the proper MSRP forwarding (as the
lightest
> > means for issuing a token) and second for actually accessing a home
> > network or other valid services network.
> >
> > More inline,
> > Orit.
> >
> >> From: Peterson, Jon [mailto:[email-masked]]
> >> Sent: Tuesday, June 28, 2005 2:28 PM
> >> To: Orit Levin; Cullen Jennings; Avshalom Houri; [email-masked]
> >> Cc: Aki Niemi
> >> Subject: RE: [Simple] OPEN ISSUE: Basic vs. Digest
> >> authentication inMSRPrelays extension
> >>
> >>
> >> This is the crux of the matter. Are we admitting use cases in
> >> which there are intermediary relays that would have the
> >> opportunity to inspect Basic credentials? If so, then Basic
> >> over hop-by-hop TLS is not sufficient.
> >>
> >
> > It is OK for an intermediary MSRP relay to inspect the Basic
credentials
> > because:
> > 1. According to the spec every MSRP relay needs to use the "token"
> > mechanism and thus, by definition, it has the lowest transitive
level of
> > trust required for secure MSRP forwarding
> > 2. A network protocol specification can not prohibit network
entities
> > from implementing internal tracing features (even if available to
> > administrators only :-)
> >
> > BUT it is OK as long as some MSRP Relays (typically the home Relays)
> > have standard means of establishing a stronger level of trust with
some
> > clients that they choose to. It is better to be described as
"allowing
> > additional (e.g. home) services" rather than enforcing "policies".
> > Obviously, the credentials for this level of trust must not be
visible
> > to intermediates (even if trusted for plain MSRP forwarding).
> >
> >> The motivation for these uses cases remains a bit murky to
> >> me, to be honest. I understand the argument that one might
> >> have a visited-network relay and a policy-enforcing relay in
> >> one's home network. At a high level, though, I tend to agree
> >> with Rohan that if you are unable to make a direct connection
> >> to a policy-enforcing relay, then the very policies that
> >> might be enforced by such a relay could be compromised by
> >> sending traffic through a visited-network relay. The odds
> >> that most sorts of visited networks are going to block VPNs,
> >> or indeed care about MSRP at all, seem quite slim to me. The
> >> sorts of visited networks that do care are likely to be
> >> unsympathetic to the policy needs of your home network.
> >>
> >> That much said, I am ultimately not persuaded that it is so
> >> problematic to create a Digest system for MSRP. Doing so
> >> would certainly invite additional scrutiny from the Security
> >> Area, but that scrutiny is likely to be constructive. If
> >> people want to admit cases where there are intermediary
> >> relays, then I think it is unwise not to address this
> >> scenario in the protocol design.
> >>
> >> Jon Peterson
> >> NeuStar, Inc.
> >>
> >>> [mailto:[email-masked]]On Behalf Of Orit Levin
> >>> specification the ability to negotiate the security method
> >> to be used
> >>> with a particular Relay.
> >>>
prescribe
> >>> what level of security is going to be used in real
> >> deployments. If we
> >>> want implementations from different vendors interoperate
> >> according to
> >>> this standard - cutting the edges for "simplicity" will lead to
> >>> opposite results.
> >>>
> >>>> I don't think there is a very good argument to be made that there
> >>>> are devices that are capable of TLS but can't do digest.
> >> (I know you
> >>>> are not making this argument but just tossing in this comment)
> >>>>
> >>>> Thought I can live with either basic/digest I would really prefer
> >>>> one over both.
> >>>>
> >>>>
> >>>>
> >>>>