Subject: Re: [AAA-WG]:draft-johansson-aaa-diameter-mm-app-00.txt

From: Pete McCann <[email-masked]>
Date: Wed, 23 Jan 2002 10:58:30 -0600 (CST)

Hi, Jari,

Thanks for your comments on the draft - some replies below.

Jari Arkko writes:
 > Tony Johansson wrote:
 > 
 > > > - Capability AVPs that use Unsigned32. Given
 > > >   that ls -l *-sip-* | wc -l is 149, I fear
 > > >   the capability space may not be sufficient.
 > > >   And why didn't you use the option-tag scheme
 > > >   present in the SIP Supported etc headers?
 > > >
 > > 
 > > I'm not really sure that I fully understand you. Can you elaborate this
 > > a little bit further.
 > 
 > So, for instance, you have a SIP-Server-Capability AVP which
 > is of type Unsigned32. But what are the values? Ok, so you may
 > say that you'll provide some values in the future.  But how is
 > this synced to what the SIP WG will do? Will 32 bits be enough?
 > 
 > Note that in draft-ietf-sip-rfc2543bis-05.txt, section 21.2 a
 > concept of an "option-tag" is defined. This is a string of a specific
 > format that defines the capabilities of the SIP node. Couldn't
 > we use that?

As the draft is written, all capabilities are operator-defined 32-bit
numbers.  We have been discussing among the co-authors a more
general-purpose scheme for capabilities that allows e.g., both global
and vendor-specific scope for the capabilities.  However, we haven't
thought about trying to unify with the SIP option-tag feature.
Personally I think this is a very good idea and will lead to greater
flexibility, but it may imply more expensive processing than the
simple "dictionary" approach that was envisioned by 3GPP.

 > > >  What if there's a new HTTP Auth
 > > >  scheme that the SIP node doesn't know, but both
 > > >  the client and the AAA server do know? What I'm
 > > >  getting at is whether it makes sense to transport
 > > >  the HTTP Auth headers as such, unchanged, or
 > > >  whether you want or need to understand more of
 > > >  what happens inside the auth headers.
 > > 
 > > First of all, would you really update your client and AAA, and not your
 > > SIP node?
 > > 
 > > Furthermore, so lets say that the AAA is handling the HTTP Auth scheme
 > > and we transport HTTP Auth headers as such, unchanged, I don't see that
 > > the SIP node really have to understand the scheme in it's full detail.
 > > The SIP node (SSP) only has to forward the HTTP Auth header created by
 > > the client and the AAA, and finally get a successful result code from
 > > the AAA, if successfully authenticated .
 > > 
 > > On the other hand, if the SIP node is incharge of authenitication and
 > > the SIP node receives an unkown HTTP Auth header you would have do deal
 > > with this as in a SIP only case...
 > > 
 > > Unless I have missed some thing, I don't really see that we should
 > > change the idea of forwarding the HTTP Auth headers as such.
 > 
 > We seem to agree about the goal but perhaps I didn't understand
 > the document well enough to see that this was really the goal.
 > If you transport the HTTP Auth headers as such, where do you
 > need EAP-Payload?

I think I see your point.

The current text is designed to meet 3GPP's requirements for AKA,
which have the SSP doing some of the work in checking RES=XRES and
caching several authentication vectors in order to minimize round
trips with AAA.  However, this does seem to violate some of the goals
of EAP (assuming we run AKA in EAP), which is to keep the NAS-like
device unaware of most aspects of the authentication protocol, even if
it does need to know ciphersuites and key them based on NAS-Keys.

Perhaps the requirement is misguided and we should learn to live with
only HTTP Auth headers in the Diameter application and require AAA
involvement on every authentication.

Another approach would be for the SSP to understand the details of
AKA, its embedding in SIP (with or without EAP), and to encode
specific AVPs for AKA inside Diameter.

-Pete