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

From: Cullen Jennings <[email-masked]>
Date: Sun, 03 Jul 2005 19:53:46 -0400

On 6/30/05 9:23 AM, "Orit Levin" <[email-masked]> wrote:

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

Yes, I understand now - that makes sense.  I feel strongly that Digest is
better idea than both but don't have as strong as feeling between Basic+TLS
and Digest. 

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

---

From: Adam Roach <[email-masked]>
Date: Sun, 03 Jul 2005 23:59:01 -0500

>better idea than both but don't have as strong as feeling between Basic+TLS

I'm probably rehashing old arguments here, but I do have a reasonably 
strong feeling about this. If I want to go through my "home" relay for 
message logging purposes, but first need to go through a 
firewall-traversal relay at a client's site, I'd prefer to have the 
ability to do so without giving the client's relay an opportunity to 
intercept my "home" relay password.

/a

---

From: Aki Niemi <[email-masked]>
Date: Tue, 05 Jul 2005 18:50:08 +0300

Inline.

ext Orit Levin wrote:
> 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.

Sorry, but what? That is exactly what authentication is; I present valid 
credentials to access a resource that in this case is the MSRP 
forwarding token.

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

Are you saying that the draft should describe Basic as something else 
and not authentication? If that is the case, I don't agree with it.

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

You seem to suggest that MSRP needs a challenge-response scheme because 
there is some other authentication scheme you intend to use with it. You 
wouldn't be talking about NTLM authentication here now would you?

Cheers,
Aki

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 05 Jul 2005 13:04:01 -0400

> intercept my "home" relay password.

If we agree that the above use case is a valid use case, then I imagine this
discussion is probably over and all will agree we need to move to Digest.
Rohan had some sort of argument that amounted to "Don't do this". Can we
decide if we think this is a valid use case or not?

---

From: Avshalom Houri <[email-masked]>
Date: Tue, 5 Jul 2005 20:12:57 +0300

Cullen Jennings <[email-masked]> wrote on

I think that it is a valid use case. The average user will not know that

MSRP is sending the password on the clear over TLS.
It will also be very hard

to instruct users to use a gateway in the hotel for
example for one protocol and

not for the other. Most users do not even know what
protocol their software is

using.

Avshalom

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 5 Jul 2005 10:36:43 -0700

Avshalom,

I don't believe that the average user will go and manually configure 
some MSRP proxy they've never heard of before.  What is the use case?

Can anyone provide a *good* reason why you should be using arbitrary 
random relays and why this is reasonable from a security perspective.

I personally hope that anyone enlightened enough to have heard of MSRP 
will be at least enlightened enough to allow outbound TCP connections 
from their network.

thanks,
-rohan

On Jul 5, 2005, at 10:12, Avshalom Houri wrote:
> Cullen Jennings <[email-masked]> wrote on 05/07/2005 08:04:01 PM:
>
> MSRP is sending the password on the clear over TLS. It will also be 
> very hard
> to instruct users to use a gateway in the hotel for example for one 
> protocol and
> not for the other. Most users do not even know what protocol their 
> software is
> using.
>
> Avshalom

---

From: Aki Niemi <[email-masked]>
Date: Tue, 05 Jul 2005 20:50:03 +0300

Hi,

I don't think this is a valid use case. If we are talking about 
corporate users here (and I assume we are), I have a hard time seeing 
MSRP logged via anything other than a VPN-tunnel along with other 
traffic the users generate (such as email). And VPNs seem to pass 
firewalls quite well already.

Cheers,
Aki

---

From: Ben Campbell <[email-masked]>
Date: Tue, 5 Jul 2005 13:01:47 -0500

On Jul 5, 2005, at 12:36 PM, Rohan Mahy wrote:

> Avshalom,
>
> I don't believe that the average user will go and manually  
> configure some MSRP proxy they've never heard of before.  What is  
> the use case?
>
> Can anyone provide a *good* reason why you should be using  
> arbitrary random relays and why this is reasonable from a security  
> perspective.
>
> I personally hope that anyone enlightened enough to have heard of  
> MSRP will be at least enlightened enough to allow outbound TCP  
> connections from their network.

I think the large deployed base of HTTP proxies would tend to prove  
your hope a false one. It is _very_ common for enterprise networks to  
only allow HTTP connections via a locally controlled proxy. Why would  
you expect an enterprise firewall admin to treat MSRP any different  
that it treats HTTP?

Don't get me wrong; I'd love to see mandatory HTTP proxies go away  
too. But I am not wasting much breath on the effort to make it happen.

>> MSRP is sending the password on the clear over TLS. It will also  
>> be very hard
>> to instruct users to use a gateway in the hotel for example for  
>> one protocol and

---

From: Ben Campbell <[email-masked]>
Date: Tue, 5 Jul 2005 12:54:37 -0500

> decide if we think this is a valid use case or not?

So, I did some more thinking about this over the weekend, and it  
seems to me that we have already implied this use case by allowing  
the telescoping of AUTH. (That is, the ability to send AUTH to a  
second (or third etc) relay via the first.) What other use cases do  
we have for that mechanism other than the one Adam described? Or more  
generally, what other use cases do we have for the telescoping  
mechanism where the first and subsequent relays are all in the same  
administrative domain, so that revealing your second-relay password  
to the first relay is a non-issue?

So, my concrete proposal is that we either solve the password-reveal  
issue, or we remove the AUTH telescoping mechanism.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 5 Jul 2005 13:11:28 -0500

On Jul 5, 2005, at 12:50 PM, Aki Niemi wrote:

> corporate users here (and I assume we are), I have a hard time  
> seeing MSRP logged via anything other than a VPN-tunnel along with  
> other traffic the users generate (such as email). And VPNs seem to  
> pass firewalls quite well already.
>

I have personally worked at no less than 3 enterprise sites that  
explicitly denied the use of outbound VPN, because they believed it  
1) allowed data to leave the network they could not monitor, and 2)  
potentially created an uncontrolled path for things to come into the  
network. One of them even disallowed any analog phone lines in the  
building because people might connect modems to them, with exactly  
the same rational.

As I have mentioned several times, firewall policy that locks down  
all communication except via locally-controlled proxies is common.  
There are lots of so-called security consultants out there claiming  
it is necessary, and lots of so-called security auditors that will  
mark you down if you don't do it.

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 5 Jul 2005 11:09:42 -0700

On Jul 5, 2005, at 10:54, Ben Campbell wrote:

> So, I did some more thinking about this over the weekend, and it seems 
> to me that we have already implied this use case by allowing the 
> telescoping of AUTH. (That is, the ability to send AUTH to a second 
> (or third etc) relay via the first.) What other use cases do we have 
> for that mechanism other than the one Adam described? Or more 
> administrative domain, so that revealing your second-relay password to 
> the first relay is a non-issue?

AUTH telescoping is useful in large enterprises (same administrative 
domain) where there is an internal relay and an external relay.  The 
external relay farm services the entire company and might do additional 
logging or alerts on keywords. You only use the external relay when 
talking with someone outside your administrative domain. This is a 
fairly typical usage, and it is precisely the example that is given in 
the draft.

thanks,
-rohan

---

From: Hisham Khartabil <[email-masked]>
Date: Tue, 5 Jul 2005 20:46:57 +0200

(as a working group chair)

Ok, it is clear that people have concerns with Basic as the 
authentication mechanism for MSRP Relays. It is also clear that the 2 
people advocating Basic (Aki and Rohan) have not presented any strong 
argument against Digest nor have they clearly solved the concerns that 
people have with Basic. Digest resolves those concerns and there are no 
technical drawbacks with it.

The majority of contributors to this thread either want Digest or do 
not object to using Digest. That is rough consensus to me.

Unless you tell me you will commit suicide if Basic is not used, I am 
going to instruct the editors to rewrite the relevant sections to 
remove Basic and re-introduce Digest as the Authentication mechanism.

In the mean time, please remember that a WGLC have been issued for MSRP 
relay draft. Please send your comments in a.s.a.p.

Regards,
Hisham
SIMPLE WG co-chair

On Jul 5, 2005, at 8:09 PM, Rohan Mahy wrote:

> external relay farm services the entire company and might do 
> additional logging or alerts on keywords. You only use the external 
> relay when talking with someone outside your administrative domain. 
> This is a fairly typical usage, and it is precisely the example that 
> is given in the draft.
>
> thanks,
> -rohan
>
>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 05 Jul 2005 15:06:12 -0400

Way back at the being of this thread, Rohan put out some questions about how
to do Digest. I think it would be good to get talking about those as well as
proposed text that need to change to move to digest. If anyone wants to help
with text, as always, appreciated and the XML is at

http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple-msrp-rela
ys.xml

Rohan's questions/proposal follows - can folks comment on how resolve open
items....

On 6/20/05 6:44 PM, "Rohan Mahy" <[email-masked]> wrote:

> When I originally tried to map the draft onto Digest, I was planning to
> do something like this:
> 
> - realm is a string provided by the server. it SHOULD be the host name
> of the relay.
> - the domains parameter is ignored
> - note that the nonce algorithm based on ETags doesn't work
> - do not support auth-int, but always include the qop parameter with
> auth
> - the digest-uri parameter is the right-most URI in the To-Path header
> - the alg parameter is ???
> - the cnonce and the nonce-count MUST be sent
> - the Method from A2 is always AUTH
> - there is never a body for AUTH so A2 is just AUTH: plus the
> Request-URI
> - I have no idea what to do about MD5 vs. MD5-sess.
> - I have no idea whether the nextnonce parameter is useful here.
> - I don't think the response authentication parameter is useful at all.
>   However, the security considerations needs to describe what would or
> would not be protected here.  Remember that we have no integrity over
> the Use-Path header from client to outermost relay even if we use this,
> unless we redefine the A2 to include the value of the Use-Path header
> instead of the entity-body.

---

From: Adam Roach <[email-masked]>
Date: Tue, 05 Jul 2005 14:31:59 -0500

>>- realm is a string provided by the server. it SHOULD be the host name

Host name or domain name -- I think this would be up to the whoever 
deploys it. If they want a single password across all their MSRP relays, 
they share a common realm. I'm not sure the document needs to say too 
much about this.

>>- the domains parameter is ignored

Maybe I'm becoming senile, but I can't recall what this might be talking 
about, and RFC 2617 doesn't give me any clues.

>>- note that the nonce algorithm based on ETags doesn't work

So authentication will likely need to be stateful.

>>- do not support auth-int, but always include the qop parameter with

Sounds reasonable. We can always add an S/MIME mechanism if we need 
integrity protection.

>>- the digest-uri parameter is the right-most URI in the To-Path header

Yes.

>>- the alg parameter is ???

MD5, probably (modulo any discussions we have on MD5-sess handling). I 
think we want to be able to re-use as much code as possible from any SIP 
digest implementations people have in their clients.

>>- the cnonce and the nonce-count MUST be sent

Sounds good.

>>- the Method from A2 is always AUTH

I agree, in a round-about sort of way. It should always match the 
method, and we're doing authentication in AUTH requests.

>>- there is never a body for AUTH so A2 is just AUTH: plus the

Yep

>>- I have no idea what to do about MD5 vs. MD5-sess.

The handling of session mode in RFC 2617 is extremely ambiguous. I have 
poked and prodded the HTTP community and key players within it to try to 
get some clarification, and the net result seems to be that no one 
really cares because no one really implements it. (For the morbidly 
curious, you can read my summary of the problem at 
http://lists.w3.org/Archives/Public/ietf-http-wg/2004OctDec/0039.html). 
Until this issue is clarified, I don't think specifying MD5-sess is 
viable, since it is fundamentally unimplementable.

>>- I have no idea whether the nextnonce parameter is useful here.

I believe it is. The server can send nextnonces in the response to AUTH 
request which the client can then use when they refresh their AUTH 
binding -- this reduces all non-initial AUTH requests to one round trip 
instead of two.

>>- I don't think the response authentication parameter is useful at all.

Agreed.

>>would not be protected here.
>>

I don't think we're looking for an integrity protection mechanism here; 
I think we're looking for an authentication mechanism. It's fine with me 
if the security section basically says, "the use of digest 
authentication in MSRP provides no integrity protection, and is to be 
used as an authentication mechanism only."

/a

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 5 Jul 2005 18:05:18 -0700

> too. But I am not wasting much breath on the effort to make it happen.

If you are "inside" an enterprise network then typically you have 
credentials to its enterprise resources and would only use the 
enterprise MSRP relays.

I have never used a hotspot or hotel internet access provider that 
required me to use their HTTP proxy or did not allow me to make 
outbound TCP connections.  For the previous 7 years I travelled 
extensively and was able to connect using SSH port forwarding in a 
number of situations where my colleagues could not get their VPN 
software to work.

Outbound TCP works on public networks.  If you managed to get onto a 
private network you would need credentials to use their relay anyway.  
Why use another relay in addition?

thanks,
-rohan

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 5 Jul 2005 18:35:48 -0700

On Jul 5, 2005, at 11:46, Hisham Khartabil wrote:

> people have with Basic. Digest resolves those concerns and there are 
> no technical drawbacks with it.

1) Done is a feature and perfect is the often the enemy of the good.  
The draft is done now if Basic is acceptable.   "Not done" is a 
technical drawback.  I raised several open issues with how you would 
map Digest to MSRP which are not resolved.  More issues will crop up if 
we actually write text.

2) This disagreement appears to be between a very small number of 
people.  The main desire for wanting Digest appears to be a use case 
(multiple relays per side in different administrative domains) that 
still does not have a well justified motivation.

This doesn't seem like much of a consensus to me.

> remove Basic and re-introduce Digest as the Authentication mechanism.

I'm not planning to commit suicide, but my IETF work is currently 
happening at the expense of paid consulting work.  Since I don't have 
credible text on the semantics and syntax of all the Digest parameters, 
nor a reasonable section for the Security Considerations section, its 
likely that I would just pass the baton to another editor.

The reason that I did not "simply" finish the Digest specification 
earlier in the life of the draft was because as I dug deeper into it it 
seemed like a poorer and poorer fit.

thanks,
-rohan

> In the mean time, please remember that a WGLC have been issued for 
> MSRP relay draft. Please send your comments in a.s.a.p.
>
> Regards,
> Hisham
> SIMPLE WG co-chair
>
>>> we have for that mechanism other than the one Adam described? Or 
>>> more generally, what other use cases do we have for the telescoping

---

From: Adam Roach <[email-masked]>
Date: Tue, 05 Jul 2005 23:21:47 -0500

Rohan Mahy wrote:

> For the previous 7 years I travelled extensively and was able to 
> connect using SSH port forwarding in a number of situations where my 
> colleagues could not get their VPN software to work.

I'm not sure it's realistic to expect all MSRP users to be as 
sophisticated as you at circumventing administrative policies.

In any case, if that kind of circumvention were the means by which we 
expected firewall traversal to be performed, we would be specifying the 
use of port 80 for MSRP.

> Why use another relay in addition?

Imagine my employer is a public company, and they have a policy of 
logging all messages sent to and from my company-owned machine as a part 
of Sarbanes-Oxley record keeping. Alternately, imagine I'm a securities 
broker, and my company is required to log messages I send as a part of 
SEC regulations. These are realistic use cases that would 
administratively force me to send my messages through my company's relay.

Further imagine that, in the course of business, I travel to customers' 
sites from time to time. Imagine those customers allow access only 
through designated proxies specific to the protocols they allow to pass. 
Perhaps they allow instant message sessions, but -- as a matter of 
administrative policy -- log all such inbound and outbound messages, and 
consequently require the use of their MSRP relay. I'm not going to argue 
that this is a reasonable thing for them to be doing; however, I can 
cite two different customers that our company currently has that have 
network configurations that are substantially similar to that 
description (modulo the use of proprietary IM protocols). I have spent 
time on their networks, and been forced to operate through their IM 
relays to perform instant messaging sessions. It is unrealistic to 
expect that they will change their administrative policy once MSRP is 
deployed, even if you and I think it's a stupid policy. In fact, I fully 
expect them to deploy MSRP relays that continue to allow them to log 
instant messages as they currently are doing.

So you can say the use cases arise out of stupid regulations and stupid 
administrative policies -- and I can't disagree with you.  However, I 
don't think it's realistic to assert that use cases involving relays in 
different administrative domains actually won't arise.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 05 Jul 2005 23:43:03 -0500

> 1) Done is a feature and perfect is the often the enemy of the good.

I agree with your statement.

It does not apply to the situation at hand.

I am confident that basic authentication does not rise to the level of 
"good," and I hesitate to suggest that digest authentication is 
"perfect." I would characterize them more as "broken" and "acceptable," 
respectively.

> map Digest to MSRP which are not resolved. 

If you're referring to the list that Cullen re-posted earlier today, I 
don't think they're intractible or even difficult, especially once you 
consider that all we're trying to do here is authenticate users, and not 
provide any level of integrity protection (which is where most of the 
questions you had seemed to stem from).

In fact, the answers seem obvious to me: use a realm appropriate to the 
scope of the password (equivalent relays in a single domain); don't 
worry in any way about integrity (request or response); use MD5 to 
provide code re-use from SIP clients; don't use MD5-sess because it's 
aggressively underspecified; require cnonce and nonce-count; use the 
request method as the method; nextnonce use is optional and useful; and 
response authentication makes no sense. I agree that the text remains to 
be written, but as far as I can tell, the "open issues" have very 
straightforward answers.

/a

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 5 Jul 2005 21:47:02 -0700

> sophisticated as you at circumventing administrative policies.

I wasn't circumventing anything.  I just made an outbound TCP 
connection to the default port.  It could have been trivially blocked, 
but nobody bothered because I was using public hotspots or hotel 
networks.

> expected firewall traversal to be performed, we would be specifying 
> the use of port 80 for MSRP.

Since it wasn't necessary to circumvent anything to make an outbound 
TCP connection from a hotspot I don't think it is necessary or useful 
to use port 80 for MSRP.

> logging all messages sent to and from my company-owned machine as a 
> part of Sarbanes-Oxley record keeping. Alternately, imagine I'm a 
> securities broker, and my company is required to log messages I send 
> as a part of SEC regulations. These are realistic use cases that would 

YES.  You need to send your messages through ***YOUR*** company's 
relay.  I have no problem with this.

> Further imagine that, in the course of business, I travel to 
> customers' sites from time to time. Imagine those customers allow 
> access only through designated proxies specific to the protocols they 
> allow to pass. Perhaps they allow instant message sessions, but -- as 
> a matter of administrative policy -- log all such inbound and outbound 
> messages, and consequently require the use of their MSRP relay. I'm 
> not going to argue that this is a reasonable thing for them to be 
> doing; however, I can cite two different customers that our company 
> currently has that have network configurations that are substantially 
> similar to that description (modulo the use of proprietary IM 
> protocols). I have spent time on their networks, and been forced to 
> operate through their IM relays to perform instant messaging sessions. 
> It is unrealistic to expect that they will change their administrative 
> policy once MSRP is deployed, even if you and I think it's a stupid 
> policy. In fact, I fully expect them to deploy MSRP relays that 
> continue to allow them to log instant messages as they currently are 
> doing.

If you have to log all your messages to Sarbanes-Oxley, you will also 
be required to use a VPN to go directly to your company.  When you use 
the VPN you still only go through *YOUR* companies relay.

Even if your company screwed up somehow, your company relay would have 
no reason to trust AUTH requests that came from an untrusted relay in 
another domain.  How would your relay make such an authorization 
decision?

thanks,
-rohan

> So you can say the use cases arise out of stupid regulations and 
> stupid administrative policies -- and I can't disagree with you.  
> However, I don't think it's realistic to assert that use cases 
> involving relays in different administrative domains actually won't 
> arise.
>
> /a

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 5 Jul 2005 21:59:41 -0700

On Jul 5, 2005, at 21:43, Adam Roach wrote:

> "perfect." I would characterize them more as "broken" and 
> "acceptable," respectively.

I guess its not surprising that we disagree.

> consider that all we're trying to do here is authenticate users, and 
> not provide any level of integrity protection (which is where most of 
> the questions you had seemed to stem from).
>
> In fact, the answers seem obvious to me: use a realm appropriate to 
> the scope of the password (equivalent relays in a single domain); 
> don't worry in any way about integrity (request or response); use MD5 
> to provide code re-use from SIP clients; don't use MD5-sess because 
> it's aggressively underspecified; require cnonce and nonce-count; use 
> the request method as the method; nextnonce use is optional and 
> useful; and response authentication makes no sense. I agree that the 
> text remains to be written, but as far as I can tell, the "open 
> issues" have very straightforward answers.

The list I came up with is a short list of the semantics that need to 
be specified.  I did not make an exhaustive list of the new threats we 
would need to account for and what information we would need to include 
in Digest in this case. For example, if you are sending an AUTH request 
through a relay in another administrative domain it think it would be 
irresponsible to skip integrity protection over the Use-Path header.

I don't think the security in the use case you are trying to motivate 
is "straightforward" if you use Digest.

thanks,
-rohan

---

From: Adam Roach <[email-masked]>
Date: Wed, 06 Jul 2005 00:26:26 -0500

Rohan Mahy wrote:

> be required to use a VPN to go directly to your company.

And if the site that I've visited blocks outbound VPNs because they 
allow insufficient monitoring? Ben has already asserted that he has 
worked with one company that does so. I agree that what you are 
proposing is one potential solution that can be applied in specific 
scenarios. However, I assert by way of actual deployments that there are 
realistic scenarios in which it can not be applied but which multiple 
relays in differing administrative domains can.

> another domain.  How would your relay make such an authorization decision?

How do HTTP servers trust Digest authentication that arrives by way of 
an HTTP proxy? If my understanding is correct, they issue a challenge, 
and validate that the response to the challenge demonstrates possession 
of a shared secret. What am I missing? How does this not apply in the 
multi-relay case?

/a

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 5 Jul 2005 22:57:27 -0700

On Jul 5, 2005, at 22:26, Adam Roach wrote:

> scenarios. However, I assert by way of actual deployments that there 
> are realistic scenarios in which it can not be applied but which 
> multiple relays in differing administrative domains can.
>
>> Even if your company screwed up somehow, your company relay would 
>> have no reason to trust AUTH requests that came from an untrusted 
>> relay in another domain.  How would your relay make such an 
>> authorization decision?
>
>
> and validate that the response to the challenge demonstrates 
> possession of a shared secret. What am I missing? How does this not 
> apply in the multi-relay case?

HTTP operates very differently.  The HTTP Digest challenge is for a 
specific resource returned in a body that the User Agent is requesting. 
  The HTTP server can apply response integrity to this body.  If TLS is 
used, there is a command to the relay that tells it to get out of the 
way and just complete the TLS connection.  Many proxies don't need to 
authenticate the user to work. A large number of them just record every 
transaction and watch for viruses and various other nasty things.

MSRP authentication is used to fetch a forwarding URI that is supposed 
to remain secret.  The provisions that prevent against open relays 
depend on trusting all the nodes on your "side" and verifying that the 
other side provided one of the secret URIs you provided.  Relays will 
also verify the source of messages from the forwarding URI comes over 
the same path.  This is authenticating for a very different reason and 
relying on a very different set of trust assumptions than an HTTP 
proxy.

I'll point out that Jabber does not support arbitrary intermediaries 
and they are successfully deploying in plenty of banks, hospitals, and 
all the other regulated environments that have been cited as use cases.

thanks,
-rohan

---

From: Adam Roach <[email-masked]>
Date: Wed, 06 Jul 2005 05:21:04 -0500

Rohan Mahy wrote:

> other side provided one of the secret URIs you provided.

I think the fallacy here is that you're viewing "trust" as an 
all-or-nothing proposition. It's not; otherwise, there would be no 
objection to requiring the use of your Social Security number, date of 
birth, current mailing address, and the number and date of expiration of 
a major credit card in the authentication requests.

There's a huge gulf between trusting a relay to route messages to and 
from my current location on my behalf for the duration of a session 
without divulging the information necessary to perform such routing and 
trusting a relay to not divulge my password which changes on a 
semi-annual basis (if that frequently).

> all the other regulated environments that have been cited as use cases.

So define the SDP syntax necessary to set up Jabber sessions and be done 
with it. Or did we go down this path because we thought we could do better?

/a

---

From: Ben Campbell <[email-masked]>
Date: Wed, 6 Jul 2005 09:23:24 -0500

On Jul 6, 2005, at 12:57 AM, Rohan Mahy wrote:

> I'll point out that Jabber does not support arbitrary  
> intermediaries and they are successfully deploying in plenty of  
> banks, hospitals, and all the other regulated environments that  
> have been cited as use cases.

It is not the support of arbitrary intermediaries that is being  
argued here. We are arguing about a potential security issue that is  
created by the support of arbitrary intermediaries. That's why I  
argued that we should either fix the password leaking issue, or we  
should disallow arbitrary chains of relays.

But, to your point, there are certainly a lot of successful jabber  
deployments. There are also a lot of areas where deployment will  
fail. Can you describe how jabber would work in Adam's scenario?

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 6 Jul 2005 07:52:44 -0700

On Jul 6, 2005, at 3:21, Adam Roach wrote:

> Rohan Mahy wrote:
>
>> MSRP authentication is used to fetch a forwarding URI that is 
>> supposed to remain secret.  The provisions that prevent against open 
>> relays depend on trusting all the nodes on your "side" and verifying 
>> that the other side provided one of the secret URIs you provided.
>
> birth, current mailing address, and the number and date of expiration 
> of a major credit card in the authentication requests.
>
> without divulging the information necessary to perform such routing 
> and trusting a relay to not divulge my password which changes on a 

So you are OK with forgery, spam, and session hijacking as long as you 
don't have to provide your credit card number, etc...?

There is text in the relay document right now that describes the 
process for authorizing an AUTH request.  If you think you can send 
text that credibly (not perfectly) defines new authorization language 
for this section and a threat model and security considerations that 
addresses spam, open relays, DoS, forgery, and session hijacking then 
more power to you.

If you think you can do that, then please send text, preferably in 
xml2rfc format.

>> and they are successfully deploying in plenty of banks, hospitals, 
>> and all the other regulated environments that have been cited as use 
>> cases.
>
> So define the SDP syntax necessary to set up Jabber sessions and be 
> done with it. Or did we go down this path because we thought we could 
> do better?

I recall that we went down this path because some people said it would 
only take a month or two to define this protocol.

thanks,
-rohan

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 6 Jul 2005 07:57:58 -0700

On Jul 6, 2005, at 7:23, Ben Campbell wrote:

> It is not the support of arbitrary intermediaries that is being argued 
> here. We are arguing about a potential security issue that is created 
> by the support of arbitrary intermediaries. That's why I argued that 
> we should either fix the password leaking issue, or we should disallow 
> arbitrary chains of relays.
>
> deployments. There are also a lot of areas where deployment will fail. 
> Can you describe how jabber would work in Adam's scenario?

Jabber won't work in Adam's scenario, but they are still successfully 
selling in the types of real accounts that Adam cites.

thanks,
-rohan

---

From: Adam Roach <[email-masked]>
Date: Wed, 06 Jul 2005 17:00:37 -0500

> If you think you can do that, then please send text, preferably in 

I will endeavor to get such text together this week or early next.

If I fail to do so, I'm willing to entertain moving the current draft 
forward with Basic authentication, given that the document includes 
appropriate warnings about applicability (e.g. only to be used over a 
single, TLS-protected hop), and that the document leaves open the option 
to add, at a future date, an additional authentication mechanism that 
can support multiple administrative domains.

/a

---

From: Aki Niemi <[email-masked]>
Date: Thu, 07 Jul 2005 07:14:40 +0300

Hi,

Since this seems to be the most detailed description of the "multiple 
authoritive domains" use case that I've seen yet, I'll adress it here 
inline.

> administratively force me to send my messages through my company's relay.

This is all understood, and my understaning is that MSRP, like email and 
web traffic would be sent via the same VPN to the company network, 
logged and only after that sent to the outside world. I'm sure many of 
us have done or dealt with this sort of thing for years now.

> description (modulo the use of proprietary IM protocols). 

Right. I think this sort of configuration is very commonplace.

> I have spent 

The key question to ask here is: What identity are you using when 
working inside those companies?

If you are using an external identity, why on earth would they be 
logging that traffic? What does Sarbanes-Oxley have that mandates 
logging foreign comany communication?

I have a hard time buying this use case simply because I don't believe 
logging is necessary in two or more places at the same time. Unless this 
is an identity that has some serious split personality issues...

> different administrative domains actually won't arise.

I believe we started with that model, so I won't disagree with you here. 
However, the moidel we started with included 0 to 2 relays per MSRP 
session, meaning that there were a maximum of two different 
administrative domains in play.

We are now moving into a model that includes 0 to 4 or more relays per 
MSRP session. Meaning there are possibly four or more administrative 
domains involved in the MSRP session.

I am concerned about this constant feature creep, especially since we 
are already a decade late with this work.

Cheers,
Aki