Subject: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP relays extension

From: Rohan Mahy <[email-masked]>
Date: Mon, 20 Jun 2005 18:44:07 -0700

Hi Everyone,

Despite the thread on the list from late March and early April about 
Basic vs Digest authentication, I don't feel like we came to consensus 
on this issue. First I would like to apologize for my lack of attention 
on this particular issue, and that it has remained open for so long.

The arguments in favor of Digest authentication included a number of 
incorrect assumptions (marked "I") which need to be clarified in the 
draft.  Among them:

I: Relays for user B get to see the username and password for user A.
A: This never happens.  user A only sends AUTH requests to *its* 
relays, never to the relays used to forward requests on to another 
user.

I: User B sends its password in the clear over the network.
A: Use of TLS is mandatory, user B only sends its password inside a 
TLS-protected channel.

I: The Security Area Directors will never allow this.
A: Based on preliminary discussions, I believe this will be acceptable 
to the Security ADs.  Again, use of TLS is mandatory.  This is exactly 
like the common usage of SMTP using PLAIN user authentication over a 
TLS-protected channel, which is a very widely deployed model.

I: If I use RADIUS I have to send the username and password in the clear
A: The MSRP relay can hash the password before sending to the RADIUS 
server, or send all RADIUS traffic over a protected channel.

There are two other concerns with Basic which are accurate:

1. If example.com has an inner relay and an outer relay, credentials 
for outer.example.com are revealed to inner.example.com as AUTH 
requests are forwarded to outer.example.com.  This limitation is 
clearly explained in the Security Considerations section.

2. The other issue that Avshalom brought up is that the relay 
administrator has access to the password, or an attacker who can gain 
access to the relay machine.  While the administrator could mount a 
dictionary attack on a Digest protected password, its obviously easier 
to get access to the password when it isn't hashed at all.

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.

The arguments in favor of Basic authentication are:

1. Basic authentication is much simpler to implement than Digest, and 
the authors feel that with TLS protection of the channel that its 
security is good enough. We expect MSRP AUTH to be used within a single 
administrative domain, and the limitation of the server seeing the 
plain text password is similar to the way that many email services are 
deployed with TLS.

2. Digest authentication is not a great fit to MSRP and as a result its 
not obvious what to specify for all the parameters.

What do we do?  My proposal is to go with Basic.  I have updated the 
draft leaving Basic in place.  I feel this is appropriate given the 
relative security of the base draft, and given what would be needed to 
do Digest properly.  If the consensus of the group is that we should do 
Digest instead, then I urge someone to propose specific text answering 
the questions I discuss above, that would go into the draft.

thanks,
-rohan

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

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 22 Jun 2005 08:58:41 -0700

I have not really provided much input on this issues - that is partially
because I could go either way if we could just finish this. That said, let
me outline a few points that I see as relevant to the decision....

The significant argument  I have seen made an attack where someone broke
into the relay server (or had access to it because they were the
administrator) of it and thus gained access to all the stored passwords. We
are worried about people using the information to log in as the a given user
to this relay and also, assuming the users use the same password other
places, to long on to other boxes. This is definitely an important attack to
consider. 

If we go with the Digest route, any reasonable server will end up storing
H(A1). It may do this directly or via a radius server. Now if someone gets
H(A1), the can not discover my password and long on to some other server
where I may have used the same password. However, they can use that to log
on to this same relay server as me. The last sentence is important, using
Digest, if the attacker gets my stored H(A1) then can log on as me to this
box (but not others).

Now consider the Basic+TLS approach, any reasonable implementation will
store the usual hash of password plus salt solution. If an attacker gets
this stored information, they can log on other boxes, but even more than
this, they can not log onto this box using what they learned.

Both solutions protect against the stored information being used to log on
another box and the Digest+TLS also protects against it being used to log on
the same relay. 

I'm not sure I view this as an amazing advantage for Basic+TLS - I view the
real advantage of Basic+TLS be the simplicity it brings and that much of
what Digest is designed to provide, MSRP has no use for.

Next point has to do with this being a password at all - if we think this is
something a human generates, remembers, and types in, well then it is a
password and the above attacks are worth considering. Personally, I think it
is going to be come configuration information generated by the system and
downloaded to the client then used to connect to the relay. In this form it
is far more of a cookie than a password and the above attacks are far less
interesting because there will not be other systems that use the same
password. 

Cullen

---

From: Avshalom Houri <[email-masked]>
Date: Wed, 22 Jun 2005 20:14:23 +0300

Cullen,

Not sure I understand.

In digest, the server will send a nonce
to the user thus preventing replay attacks by replacing the nonce every
time.

The hashed value stored in the server
can not be used for logging again to the server since the server will accept
only nonced passwords.

In basic authentication anyone that
has an access to the server code may get the cleartext password and do
with it whatever they want.

Avshalom

Cullen Jennings <[email-masked]>

Sent by: [email-masked]

22/06/2005 06:58 PM

To

Rohan Mahy <[email-masked]>,
"[email-masked]" <[email-masked]>

cc

Subject

Re: [Simple] OPEN ISSUE: Basic vs. Digest
authentication in MSRP        relays extension

because I could go either way if we could just finish this. That said,
let

The significant argument  I have seen made an attack where someone
broke

administrator) of it and thus gained access to all the stored passwords.
We

are worried about people using the information to log in as the a given
user

places, to long on to other boxes. This is definitely an important attack
to

consider.

where I may have used the same password. However, they can use that to
log

box (but not others).

Both solutions protect against the stored information being used to log
on

another box and the Digest+TLS also protects against it being used to log
on

the same relay.

I'm not sure I view this as an amazing advantage for Basic+TLS - I view
the

Next point has to do with this being a password at all - if we think this
is

password and the above attacks are worth considering. Personally, I think
it

downloaded to the client then used to connect to the relay. In this form
it

password.

Cullen

Simple mailing list

[email-masked]

---

From: Ben Campbell <[email-masked]>
Date: Fri, 24 Jun 2005 10:57:06 -0500

I am sensitive to the fact basic is easier to implement, simpler to  
specify, etc. However,  "accurate concern number" 1 feels like a show  
stopper.

The particular use case I imagine is that I am roaming onto someone  
else's network (a Hotel, for example) that forces all MSRP traffic  
through its relay. I might have a high-security job where my  
credentials must not be revealed to _anyone_ outside of my  
organization. What do I do?

If we go with basic for now, does that in any way preclude doing a  
followup effort on how to use digest?

On Jun 20, 2005, at 8:44 PM, Rohan Mahy wrote:

> Hi Everyone,
>
> Despite the thread on the list from late March and early April  
> about Basic vs Digest authentication, I don't feel like we came to  
> consensus on this issue. First I would like to apologize for my  
> lack of attention on this particular issue, and that it has  
> remained open for so long.
>
> The arguments in favor of Digest authentication included a number  
> of incorrect assumptions (marked "I") which need to be clarified in  
> the draft.  Among them:
>
> A: Based on preliminary discussions, I believe this will be  
> acceptable to the Security ADs.  Again, use of TLS is mandatory.   
> This is exactly like the common usage of SMTP using PLAIN user  
> authentication over a TLS-protected channel, which is a very widely  
> deployed model.
>
> A: The MSRP relay can hash the password before sending to the  
> RADIUS server, or send all RADIUS traffic over a protected channel.
>
> 1. If example.com has an inner relay and an outer relay,  
> credentials for outer.example.com are revealed to inner.example.com  
> as AUTH requests are forwarded to outer.example.com.  This  
> limitation is clearly explained in the Security Considerations  
> section.
>
> administrator has access to the password, or an attacker who can  
> gain access to the relay machine.  While the administrator could  
> mount a dictionary attack on a Digest protected password, its  
> obviously easier to get access to the password when it isn't hashed  
> at all.
>
> 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.
> - do not support auth-int, but always include the qop parameter  
> with auth
> - 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.
>
> 1. Basic authentication is much simpler to implement than Digest,  
> and the authors feel that with TLS protection of the channel that  
> its security is good enough. We expect MSRP AUTH to be used within  
> a single administrative domain, and the limitation of the server  
> seeing the plain text password is similar to the way that many  
> email services are deployed with TLS.
>
> 2. Digest authentication is not a great fit to MSRP and as a result  
> its not obvious what to specify for all the parameters.
>
>
> What do we do?  My proposal is to go with Basic.  I have updated  
> the draft leaving Basic in place.  I feel this is appropriate given  
> the relative security of the base draft, and given what would be  
> needed to do Digest properly.  If the consensus of the group is  
> that we should do Digest instead, then I urge someone to propose  
> specific text answering the questions I discuss above, that would  
> go into the draft.
>
> thanks,
> -rohan
>
>

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 25 Jun 2005 08:45:04 -0700

Consider how a password works on a UNIX system, if you get access to the
/etc/passwd file, you don't find out what my password is because the
password is not stored but instead a hashed+salt version of it is. This is
how people that implemented the Basic+TLS scheme would do it.

Now consider how Apache stores the the HTTP digest credentials. It stores
the H(A1) value which does not include the nonce. I might be wrong on this
but I think that if the attacker new the H(A1), they could compute the
response to logon to this particular realm even when a new nonce was
presented. 

Cullen 

On 6/22/05 10:14 AM, "Avshalom Houri" <[email-masked]> wrote:

> 
> Cullen, 
> 
> Not sure I understand.
> 
> In digest, the server will send a nonce to the user thus preventing replay
> attacks by replacing the nonce every time.
> The hashed value stored in the server can not be used for logging again to the
> server since the server will accept only nonced passwords.
> 
> In basic authentication anyone that has an access to the server code may get
> the cleartext password and do with it whatever they want.
> 
> Avshalom 
> 
> 
> 
> Sent by: [email-masked] 22/06/2005 06:58 PM
> To
> Rohan Mahy <[email-masked]>, "[email-masked]" <[email-masked]>
> cc
> Subject
> Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP        relays
> extension 
> 
> 
> 
> 
>

---

From: Scott Lawrence <[email-masked]>
Date: Sun, 26 Jun 2005 11:41:37 -0400

> response to logon to this particular realm even when a new nonce was

You are correct - anyone who knows H(A1) can authenticate themselves on
the server.  The reason that servers typically store the H(A1) rather
than the plaintext password is that users often use the same passwords
on multiple systems - recovering the plaintext from the H(A1) is
'computationally infeasible', so the plaintext, and thus any other
systems where the same password was used, is safe.  Since the 'realm'
component on other systems will be different, that H(A1) is not useful
to an attacker there.

-- 
Scott Lawrence, Consulting Engineer
Pingtel Corp.  http://www.pingtel.com/
+1.781.938.5306 x162 or sip:[email-masked]

---

From: Hisham Khartabil <[email-masked]>
Date: Sun, 26 Jun 2005 11:30:05 +0200

Cullen, Rohan,

You're not selling the Basic Authentication solution very well. 
Simplicity is not a good reason as far as I'm concerned. You could 
argue your same arguments for SIP Basic authentication (that Basic+TLS 
and hash+salt is enough), but we deprecated Basic still, for a reason. 
Why doesnt that reason also apply to MRSP relays?

People have concerns with Basic. Using Digest well not compromise the 
security of the system, and will make everybody happy. Unless you have 
real technical issues and concerns with using Digest, I believe we need 
to go with it.

Regards,
Hisham

On Jun 25, 2005, at 5:45 PM, Cullen Jennings wrote:

>>> acceptable
>>> name
>>> all.
>>> its

---

From: Aki Niemi <[email-masked]>
Date: Sun, 26 Jun 2005 21:15:23 +0300

Inline.

ext Hisham Khartabil wrote:
> Simplicity is not a good reason as far as I'm concerned. You could argue 
> your same arguments for SIP Basic authentication (that Basic+TLS and 
> hash+salt is enough), but we deprecated Basic still, for a reason. Why 
> doesnt that reason also apply to MRSP relays?

Comparing SIP and MSRP may not be that wise here. The SIP model differs 
from the MSRP relay model significantly, since in SIP TLS is only 
hop-by-hop, and so even with transport security, an outbound proxy would 
have full access to the Basic password.

Since in MSRP the client is supposed to have a TLS session up with the 
relay before any authentication is done, I don't see the problem.

I would also like to separate protocol security from the discussion of 
how credentials are stored in the relay. IMHO, the latter can be screwed 
up in so many ways [1] we may just as well simply concentrate on the 
former. The latter is also an implementation issue.

> real technical issues and concerns with using Digest, I believe we need 

I'm fine with Basic. I agree it's easier to implement, interoperates 
better and works fine when used in a TLS session authenticated with a 
server certificate.

Digest would be an option if TLS was somehow deemed insufficient, or too 
much of a burden. It is neither, since TLS+basic (or username/password 
in an HTML form) has been proven to work in the web, and as has been 
pointed out by various people in other threads, server certificates are 
nowadays really dirt cheap.

Cheers,
Aki

[1] Referring to the recent credit card number theft, where I'm sure 
most if not all numbers were sent via an SSL protected site.

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 26 Jun 2005 23:10:41 -0700

> organization. What do I do?

If you have a high security job then you have no business relaying your 
traffic through a hotel relay regardless of protocol.  Besides, you 
will probably use an IPsec VPN or (rarely) an SSH tunnel. Encouraging 
random relays run by folks you don't trust is just plain a bad idea.

> followup effort on how to use digest?

no.

thanks,
-rohan

>> Basic vs Digest authentication, I don't feel like we came to 
>> consensus on this issue. First I would like to apologize for my lack 
>> of attention on this particular issue, and that it has remained open 
>> for so long.
>>
>> dictionary attack on a Digest protected password, its obviously 
>> easier to get access to the password when it isn't hashed at all.
>>
>> When I originally tried to map the draft onto Digest, I was planning 
>> to do something like this:
>>
>> security is good enough. We expect MSRP AUTH to be used within a 
>> single administrative domain, and the limitation of the server seeing 
>> the plain text password is similar to the way that many email 
>> services are deployed with TLS.
>>
>> relative security of the base draft, and given what would be needed 
>> to do Digest properly.  If the consensus of the group is that we 
>> should do Digest instead, then I urge someone to propose specific 
>> text answering the questions I discuss above, that would go into the 
>> draft.
>>
>> thanks,
>> -rohan
>>
>>

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 27 Jun 2005 11:54:15 +0200

On Jun 26, 2005, at 8:15 PM, Aki Niemi wrote:

>> argue your same arguments for SIP Basic authentication (that 
>> Basic+TLS and hash+salt is enough), but we deprecated Basic still, 
>> for a reason. Why doesnt that reason also apply to MRSP relays?
>
> Comparing SIP and MSRP may not be that wise here. The SIP model 
> differs from the MSRP relay model significantly, since in SIP TLS is 
> only hop-by-hop, and so even with transport security, an outbound 
> proxy would have full access to the Basic password.
>
> how credentials are stored in the relay. IMHO, the latter can be 
> screwed up in so many ways [1] we may just as well simply concentrate 
> on the former. The latter is also an implementation issue.
>
>> security of the system, and will make everybody happy. Unless you 
>> have real technical issues and concerns with using Digest, I believe 
>> we need to go with it.
>
> I'm fine with Basic.

The question I'm trying to ask is: Are you fine with Digest also? (I 
think we can safely assume that Digest is just as good as Basic in this 
case :) ) If Digest does the job, and makes everyone happy, then we use 
it. What is the technical objection for using Digest?

> I agree it's easier to implement, interoperates better and works fine 
> when used in a TLS session authenticated with a server certificate.

I agree with those points also, but they do not address some of folk's 
concerns including storing passwords in the clear, etc.

Hisham

>
> Digest would be an option if TLS was somehow deemed insufficient, or 
> too much of a burden. It is neither, since TLS+basic (or 
> username/password in an HTML form) has been proven to work in the web, 
> and as has been pointed out by various people in other threads, server 
> certificates are nowadays really dirt cheap.
>
> Cheers,
> Aki
>
>>>>> about
>>>>> consensus
>>>>> of
>>>>> RADIUS
>>>>> credentials
>>>>> gain
>>>>> easier
>>>>> with
>>>>> and
>>>>> single

---

From: Avshalom Houri <[email-masked]>
Date: Mon, 27 Jun 2005 17:17:50 +0300

From RFC 2617:

request-digest  = <">
< KD ( H(A1),     unq(nonce-value)

":" nc-value

":" unq(cnonce-value)

":" unq(qop-value)

":" H(A2)

) <">

A1       = unq(username-value)
":" unq(realm-value) ":" passwd

--------------

So if the server has H(A1) stored and
it is compromised, the attacker is able

to login to the servers that serve
the same realm and use digest. The attacker

will have to re-ngineer client software
in order to really be able to make use

of H(A1).

However, if the server actually gets
the clear password somewhere during the

authentication (even if it was sent
via TLS) process then the attacker can use

any normal UI interface to pretend
to be that user. I doubt if this will be

acceptable for enterprises.

In addition, scenario 1 in Rohan's
email below is still very concerning

(as Ben have described and you do not
need to have a high security job

in order to be concerned about this
scenario).

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.

Avshalom

Hisham Khartabil <[email-masked]>

27/06/2005 12:54 PM

To

Aki Niemi <[email-masked]>

cc

"[email-masked]" <[email-masked]>,
Cullen Jennings <[email-masked]>, Avshalom Houri/Haifa/IBM@IBMIL

Subject

Hisham

>>> Consider how a password works on a UNIX system, if you get
access to

>>> password is not stored but instead a hashed+salt version of
it is.

>>> This is

>>> Now consider how Apache stores the the HTTP digest credentials.
It

>>> stores

>>> the H(A1) value which does not include the nonce. I might
be wrong

>>> on this

>>> but I think that if the attacker new the H(A1), they could
compute

>>>> In digest, the server will send a nonce to the user thus
preventing

>>>> replay

>>>> The hashed value stored in the server can not be used
for logging

>>>> again to the

>>>> In basic authentication anyone that has an access to the
server

>>>> code may get

>>>> Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication
in MSRP

>>>>     relays

>>>> I have not really provided much input on this issues -
that is

>>>> partially

>>>> because I could go either way if we could just finish
this. That

>>>> said, let

>>>> administrator) of it and thus gained access to all the
stored

>>>> passwords. We

>>>> are worried about people using the information to log
in as the a

>>>> given user

>>>> to this relay and also, assuming the users use the same
password

>>>> other

>>>> places, to long on to other boxes. This is definitely
an important

>>>> attack to

>>>> If we go with the Digest route, any reasonable server
will end up

>>>> storing

>>>> H(A1). It may do this directly or via a radius server.
Now if

>>>> someone gets

>>>> H(A1), the can not discover my password and long on to
some other

>>>> server

>>>> where I may have used the same password. However, they
can use that

>>>> to log

>>>> on to this same relay server as me. The last sentence
is important,

>>>> using

>>>> Digest, if the attacker gets my stored H(A1) then can
log on as me

>>>> to this

>>>> Now consider the Basic+TLS approach, any reasonable implementation

>>>> will

>>>> store the usual hash of password plus salt solution. If
an attacker

>>>> gets

>>>> this stored information, they can log on other boxes,
but even more

>>>> than

>>>> Both solutions protect against the stored information
being used to

>>>> log on

>>>> another box and the Digest+TLS also protects against it
being used

>>>> to log on

>>>> I'm not sure I view this as an amazing advantage for Basic+TLS
- I

>>>> view the

>>>> real advantage of Basic+TLS be the simplicity it brings
and that

>>>> much of

>>>> Next point has to do with this being a password at all
- if we

>>>> think this is

>>>> something a human generates, remembers, and types in,
well then it

>>>> is a

>>>> password and the above attacks are worth considering.
Personally, I

>>>> think it

>>>> is going to be come configuration information generated
by the

>>>> system and

>>>> downloaded to the client then used to connect to the relay.
In this

>>>> form it

>>>> is far more of a cookie than a password and the above
attacks are

>>>> far less

>>>> interesting because there will not be other systems that
use the

>>>> same

>>>>> on this issue. First I would like to apologize for
my lack of

>>>>> attention

>>>>> on this particular issue, and that it has remained
open for so

>>>>> long.

>>>>> incorrect assumptions (marked "I") which
need to be clarified in

>>>>> I: Relays for user B get to see the username and password
for user

>>>>> A.

>>>>> to the Security ADs.  Again, use of TLS is mandatory.
This is

>>>>> exactly

>>>>> like the common usage of SMTP using PLAIN user authentication
over

>>>>> a

>>>>> I: If I use RADIUS I have to send the username and
password in the

>>>>> clear

>>>>> planning to

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

>>>>> header

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

>>>>> plain text password is similar to the way that many
email services

>>>>> are

>>>>> 2. Digest authentication is not a great fit to MSRP
and as a

>>>>> result its

>>>>> relative security of the base draft, and given what
would be

>>>>> needed to

>>>>> do Digest properly.  If the consensus of the
group is that we

>>>>> should do

>>>>> Digest instead, then I urge someone to propose specific
text

>>>>> answering

---

From: Aki Niemi <[email-masked]>
Date: Mon, 27 Jun 2005 22:43:15 +0300

> it. What is the technical objection for using Digest?

No, I'm not fine with digest. It isn't "just as good" considering that 
it is harder to specify and implement. I think you're asking the 
question the wrong way.

> concerns including storing passwords in the clear, etc.

Like I said, that seems like a different problem, and an implementation 
issue.

Cheers,
Aki

---

From: Ben Campbell <[email-masked]>
Date: Mon, 27 Jun 2005 09:38:10 -0500

On Jun 27, 2005, at 1:10 AM, Rohan Mahy wrote:

>> I am sensitive to the fact basic is easier to implement, simpler  
>> to specify, etc. However,  "accurate concern number" 1 feels like  
>> a show stopper.
>>
>> The particular use case I imagine is that I am roaming onto  
>> someone else's network (a Hotel, for example) that forces all MSRP  
>> traffic through its relay. I might have a high-security job where  
>> my credentials must not be revealed to _anyone_ outside of my  
> If you have a high security job then you have no business relaying  
> your traffic through a hotel relay regardless of protocol.   
> Besides, you will probably use an IPsec VPN or (rarely) an SSH  
> tunnel. Encouraging random relays run by folks you don't trust is  
> just plain a bad idea.
>

If it were entirely my choice, I would never use an HTTP proxy or an  
outbound SMTP server other than my home one. But these are sometimes  
forced on me by the local network. I have visited more than one  
company that locks down everything that does not go through some  
relay that they control. If we make this choice, we are saying that  
under those conditions, I have a choice of either revealing my  
password, or not communicating. That does not seem very satisfying.

(But see my next comment before spending too much time rebutting this  
one :-)  )

>> followup effort on how to use digest?

In that case, I am willing to accept basic for now, in order to get  
this work done, as long as the issues are clearly spelled out in the  
security considerations.

>>> about Basic vs Digest authentication, I don't feel like we came  
>>> to consensus on this issue. First I would like to apologize for  
>>> my lack of attention on this particular issue, and that it has  
>>> of incorrect assumptions (marked "I") which need to be clarified  
>>> in the draft.  Among them:
>>>
>>> relays, never to the relays used to forward requests on to  
>>> another user.
>>>
>>> A: Use of TLS is mandatory, user B only sends its password inside  
>>> a TLS-protected channel.
>>>
>>> authentication over a TLS-protected channel, which is a very  
>>> widely deployed model.
>>>
>>> credentials for outer.example.com are revealed to  
>>> inner.example.com as AUTH requests are forwarded to  
>>> outer.example.com.  This limitation is clearly explained in the  
>>> Security Considerations section.
>>>
>>> obviously easier to get access to the password when it isn't  
>>> hashed at all.
>>>
>>> - 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.
>>>
>>> its security is good enough. We expect MSRP AUTH to be used  
>>> within a single administrative domain, and the limitation of the  
>>> server seeing the plain text password is similar to the way that  
>>> many email services are deployed with TLS.
>>>
>>> 2. Digest authentication is not a great fit to MSRP and as a  
>>> result its not obvious what to specify for all the parameters.
>>>
>>>
>>> the draft leaving Basic in place.  I feel this is appropriate  
>>> given the relative security of the base draft, and given what  
>>> would be needed to do Digest properly.  If the consensus of the  
>>> group is that we should do Digest instead, then I urge someone to  
>>> propose specific text answering the questions I discuss above,  
>>> that would go into the draft.
>>>
>>> thanks,
>>> -rohan
>>>
>>>

---

From: Hisham Khartabil <[email-masked]>
Date: Tue, 28 Jun 2005 03:55:08 +0200

On Jun 27, 2005, at 9:43 PM, Aki Niemi wrote:

>> think we can safely assume that Digest is just as good as Basic in 
>> this case :) ) If Digest does the job, and makes everyone happy, then 
>> we use it. What is the technical objection for using Digest?
>

Why is it harder to specify? and why is it harder to implement. You 
need to sell your arguments better. I'm not arguing for one or the 
other. I just want to make sure the the people with issues are 
satisfied with your answers.

>
>>> I agree it's easier to implement, interoperates better and works 
>>> fine when used in a TLS session authenticated with a server 
>>> certificate.
>> I agree with those points also, but they do not address some of 
>> folk's concerns including storing passwords in the clear, etc.
>
> Like I said, that seems like a different problem, and an 
> implementation issue.

It is not an implementation issue. If you use Basic, you store the 
password differently than using Digest. In any case, this was just an 
example of the concerns that people have. We need to make sure we 
address them all. (See Ben's post as another example).

Hisham

>>> username/password in an HTML form) has been proven to work in the 
>>> web, and as has been pointed out by various people in other threads, 
>>> server certificates are nowadays really dirt cheap.
>>>
>>> Cheers,
>>> Aki
>>>
>>>>>> preventing replay
>>>>>>> another
>>>>>>> over a

---

From: Hisham Khartabil <[email-masked]>
Date: Tue, 28 Jun 2005 03:57:53 +0200

On Jun 27, 2005, at 4:38 PM, Ben Campbell wrote:

>>> specify, etc. However,  "accurate concern number" 1 feels like a 
>>> show stopper.
>>>
>> your traffic through a hotel relay regardless of protocol.  Besides, 
>> you will probably use an IPsec VPN or (rarely) an SSH tunnel. 
>> Encouraging random relays run by folks you don't trust is just plain 
>> a bad idea.
>>
>
> company that locks down everything that does not go through some relay 
> that they control. If we make this choice, we are saying that under 
> those conditions, I have a choice of either revealing my password, or 
> not communicating. That does not seem very satisfying.
>

If we are aware of a problem and we are aware of the how to fix it, 
then why would we ignore such problem? Please convince me that 
specifying digest (which i think was already specified in an earlier 
version of the draft) will delay us further than this issue itself.

Hisham

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 27 Jun 2005 23:37:32 -0700

On Jun 27, 2005, at 18:57, Hisham Khartabil wrote:

> then why would we ignore such problem?

We rule problems out of scope all the time. Is MSRP useful in the 
situations where Basic is useful?  Absolutely.  This is an enormous 
proportion of the expected deployment scenarios.  As for the specific 
problem in this thread, I am aware that sending my media through a 
relay with whom I have no actual trust relationship is a problem.  A 
good way to fix that problem is to tell people very clearly in the 
draft not to do that.  That's exactly what I have done.

> Please convince me that specifying digest (which i think was already 
> specified in an earlier version of the draft) will delay us further 
> than this issue itself.

Specifying Digest is essentially trying to make a mapping which does 
not fit very well.  I feel that the ambiguity and underspecificity 
about how to do Digest for MSRP will take a long time to get right.

thanks,
-rohan

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 28 Jun 2005 07:35:11 -0700

First two side notes 1) 100% agreement with Aki. 2) I'm not sure how much I
care about any of this, I think it is Rohan not me who is trying to sell it.
I'm mostly just trying to keep people straight on the facts as best I can
make sense of them. On to my real comment ....

Like all protocol things, we should make this as simple as possible but no
simpler. TLS+Basic is simpler to understand and implement than TLS+Digest.

It seems the question revolves around is this too simple. The argument that
it is too simple revolves around the server seeing (not storing) the
password. 

It is interesting to consider how this is done today. I note that for web
applications, imap, pop and no doubt others, it seem that I personally
deliver my password inside a TLS connection to a server fairly often. The
other questions is what password is used. If this is really a password that
the user sets and types in, then that is one thing since the user likely
uses the same password on multiple systems. In every deployment I am
considering this password is a machine generated string downloaded in a
config file and is delivered back to more or less the same servers that
generated it - in this sort of case I don't see any problem with the server
seeing it.  

This is not the same as SIP because SIP works without TLS. This is something
worth noting here. MSRP to the relays really truly requires you to use TLS.
A secret or cookie is passed in the result of the AUTH. If this is not
protected by TLS, attackers can do evil things. You really do have to do the
AUTH inside a TLS connection. If it was possible to do AUTH without TLS, no
one would be suggesting Basic.

Anyway, I'm not married to any particular outcome of this discussion but I
would like to see the choice made for good technical reasons. (and I would
like to have it resolved).

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 28 Jun 2005 07:43:12 -0700

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.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 29 Jun 2005 11:35:16 -0700

On 6/27/05 6:55 PM, "Hisham Khartabil" <[email-masked]> wrote:

> Why is it harder to specify?

As Rohan's original email said - there are some questions on how to map MSRP
into HTTP digest - sending some text on that would be good if we are going
to do this. Or if we are going to create a new Digest like scheme, send text
on that.