[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [AAA-WG]: Reconciling Radius/Diameter SIP application



Hi,

Again I think that only option b is the valid one.  Unless I am missing
something, I think a Proxy must be able to identify the the
Proxy-Authorization that is associated with it.  From RFC 2616:

"When multiple proxies are used in a chain, the
   Proxy-Authorization header field is consumed by the first outbound
   proxy that was expecting to receive credentials. A proxy MAY relay
   the credentials from the client request to the next proxy if that is
   the mechanism by which the proxies cooperatively authenticate a given
   request."

Therefore you would think that a particular proxy would extract the
credentials from its headers and those would be the only ones that are sent
to the AAA infrastructure.

And this also implies that the Proxy has a way to identify the
Proxy-Authroization header.

Is this right?

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] 
> Sent: Wednesday, November 24, 2004 1:58 PM
> To: Miguel Garcia
> Cc: Beck01, Wolfgang; AAA mailing list; radiusext@ops.ietf.org
> Subject: Re: [AAA-WG]: Reconciling Radius/Diameter SIP application
> 
> 
> Miguel Garcia wrote:
> 
> > In HTTP there is typically a single Proxy-Aut* header, due to that
> > typically there is a single proxy sitting between the 
> client and the 
> > server.
> > 
> > In SIP things get a bit more complicated, since it is common that a 
> > SIP
> > request traverses several proxies, where theoretically each 
> proxy could 
> > demand credentials. It is also valid that each SIP proxy requests 
> > credentials for the same or different realms than other SIP proxies.
> > 
> > In other words, a SIP proxy can receive a SIP request that contain
> > several Proxy-Authorization header fieldss. Each header field will 
> > contain the credentials for a particular realm.
> > 
> > So let's assume that one of this proxies receives a request that
> > contains several Proxy-Authorization headers. Which one 
> should the SIP 
> > proxy put into the Radius/Diameter message and send it to the 
> > Radius/Diameter server?
> 
> Thanks for the explanation. The situation is clearer to me
> now.
> 
> > a) Put blindly everything, I mean, all the Proxy-Authorization 
> > headers.
> > Repeat attributes (Radius will give us a problem since 
> attributes are 
> > not grouped).
> 
> I see the problem.
> 
> > b) Extract the credentials that are of interested (according to the
> > realm) of the SIP server and RADIUS/Diameter server. This 
> requires to 
> > configure the SIP server with the realm it is serving, but 
> it has some 
> > benefits: first the Radius/Diameter message contains one set of 
> > credentials (no poblems with Radius); second, it allows the 
> > Radius/Diameter server to be authenticating several realms, 
> so there is 
> > no uncertainity because there is only one set of credentials in the 
> > message.
> > 
> > Therefore, we proposed to clarify all this issue and 
> describe the need
> > to configure the SIP server with the realm it is serving. 
> This allows 
> > the server to select the appropriate credentials.
> 
> This sounds reasonable, and my original worry turned out
> to be a non-issue. (I worried that this might somehow
> limit what the user's realm might be. But the client's
> header includes both the username, which might of the
> form jari@domain, and the challenging proxy's realm.
> Only the latter is used in matching what gets sent to
> the AAA server. In conclusion I could be jari@domain1
> when traversing through three proxies that challenge
> me using realms domain2, domain3, and domain4, and
> a single AAA server could handle all of this.)
> 
> --Jari
> 

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>