Subject: AW: [AAA-WG]: Re: Comments on draft-ietf-aaa-diameter-sip-app-04( pre).txt

From: "Beck01, Wolfgang" <[email-masked]>
Date: Mon, 30 Aug 2004 15:56:41 +0200

Miguel Garcia wrote:
>> Pete McCann wrote
>> In section 5.2:
>>    Diameter server will respond with a Diameter Multimedia-Auth-Answer
>>    (MAA) message (step 6) with Result-Code AVP set to the value
>>    DIAMETER_MULTI_ROUND_AUTH.  The Diameter server will also include a
>>    challenge, which SIP server 2 will use to map into the
>> So, this document rules out the scenario where the SIP server chooses
>> the challenge, right?  Does this cause some backwards-compatibility problems
>> with draft-sterman, especially in light of the rsp-auth issue?  Maybe it's
>> not a problem.
>
> At least I never heard a requirement where the SIP server chooses the 
> challenge. I thought that what we want is to store the user's 
> configuration (including shared secrets) in the Diameter server. I don't 
> quite figure out what will be the role of the Diameter server if the SIP 
> server challenges the user, which is standard SIP functionality (RFC 3261).
The SIP server sends the challenge, the RADIUS server verifies it. There are
several draft-sterman..-00 deployments which work fine this way. As
draft-sterman supports AAA server challenges, interopability should be
possible.

While we are at it:

   "Therefore, a value of "auth-int" in the Digest-Qop AVP of the
   SIP-Authentication-Info AVP indicates that the Diameter client (SIP
   server) MUST compute the Digest "rspauth" parameter value at the
   Diameter client (SIP server)."

The Diameter client can't do that without the user's password or H(A1).
I am struggling with this, too. H(A1) with algorithm=MD5 is susceptible
to replay attacks, H(A1) with algorithm=MD5-sess might be secure enough
to be included into a RADIUS attribute or Diameter AVP.

>> 
>> On the issue of compatibility with draft-sterman, I note that this
>> application contains a lot more functionality than draft-sterman; the
>> capabilities to route SIP messages and download/update subscriber
>> profiles are not contemplated by draft-sterman, which is a simple
>> mapping of HTTP-Digest onto RADIUS.  Maybe this is ok, if the only
>> goal is to allow draft-sterman networks to use a Diameter back-end,
>> but maybe it should be noted that a SIP server using the SIP-Diameter
>> application cannot be supported by a RADIUS back-end.
>
> Yes, your assumption of operation is correct. I think we agreed that the 
> compatibility issues will be documented in draft-sterman, so I would 
> expect this discussion to be covered there.
Unlike diameter-sip-app, draft-sterman does not intend to cover all SIP
specific parameters. Its scope is limited to HTTP Digest Authentication.

Wolfgang

--
Wolfgang Beck
T-Systems
Internet Netzplattformen
+49 6151 937 2863
Am Kavalleriesand 3
64295 Darmstadt

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 31 Aug 2004 10:06:54 +0300

> draft-sterman supports AAA server challenges, interopability should be

Wofgang:

So, just for my understanding... Is the scenario you mentioned, the one 
that you describe in draft-sterman Section 1.3, "Scenario 1, RADIUS 
client chooses nonces" ?

If I understand correctly, the SIP server generates the nonce and the 
rest of the Digest directives (realm, qop, etc.). The Radius server is 
computing the final authentication, since it stores the user name, 
password, etc.

As I see it, this scenario is a variant of Section 5.2 in Diameter SIP 
application, where the first set of MAR/MAA commands (steps 5 and 6) are 
omitted.

Can you verify that my assumption is correct? If it is, I can add a new 
section to the Diameter SIP app. describing this scenario. I believe 
there is no impact in the protocol, since this new scenario is a subset 
of an existing one. So I believe MAR/MAA need not be modified.

- Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 31 Aug 2004 10:50:47 +0300

Now on the second issue.

> to be included into a RADIUS attribute or Diameter AVP.

I agree with your statement. The idea is not for the SIP server to store 
the user's password or H(A1). These should be stored in the Diameter server.

So what we need is: some means to transport H(A1) from the Diameter 
server to the SIP server. I think this is missing at the moment.

So I propose to crete a new AVP (whose name might be HA1) in the 
SIP-Authentication-Info. This will carry HA1 from the Diameter server to 
the SIP server, if needed. HA1 should contain the MD5 or MD5-sesssion of 
A1, as per RFC 2617.

On the other hand, you mentioned the problem of reply attacks. Well, I 
believe the interface between the Diameter client and server should be 
secure with IPsec or TLS, as per recommendations in RFC 3588, so this is 
  not a problem in Diameter. But I can add this point to the security 
considerations section.

Comments on this proposal?

---

From: Jo Hermans <[email-masked]>
Date: Tue, 31 Aug 2004 23:25:38 +0200

> Comments on this proposal?

Not directly related to the current thread, but I've met the same problem.

I have been thinking about improving the performance of
digest-authentication in large networks (long chains of SIP-proxies
and/or DIAMETER-proxies), especially in the light of a DDOS attack.
I'm talking about reqauth here, not rspauth. We're having a situation
where there's a huge amount of 'border nodes' (SIP-proxies that are as
close a possible to the user, but still under the control of the
network operator) and only very few authentication servers that
actually contain the password.

If we can use MD5-session (auth or auth-int), and the MD5 hash of the
username, realm and password is forwarded from the AAA-server to the
front-end process on the border, then we can calculate the digest in
the front-end process, so the packet doesn't have to be forwarded thru
the
entire chain, and the AAA-server (whether it's RADIUS, DIAMETER or
something else) isn't bombarded with authentication-requests. We're
seeing the limitations of AAA-server more and more, and it doesn't
always have to be a DDOS attack.

This is what is mentioned in RFC2617 (para 3.2.2.2) or in
draft-smith-sip-auth-examples-00.txt (para 3.4.3) : "The SIP server is
required to request the password, through an unspecified mechanism,
from a 3rd party authentication server, which returns a digest of the
password which can then be used to authenticate the user". Note that
it can also be a DIAMETER or RADIUS server that will be storing the
digest. The digest might be stored for as long as the password stays
the same (as long as the SIP-UA is registered, or maybe with an
expiration time).

But that digest would be H(unq(username) ":" unq(realm) " :"
password), which is the same as H(A1) in the MD5 case (or part of A1
in the MD5-sess case), so it's also vulnerable to these replay
attacks. So it should also be used with IPSEQ or TLS.

Grrr ... it's a pity that we don't have the CMS Security Application anymore.

-- 
Jo Hermans

"Eagles may soar, but weasels aren't sucked into jet engines"