Re: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]

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

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.

> 
>  > 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?
yes.

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

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

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

Thanks for the Kerberos tutorial :)

Seriously, this is precisely what the AAAH does.

PatC

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip