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

From: Pat Calhoun <[email-masked]>
Date: Tue, 2 Jan 2001 14:19:24 -0800 (PST)

> The document has not been discussed in the AAA
> WG, because AAA is focused on network access
> requirements. 

Correct. For the record, however, the AAA did at one point consider SIP (or
VoIP). At that time, the WG requested requirements for this application, but
they weren't forthcoming :( Since only requirements for network access were
received, the WG re-chartered to focus on the problems that were defined. This
new focus has allows the WG to move much more efficiently.

Given the above, the AAA WG still should not diverge from its current path.
Any other WG that requires AAA should first come up with their requirements,
then perhaps see if the AAA protocol can satisfy those requirements.

> 
> Thus, it is completely up to the SIP WG to
> define the security requirements for SIP,
> which may or may not require AAA functionality
> as a solution.

Correct. The 3G folks have roaming requirements, which led them to AAA. 

> 
> I'd note that for applications such as
> telephony, where the client can often be
> presumed to have Internet access, a wider
> range of security solutions are available
> than in network access, where by definition
> the client does not have network access 
> prior to authentication. 

Whether of not the client has access to the 'net or not, I believe that a set
of requirements needs to be spelled out. We have attempted to do so in our
document, with an assumption that AAA will be used to exchange authorization
information in roaming situations.

PatC

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

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 2 Jan 2001 14:41:23 -0800 (PST)

>    I don't understand what roaming, per se, has to do
>    with SIP. How is that any different than just
>    REGISTER'ing to a new SIP registrar? I have
>    seen people want to reuse their RADIUS
>    infrastructure since it's sort of used as a
>    catch all user database, but that too seems
>    orthogonal to roaming and SIP.
and
>    That's _one_ way to do it, I suppose. It seems
>    a lot more natural to do direct authentication
>    of the SIP traffic on whatever device
>    (including UAS's) is the target of the SIP
>    message and perhaps use an LDAP or XML based
>    backend to transport the database goodies. 
> 

Devices can request services in foreign networks. Now perhaps
you are willing to open up your LDAP database to the outside world,
but the 3G folks aren't.

>    The only reason I can see to shoe horn it into
>    RADIUS/DIAMETER is because of legacy database
>    considerations, but that's only one set of
>    SIP installations which will have that as a
>    large consideration.

The 3G folks are forcasting billions of devices in the next few years,
and require such a backend. However as you state the document does in fact
attempt to solve a specific problem set. It is possible that corporate networks
have different requirements, hence multiple backends (AAA, LDAP, etc.)

PatC

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 02 Jan 2001 17:49:19 -0500

> have different requirements, hence multiple backends (AAA, LDAP, etc.)

I'm still trying to understand why the act of sending SIP requests is
subject to authorization. Will each new UDP port number and service get
its own AAA infrastructure? (I can see authorizing resource
reservations, but that's completely orthogonal to SIP, as has been
discussed here a few times...)

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 2 Jan 2001 15:00:25 -0800 (PST)

> discussed here a few times...)

Good question.

The carriers want to control who has access to certain services (say *traffic,
*911, etc.) Also in other cases, they want to get explicit authorization for
certain services, since they will incur a surcharge.

So when a request is received, say an invite to *traffic, a request is sent
off to the AAA server to ensure that the user is authenticated, and has access
to the said service. As far as *traffic is concerned, having traffic
information in the home network doesn't really do much good when one is
roaming :)

However, the actual services are still being worked out, and are carrier
specific. We are only trying to provide the infrastructure required to support
them.

PatC

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 02 Jan 2001 18:14:16 -0500

> specific. We are only trying to provide the infrastructure required to support

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]

(A separate question is whether non-global SIP URI are a good idea, but
that's a bit beyond this thread.)

---

From: Michael Thomas <[email-masked]>
Date: Tue, 2 Jan 2001 14:38:53 -0800 (PST)

Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 2 Jan 2001 15:11:10 -0800 (PST)

> you are willing to open up your LDAP database to the outside world,

   I don't see how one database transport protocol
   or another helps you on the base administration
   problem of who is and is not allowed to see
   various pieces of data.

   I'm still having a hard time understanding what 
   this has to do with SIP. I don't need a proxy
   or anything else in the visited network to do
   anything for me SIP-wise. I can talk to my home
   proxy just like normal. The two things that I
   might need are network access and enhanced QoS
   (no access just being a degenerate case of really
   lousy QoS) from the visited network attachment
   point.

   I can understand how you might want to do AAA
   for the access part (RADIUS/DIAMETER) and 
   policy decisions for QoS, but that doesn't have
   anything to do with SIP. I'll also make the
   wild assumption that you're not thinking in
   terms of the manyfolks/DCS/DQoS draft either
   which I don't think works at all for mobile
   UA's (at least in terms of the DQoS push
   model).

			Mike

---

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

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

> that's a bit beyond this thread.)

That's out of my league :(

PatC

---

From: Stephen Thomas <[email-masked]>
Date: Wed, 03 Jan 2001 11:12:04 -0500

>    lousy QoS) from the visited network attachment

I guess it depends on whether 3G providers want to
simply sell IP access (perhaps with differentiated QoS)
or whether they want to sell transactions. Kind of
reminds me of the old days when Compuserve, Prodigy,
MCI Mail, etc. billed per email message. (I guess that
dates me.)

One assumes that there are enough smart folks in 3G
to realize that it's theoretically possible to
"envelope" a voice conversation so as to make it
indistinguishable from email, Web browsing, or any
arbitrary application (whatever is un-metered), at
least as far as the network provider is concerned. (I'll
just stick my INVITE inside an SSL-encrypted connection
to port 443.)

Maybe no handset provider would be willing to alienate
its service provider customer base by creating a sufficiently
hackable device that would allow such behavior, but,
since PDAs now have wireless voice capability, it seems like
that genie's already out of the bottle.

Stephen

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 3 Jan 2001 08:23:15 -0800 (PST)

> that genie's already out of the bottle.

ok, now we are venturing in the business space, so I'll temporarily cross
that boundary to address your comment.

One of my points to these carriers is that they cannot even hope that
users make use of their SIP infrastructure. There will be free SIP servers
around the 'net, and people can use those. I believe that the carriers
understand this, and this will lead to different charging models (e.g.
pay for the spectrum you use, as oppose to the calls you make or provide
better QoS if you use local SIP servers, etc.). This is really out of scope of
this discussion though...

However, some carriers do still want to make local services available,
it is not clear that there will be an added cost to make these calls, and
this is really irrelevant. The fact is that local services are important
to these providers, and an infrastructure must be built to allow them to
restrict providing these services only to customers using their network.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 3 Jan 2001 09:00:03 -0800 (PST)

>    What is in scope is whether there are any
>    peculiar requirements for SIP and AAA, and
>    indeed whether AAA protocols are the right 
>    means to the end of providing cross realm
>    services at proxies and UA's. For proxies,
>    about the only advantage I can see of using
>    an outbound proxy in the visited network is
>    that it may be topologically closer which may
>    help the overall post dial delay. If it's 
>    having to make round trips to the home AAA,
>    you've probably negated that advantage, and
>    it's not clear that it's even much of an
>    advantage in other than a small subset of
>    calls.

As I mentioned, the initial AAA infrastructure is ONLY contacted once per
session (or once per user, depending upon the service and authorization
information returned from the home, I suppose). Of course accounting messages
are still sent to the home, but these do not add latency since they are done
in parallel.

> 
>    For UA's... I get the impression that there
>    is some sort of moral dividing line in the
>    AAA wg about CPE using AAA protocols. A SIP
>    UA is a SIP UA though, and since any old
>    UA may want to be able to authenticate and
>    authorize a session, it looks like this is
>    going to at the very least like duplication 
>    of capabilities that are needed for SIP UA's.
>    Since we don't even have a very good model
>    for those capabilities within SIP right now,
>    it's not clear to me that further muddying
>    the waters with AAA backhaul is going to be
>    especially productive. In fact, it will
>    probably make things much worse because of
>    protocol combinatorics.

Well, I am not sure that I really understand your comment here. In Mobile IP,
we were able to get AAA support with VERY minimal changes. In fact, the
following was done: 1. Allow the mobile to have an NAI as its identifier, as
opposed to a home address (something that is already supported in SIP, so no
change required). 2. Allow the mobile to share a secret with its AAAH, as
opposed to its Home Agent (something that is VERY easy to do, and probably
requires NO protocol changes in SIP).

>    It seems like it would be a lot simpler to just 
>    set up agreements to do SIP proxy server
>    outsourcing. You don't end up with bizarre
>    version/service skew issues that way too.

yes, and do everything that I had listed on my previous e-mail (e.g. download
a portion of the user's profile, etc.)

PatC

---

From: Michael Thomas <[email-masked]>
Date: Wed, 3 Jan 2001 08:55:49 -0800 (PST)

Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 3 Jan 2001 09:42:04 -0800 (PST)

Pat Calhoun writes:
 > we were able to get AAA support with VERY minimal changes. 

   The problem is that you're proposing to
   backhaul most (all?) of the SIP message 
   back as an opaque blob. That sort of begs
   the question of why don't you just send it
   as a SIP message as Henning suggests; the
   AAA is, if nothing else, going to have quite
   a bit of proxy logic to determine whether
   it should authorize the request. Looks like
   duck, walks like duck... probably is duck.

 > In fact, the

   I assume that you're talking about
   draft-ietf-mobileip-aaa-key-01.txt? Assuming that I'm
   reading the draft correctly, I have to tell you that the
   entire idea makes me extremely queasy: shipping the user's
   long term key from the AAA to other entities of
   which have questionable and/or unknown security
   practices seems *extremely* dangerous.

   Kerberos, for this very reason, does not do this; instead
   a short term ephemeral secret is created for use between
   the client and server. That you even call the AAAH
   a "KDC" (to which I don't disagree) should give pause
   that the AAA should at least learn the lessons of "real"
   KDC's which consumes endless hours of lots of
   smart security folks. FYI, I'm in the process
   of writing a draft which has the functionality
   you're looking for but uses Kerberos mechanisms 
   to create an ephemeral session key. 

	     Mike

---

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

>    duck, walks like duck... probably is duck.

I *assume* that you understand how RADIUS and/or DIAMETER works. The NAS pulls
specific items out of the request (SIP message), and inserts them into what we
commonly call AVPs (or attribute value pairs). The AAA server takes this
information to make its authorization decision. The only reason why the SIP
request is sent at all is for authentication reasons, since the SIP server
doesn't have the mobile's long term secret.

>    draft-ietf-mobileip-aaa-key-01.txt?
yes.

>    Assuming that I'm

Perhaps a re-read is in order? In fact, perhaps section 6.0 of
draft-calhoun-diameter-mobileip-11.txt would be a better read.
draft-ietf-mobileip-aaa-key-01.txt carries the ephemeral keys created in the
former document.

(btw, I'll try not to take offense that you would even think that I would be
passing around a mobile's long term secret to other network entities).

>    to create an ephemeral session key. 

Thanks for the Kerberos tutorial :)

Seriously, this is precisely what the AAAH does.

PatC

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 04 Jan 2001 12:03:48 -0600

>We are only trying to provide the infrastructure
>required to support
>them.

There have been a number of I-Ds on this list from people working for
various carriers and I suggest vendors to look at them, such as from AT&T,
L3, Telia and WorldCom in alphabetical order, and others.

One of the papers mentioned here is
http://ietf.org/internet-drafts/draft-gross-cops-sip-00.txt

and it is clearly focused (we hope) on the POLICY SERVER, NOT the AAA
SERVER, in the DIAMETER sense, whose functions are actually absorbed in the
policy server and its constituents, such as directories (personal and
corporate accounts), outsourced policy servers, clearinghouse and other. So
please do not assume that all ISP folks see the AAA server as the center of
the universe...

As for the question why XML/HTTP:

ISP services development and operations costs are minimized by using the
smallest number of protocols and data formats.
HTTP clearly makes it to the top of the short list for transport.
XML has countless tools for dummies (like me) and can be displayed with the
browser and is thus ideal for testing and prototyping in this fast changing
environment. It is has also a large field of applicability. DIAMETER with
its AVP data formats does not have these advantages - may have its place as
mentioned for network access, but is not in the center of the AAA universe
IMHO. Pushing DIAMETER to be the focus of AAA is not convincing.

Henry

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Pat Calhoun
> Sent: Tuesday, January 02, 2001 5:00 PM
> To: Henning G. Schulzrinne
> Cc: Pat Calhoun; Michael Thomas; SIP List
> Subject: Re: [[email-masked]: Re: [SIP] draft-calhoun-sip-aaa-req]
>
>
>
> >

---

From: David Frascone <[email-masked]>
Date: Fri, 5 Jan 2001 09:47:26 -0600

> IMHO. Pushing DIAMETER to be the focus of AAA is not convincing.

I'm not sure I follow your reasoning.  I agree that XML is an exelent way
to model data.  But, I have to disagree about it being a good transport.  In
my opinion, AVPs were chosen because the are extensible, and, SMALL.  And,
since they are binary, they do not have to be parsed, but can be manipulated
by pointing a structure at them.

Any of the data transported in AVPs could be *viewed* with an XML viewer after
a small conversion.  Accounting data could also be sent as XML.  Any XML
payload could be sent inside of AVPs.

But, I *still* don't understand why you would want the TRANSPORT to be 
XML.  We are still talking about the TRANSPORT, right?  What is the reasoning
for having XML on the wire? 

<sarcastic hat> I mean, if we are going to use it as the transport, why stop
there?  Why not XML over IP?  XML over ethernet? </sarcastic hat>

Please, If I'm missing something, let me know.  But I am haveing serious
trouble following your need for being able to sniff XML packets on the wire.

Dave Frascone

---

From: Henry Sinnreich <[email-masked]>
Date: Sat, 06 Jan 2001 20:38:01 -0600

>XML.

I said
>> As for the question why XML/HTTP:

that means HTTP transport.

Henry

-----Original Message-----
From: David Frascone [mailto:[email-masked]]
Sent: Friday, January 05, 2001 9:47 AM
To: Henry Sinnreich
Cc: Pat Calhoun; Henning G. Schulzrinne; Michael Thomas; SIP List;
[email-masked]; [email-masked]
Subject: Re: [[email-masked]: Re: [SIP] draft-calhoun-sip-aaa-req]

Any of the data transported in AVPs could be *viewed* with an XML viewer
after
a small conversion.  Accounting data could also be sent as XML.  Any XML
payload could be sent inside of AVPs.

But, I *still* don't understand why you would want the TRANSPORT to be
XML.  We are still talking about the TRANSPORT, right?  What is the
reasoning
for having XML on the wire?

Dave Frascone