Subject: RE: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP relaysextension

From: "Mary Barnes" <[email-masked]>
Date: Thu, 30 Jun 2005 15:55:14 -0500

I think Basic is fine, as currently specified in the draft.  Has there
been any discussion with the security ADs/gurus to see where they might
stand on this issue (i.e are they okay with Basic)? 

Mary.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Rohan Mahy
Sent: Monday, June 20, 2005 8:44 PM
To: [email-masked] WG
Cc: Rohan Mahy
Subject: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP
relaysextension

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

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