Re: [[e-mail]: Re: [SIP] draft-calhoun-sip-aaa-req]

[Michael Thomas <[e-mail]>]

Pat Calhoun writes:
 > >    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. 

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

   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

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