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

From: "Gross, Gerhard" <[email-masked]>
Date: Wed, 3 Jan 2001 11:30:31 -0800

> In an end-to-end world, we should aim primarily
> for public-key certicates, not Radius like checks.

As discussed in
http://search.ietf.org/internet-drafts/draft-gross-sipaq-00.txt

Gery

        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
        X                                         X
        X    Gerhard W. Gross, Ph.D.              X
        X    Intel                                X
        X    2111 NE 25th Ave                     X
        X    Hillsboro, OR 97124-5961, USA        X
        X    Policy Architecture Group            X
        X      - Internet and Communication Lab   X
        X    phone:    (503) 264-6389             X
        X    fax:      (503) 264-3483             X
        X    email:    [email-masked]    X
        X                                         X
        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

> -----Original Message-----
> From: Christian Huitema [mailto:[email-masked]]
> Sent: Wednesday, January 03, 2001 10:01 AM
> To: Pat Calhoun; Henning G. Schulzrinne
> Cc: Michael Thomas; SIP List
> Subject: RE: [[email-masked]: Re: [SIP] 
> draft-calhoun-sip-aaa-req]
> 
> 
> 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
> 

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

---

From: "Tom Tang" <[email-masked]>
Date: Wed, 3 Jan 2001 11:41:19 -0800

I'm curious as to why everybody is stating that SIP is an end-to-end 
 protocol.  SIP proxies may need to modify SIP message payloads AFAIK.
 If this is true, don't we also need AAA on a PHB ?  Cheers.

 - Tom Tang

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Gross, Gerhard
Sent: Wednesday, January 03, 2001 11:31 AM
To: SIP List
Subject: RE: [[email-masked]: Re: [SIP] draft-calhoun-sip-aaa-req]

As discussed in

Gery

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 3 Jan 2001 12:31:25 -0800 (PST)

> http://search.ietf.org/internet-drafts/draft-gross-sipaq-00.txt

Just for the record, DIAMETER *does* allow public key authentication.

PatC