Subject: [AAA-WG]: FW:I-D ACTION:draft-johansson-aaa-diameter-mm-app-00.txt

From: Tony Johansson <[email-masked]>
Date: Mon, 21 Jan 2002 09:07:55 -0800

All,

A few of us just sent out our first draft that specifies a Diameter
application that allows a Diameter server to authenticate, authorize,
and collect accounting information for Session Initiation Protocol (SIP)
services rendered to a client node, see below. We hope this will be
subject for a new working group item as soon as we are done with the
current charter.

Comments are welcomed, and greatly encouraged.

/Tony

To: IETF-Announce: ;
     Subject: I-D ACTION:draft-johansson-aaa-diameter-mm-app-00.txt
     From: [email-masked]
     Date: Thu, 17 Jan 2002 06:47:58 -0500
     CC: [email-masked]
     Reply-to: [email-masked]
     Sender: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : Diameter Multimedia Application
        Author(s)       : T. Johansson et al.
        Filename        : draft-johansson-aaa-diameter-mm-app-00.txt
        Pages           : 29
        Date            : 16-Jan-02

This document specifies a Diameter application that allows a Diameter
server to authenticate, authorize, and collect accounting information
for Session Initiation Protocol (SIP) services rendered to a client
node.  This application, combined with the base Diameter protocol and
appropriate SIP extensions, allows SIP User Agents (UAs) to obtain
services from SIP servers that are connected to a Diameter
infrastructure.  When combined with the Inter-Domain capability of
the base protocol, service may even be obtained from SIP servers that
belong to foreign domains, as would be encountered by roaming mobile
nodes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-johansson-aaa-diameter-mm-app-00.txt

---

From: Jari Arkko <[email-masked]>
Date: Tue, 22 Jan 2002 12:37:03 +0200

Thanks for submitting such an extension. We
need one!

A few comments or questions:

- Overall, while the introduction at the beginning
  is good, as are the detailed AVP etc descriptions,
  I missed some explanations that fall in between.
  What goes to what AVPs, and how they are related.

- 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 sure I understand why Auth-Data-Item
  has both Authentication-Challenge/Response
  and EAP-Payloads. Supposedly because it wants
  to support EAP within SIP as well as Digest?
  Well, how does a SIP node know which one is
  being run? By looking at the scheme parameter in
  RFC 2617? 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.

- Authentication-Challenge and -Response: do
  we need two attributes, and how does the
  SIP node decide which one this is?

- 5.11 Authentication-Context needs more
  detail before implementors know what to do.

- The authentication requests, can you say something
  about the stateful vs. stateless nature of the
  SIP servers this expects? One way to make this
  work is to expect that the subsequent SIP request
  (e.g. response to a digest challenge) will get
  to the same SIP server which holds some AAA state.
  Another way to do it would be to allow the SIP
  server to change in between (as in server farms),
  but retain the authentication state, if any, in
  the AAA side. I'd prefer the latter approach.

Jari

---

From: Tony Johansson <[email-masked]>
Date: Tue, 22 Jan 2002 15:30:15 -0800

Hello Jari,

Thanks for your comments, please find mine embedded...

/Tony

>   What goes to what AVPs, and how they are related.

Okay, we will work on some text that I hope will cover this issue.

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

>   to support EAP within SIP as well as Digest?

Correct.

>   RFC 2617?

Right, in the case of Digest and Basic, which then would make use of the
Authentication-Challenge/Response AVPs, and
draft-ieft-torvinen-http-eap-00.txt in the case of EAP-Payloads. I
agree, we need to explain this more explicitly.

>  What if there's a new HTTP Auth

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.

>   SIP node decide which one this is?

The idea with two is to make it more explicit. Thus, the
Authentication-Challenge AVP is used to carry the challenge and the
Authentication-Response is used to carry the digest. I believe this
makes it easier especially in the case when a SSP handles authentication
and all authentication info has to be distributed by the Diameter server
to the SSP.

>   detail before implementors know what to do.

I agree, we will work on some text.

Thanks,

Tony

---

From: Jari Arkko <[email-masked]>
Date: Wed, 23 Jan 2002 15:37:39 +0200

> I'm not really sure that I fully understand you. Can you elaborate this

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?

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

Jari