Subject: RE: [[email-masked]: Re: [SIP] draft-calhoun-sip-aaa-req]

From: "Christian Huitema" <[email-masked]>
Date: Wed, 3 Jan 2001 10:01:12 -0800

Pat,

There are many different ways to solve the securing of SIP exchanges,
and it is very unclear that we need to use the Radius/AAA infrastructure
in any but a limited number of cases. The basic use of SIP is
end-to-end, not tied to the network topology; there is little reason to
use the network-login credentials in the end-to-end case; this would be
about as natural as using Radius inside an e-mail client. In an
end-to-end world, we should aim primarily for public-key certicates, not
Radius like checks.

SIP already includes quite a few tools in the box, both for end-to-end
and proxy authentication. The working group is currently fighting a
creeping task overload through addition of out-of-charter items. We
should refrain from adding to that overload.

-- Christian Huitema

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Wednesday, January 03, 2001 8:06 AM
> To: Henning G. Schulzrinne
> Cc: Pat Calhoun; Michael Thomas; SIP List
> Subject: Re: [[email-masked]: Re: [SIP] 
> draft-calhoun-sip-aaa-req]
> 
> 
> > Instead of re-casting the SIP request into another format and
> > translating status codes between protocols, why not just 
> proxy the SIP
> > request to whatever database/server decides whether the person has
> > subscribed to this service? 
> > 
> > INVITE sip:traffic SIP/2.0
> > To: sip:traffic
> > From: sip:[email-masked]
> 
> For the following reasons:
> 
> 1. In existing AAA networks, the home AAA server, sometimes 
> refered to as the
> AAAH, is responsible for responding with authorization 
> information. This
> authorization information typically contains a subset of the 
> user's profile,
> for a particular service.
> 
> 2. Existing security relationships are setup between the AAA 
> servers, as part
> of some contractual agreement, and the carriers want to minimize such
> relationships. Therefore, the number of AAA servers in the 
> networks are MUCH
> smaller than the number of SIP servers in the network.
> 
> 3. Future messages between the mobile and the SIP server in 
> the foreign
> network still need to be authenticated. Once authorized, the 
> carriers want to
> minimize latency in all SIP messages for that particular 
> session (whice occurs
> due to the fact that the AAAH acts as a KDC). If a SIP server 
> at the home
> network was involved, it would have to be contacted for all 
> future messages as
> well. In topologically distant, or backhaul links that are 
> congested, the
> latency could be high.
> 
> 4. If a Home SIP server approved an invite, as you suggest 
> above, and the
> foreign network could not provide the service, how would this 
> be communicated?
> In AAA, the accounting message is separate from the
> authentication/authorization message to allow for such failures.
> 
> 5. More reasons, if needed.
> 
> Of course, one can hack SIP to do all of the above, but the 
> above already
> works within the AAA infrastructure. Seems more logical to 
> keep SIP as simple
> as possible, and simply re-use what exists for AAA, 
> especially if the penalty
> is relatively small (e.g. translating an error code).
> 
> > (A separate question is whether non-global SIP URI are a 
> good idea, but
> > that's a bit beyond this thread.)
> 
> That's out of my league :(
> 
> PatC
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Matt Holdrege <[email-masked]>
Date: Wed, 03 Jan 2001 11:22:42 -0800

>end-to-end world, we should aim primarily for public-key certicates, not

It's not simply authorizing a call, as you say that can be end-to-end. But 
advanced services from any type of IP server (or even an IN SCP 
potentially, speaking SIGTRAN perhaps) could be involved in a SIP call. 
Each instance of a service being provided may need to be authorized and 
accounted for and the user must be authenticated. In certain networks a 
significant back-end system will handle AAA for such user actions.

>should refrain from adding to that overload.

I don't think anyone is proposing adding to or modifying SIP. Rather we are 
collecting AAA requirements from the people who should know the best how 
SIP networks will be deployed.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 3 Jan 2001 12:02:37 -0800 (PST)

> significant back-end system will handle AAA for such user actions.

   Again, you _could_ do that, but you could just as easily
   build the authentication/authorization logic into the
   proxy/UA. NAS routers typically do not have or
   want a disk and/or programming environment. I
   don't think the same set of constraints are
   pertinent to SIP. Indeed, it seems to be quite
   the opposite.

	    Mike