Subject: RE: [Sipping] New version of the SIP-AAA reqs draft

From: [email-masked]
Date: Wed, 19 Feb 2003 12:11:06 +0200

Hi,

I agree with Aki.

Perhaps some answer to Juha question could be found
from the Open source Diameter project (see attached mail).

http://opendiameter.org.

Br
Marco 

> -----Original Message-----
> From: ext [email-masked] [mailto:[email-masked]]
> Sent: 19 February, 2003 11:35
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; Loughney John (NRC/Helsinki); [email-masked]
> Subject: RE: [Sipping] New version of the SIP-AAA reqs draft
> 
> 
> Hi Juha,
> 
> Isn't this a chicken-and-egg problem? Diameter just got to 
> proposed standard - back in 1999 if you had asked the same 
> set of questions about RFC 2543, I bet we'd all be talking 
> about H.323 or something... ;)
> 
> Cheers,
> Aki
> 
>  > -----Original Message-----
>  > From: ext [email-masked] [mailto:[email-masked]]
>  > Sent: 19 February, 2003 10:37
>  > To: [email-masked]
>  > Cc: Henry Sinnreich; 'Gonzalo Camarillo'; 'sipping'; Loughney John
>  > (NRC/Helsinki)
>  > Subject: Re: [Sipping] New version of the SIP-AAA reqs draft
>  > 
>  > 
>  > is there any open source diameter server implementations similar to
>  > freeradius?  
>  > 
>  > is there a good number of commercial diameter server 
>  > implementations for
>  > me to choose from?
>  > 
>  > is there any open source diameter client libraries similar to
>  > radiusclient?
>  > 
>  > is there any commercial diameter client libraries for me to 
>  > choose from?
>  > 
>  > i don't mind using diameter for sip once answers to most 
> of the above
>  > questions is "yes".  as long it isn't, it makes no sense to 
>  > base sip aaa
>  > work on diameter.
>  > 
>  > -- juha
>  > 
>  > _______________________________________________
>  > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
>  > This list is for NEW development of the application of SIP
>  > Use [email-masked] for questions on current sip
>  > Use [email-masked] for new developments of core SIP
>  > 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

Subject: [AAA-WG]: OpenDiameter announcement
From: <[email-masked]>
To: <[email-masked]>
Date: Wed, 9 Oct 2002 16:21:10 +0200

Hi,

Let me allow to post this announce on the AAA mailing list.

A new project for develpping open source Diameter software has been
created.  A Diameter message parser library is available in the first
release.  We will actively work on releasing new stuff and updating 
them.  If you are interested in this project, visit 
http://opendiameter.org.  

For further questions, please send email to
[email-masked], not to this list.

Thanks,
Yoshihiro Ohba

---

From: [email-masked]
Date: Fri, 21 Feb 2003 17:43:00 +0200

> Yes, DIAMETER will be divergent with the existing RADIUS base serving
> 100's of millions Internet users. 

Yes, but RADIUS will be divergent with the wireless environment
currently serving 700's millions of GSM/GPRS users.

That's why we should make Diameter base AAA-SIP solution with
special care to RADIUS interoperability.

Br
Marco

> From: ext Henry Sinnreich [mailto:[email-masked]]
> Sent: 21 February, 2003 17:37
> To: Stura Marco (NET/Helsinki); [email-masked];
> [email-masked]
> Cc: Loughney John (NRC/Helsinki); [email-masked]; Henning 
> Schulzrinne
> > Diameter is needed to avoid divergent solutions across 
> > multiple networks, which perhaps end up in interoperability 
> problems. 
> 
> Yes, DIAMETER will be divergent with the existing RADIUS base serving
> 100's of millions Internet users. 
> 
> That's why we should make
> 
> http://www.watersprings.org/pub/id/draft-schulzrinne-sipping-r
> adius-acco
> unting-00.txt
> 
>  and
> 
> http://www.watersprings.org/pub/id/draft-byerly-sip-radius-00.txt
> 
>  should be the first WG design items.
> 
> Henry
> 
> > From: [email-masked] [mailto:[email-masked]] 
> > Sent: Friday, February 21, 2003 9:16 AM
> > To: [email-masked]; [email-masked]; 
> > [email-masked]
> > Cc: [email-masked]; [email-masked]
> > > I doubt any service providers will agree vendors are 
> > entitled to speak 
> > > for them, wired or wireless.
> > 
> > I guess Jari was not speaking on behalf of wireless 
> > operators, rather He was just reporting what has been 
> > standardized in 3GPP by both vendors and operators i.e. AAA 
> > for IP multimedia services based on Diameter.
> > 
> > Consequently 3G wireless service providers will deploy 
> > Diameter. I guess an IETF standard on SIP-AAA based on 
> > Diameter is needed to avoid divergent solutions across 
> > multiple networks, which perhaps end up in interoperability 
> problems. 
> > 
> > Best Regards
> > Marco
> > 
> > > From: ext Henry Sinnreich [mailto:[email-masked]]
> > > Sent: 21 February, 2003 16:46
> > > To: [email-masked]; [email-masked]
> > > Cc: Loughney John (NRC/Helsinki); [email-masked]
> > > >  > Any of the 3G operators count for this? I'm not sure 
> > how many  > 
> > > > of the subscribe to this group though, even if their vendors  > 
> > > > do...
> > > 
> > > I doubt any service providers will agree vendors are 
> > entitled to speak 
> > > for them, wired or wireless. The service providers on this 
> > list have 
> > > given solid arguments why we prefer RADIUS at present. As 
> for what 
> > > comes beyond RADIUS, we have the OSP token I-D
> > > 
> > > http://www.ietf.org/internet-drafts/draft-johnston-sip-osp-tok
> > > en-04.txt
> > > 
> > >  and the IETF work at
> > > 
> > > http://www.aaaarch.org/charter.html
> > > 
> > > DIAMETER is just too little, too late IMHO, when looking at
> > > the options
> > > in these links.
> > > 
> > > Question: Has anyone predetermined in SIPPING that DIAMETER 
> > good for 
> > > service providers? Interesting...
> > > 
> > > Thanks, Henry
> > > 
> > > 
> > > 
> > > > From: [email-masked] [mailto:[email-masked]]
> > > > On Behalf Of Jari Arkko
> > > > Sent: Friday, February 21, 2003 3:04 AM
> > > > To: [email-masked]
> > > > Cc: 'John Loughney'; [email-masked]
> > > > [email-masked] wrote:
> > > > > Jari Arkko writes:
> > > > > 
> > > > >  > Henry Sinnreich wrote:
> > > > >  > > Is there any service provider planning to use
> > > SIP-DIAMETER? If
> > > > > yes,  > > please speak up.  >
> > > > >  > Any of the 3G operators count for this? I'm not sure 
> > how many  
> > > > > > of the subscribe to this group though, even if their 
> > vendors  > 
> > > > > do...
> > > > > 
> > > > > it depends.  will the vendors really give 3g operators a
> > > > free choice
> > > > > which diameter server they want to use in their 3g 
> > network?  which
> > > > 
> > > > I'm not quite sure what you mean by free choice in this
> > > > context, but perhaps you are after standardized interfaces? 
> > > > These would be publicly available in the form of RFCs (eg 
> > > > DIAMETER base) and 3G specifications on how DIAMETER is used 
> > > > for multimedia application.
> > > > 
> > > > > diameter servers has nokia tested interoperability against?
> > > >  does any
> > > > > of
> > > > 
> > > > I don't know but there's been Diameter interoperability
> > > > events. Perhaps you John could dig up the Nokia information 
> > > > from those if you participated? I know Ericsson particpated 
> > > at least.
> > > > 
> > > > > these servers come from non-3g vendors?  or is the use of
> > > > diameter in
> > > > > 3g networks similar fake as use of sip in 3g im?
> > > > 
> > > > The question was if anyone was going to deploy and I 
> answered ;-)
> > > > 
> > > > I don't fully agree with the way 3G sets up their AAA. But we
> > > > are discussing the creation of an IETF standard for SIP AAA. 
> > > > 3G folks had to create a multimedia AAA application because 
> > > > the IETF does not have one. My opinion is that we need an 
> > > > IETF standard in this space, so that the 3G folks, SIP vendor 
> > > > groups, or other parties don't all diverge on how to do this. 
> > > > IMHO, this is really crucial for SIP. My belief is also that 
> > > > the IETF standard will be better than any of these groups 
> > > > could do themselves. As far as 3G goes, my understanding was 
> > > > that they are happy to switch to an IETF standard when it 
> > > > becomes available.
> > > > 
> > > > Jari
> > > > 
> > https://www1.ietf.org/mailman/listi> nfo/sipping
> > > > This list 
> > is for NEW development of the 
> > application of SIP Use 
> > > > [email-masked] for questions on 
> current sip Use 
> > > > [email-masked] for new developments of core SIP
> > > > 
> > > 
> > > This list is for NEW development of the application of SIP Use 
> > > [email-masked] for questions on current sip Use 
> > > [email-masked] for new developments of core SIP
> > > 
> > 
> 
>

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 21 Feb 2003 21:14:16 +0200

just to add to henry's list ofdrafts, this is what many open source and
commercial radius servers and sip proxies support for digest
authentication with sip and which is in use by several sip providers:

ftp://lohi.eng.song.fi/tmp/draft-sterman-aaa-sip-00.txt

(the directory is not listable).

-- juha

---

From: Stu Jacobs <[email-masked]>
Date: Fri, 21 Feb 2003 15:55:55 -0500

Allison,

This material is part of ongoing efforts of Verizon and Verizon management 
to engage in thoughtful considerations of the fundamental changes and 
challenges facing the telecommunications industry. To meet its fiduciary 
responsibilities, management must explore all alternatives, even those that 
may appear highly speculative and hypothetical. Statements and 
representations contained herein are preliminary and/or tentative and 
should not be relied on unless approved by the appropriate Verizon 
governing body.  The following represent the anticipated approach Verizon 
most likely will use.  I cannot be more firm at this time as our 
architectural plans are not finalized.

Verizon's current direction for our Next Generation Network (NGN) VoIP 
Services will likely use a challenge/response approach (ala. Radius) for 
authentication and access control between our SIP service customers and SIP 
Proxies.  All our SIP service customers will probably go through SIP 
Proxies.  We will not support SIP UA to SIP UA within our operational 
domain.  Our SIP Proxies will likely authenticate themselves to other SIP 
Proxies and other back-office systems (OSSs, Application Servers, EMSs, 
etc.) by use of IPsec, specifically IKE combined with X.509v3 server 
certificates and ESP transport mode Null-encryption using 
HMAC-SHA1-96.  Access controls (rights/policies) between our intermediate 
systems (incl. SIP Proxies, Gateways , etc.) are expected to be based on 
use of policy certificates.  All policy and identity certificates are 
expected to be distributed via a redundant hierarchy of LDAP servers 
(repositories).  Accounting data will most likely be compiled by our SIP 
Proxies and transferred to billing systems with authentication provided by 
IPsec.  The actual billing data will probably be captured in the form of 
XML in conjunction with XML signatures (as defined by the W3C).

Stu

At 2/20/03 05:24 PM, you wrote:
>Stu,
>
>You are not doing the usage accounting with Radius, then.
>
>It is only doing the remote access authentication?
>
>We can work with this scenario.  Could you speak to this in
>the open mailing list?  I would like to rule out Radius for
>call detail and usage-based accounting, but it is ok for the
>other A's.
>
>Allison
>
> > Diameter in our Next Generation Network (NGN) VoIP Services.  We will be
> > doing our usage accounting within SIP Proxies and intend to transfer said
> > accounting "call detail records" back to our billing OSSes via other
> > protocols with IPsec providing authentication and confidentiality for 
> these
> > transfers.  We currently do not plan on any deployment of Diameter within
> > Verizon's wireline NGN architecture.  We will probably continue to use
> > Radius for remote access authentication at the application layer for a
> > number or years into the future.
> >
> > Stu Jacobs
> >
> > At 2/14/03 09:58 PM, you wrote:
> >
> > >Jiri,
> > >
> > >It always seems good to be able to stay with installed base, but
> > >there's a factor against our supporting RADIUS drafts for SIP's
> > >accounting - safety.  Even though there is deployment, there are
> > >some extremely bad cases of damage in production, and the IETF
> > >has concluded that RADIUS is not suitable for usage-based accounting
> > >(RFC2975).
> > >
> > >Unless there is no intention of having in SIP accounting usage-based,
> > >monetary, auditable applications, RADIUS is not the solution.  The
> > >protocol just does not preserve a complete stream of reliable
> > >accounting records that are auditable on any level, especially with
> > >any roaming.  As Bernard Aboba stated to this WG, quoting Mike O'Dell,
> > >the use of RADIUS may even be illegal in situations where there is an
> > >authority over the billing.  Records are too easily lost by the
> > >protocol. This is stated clearly by RFC2975.  This is the reason why
> > >the Operations and Mgt Area developed Diameter.  On these technical*
> > >grounds, that the RADIUS protocol does not have enough reliability,
> > >the work must be based on the Diameter protocol, which is now
> > >approved.  Alternatively, work could be done that does not include
> > >usage-based accounting, but this does not seem to be what is
> > >envisioned in the SIPPING AAA requirements.
> > >
> > >Allison
> > >
> > >P.S. There's a current investigation of RADIUS compatibility mode
> > >in Diameter for this - more needs to be thought about it.
> > > >
> > > > At 07:46 PM 2/11/2003, [email-masked] wrote:
> > > > >Hi Henry,
> > > > >
> > > > >> >but one option is develop a solution using
> > > > >> > Diameter in RADIUS-compatibility mode.
> > > > >>
> > > > >> OK, this is better than nothing. We'll take what we can :-)
> > > > >>
> > > > >> As mentioned, the installed base is RADIUS, no matter how
> > > > >> voluminous the DIAMETER literature may be.
> > > > >
> > > > >I think the issues is that the IETF should recommend what is the
> > > > >right thing to do & why.  If people choose to do something else,
> > > > >well, that is life.
> > > >
> > > > Remember that running code does not necessarily mean something known
> > > > to compile -- that is something known to be deployed.
> > > >
> > > > >I understand what you are asking but I do note that some
> > > > >people have thought that the potential for AAA is much greater
> > > > >than the existing installed base.
> > > >
> > > > I actually think that the deployment argument is a very important one.
> > > >
> > > > -Jiri
> > > >
> > ==========================
> > Stuart Jacobs CISSP
> > PMTS - Sr. Technologist
> > Verizon Laboratories
> > 40 Sylvan Road Waltham, MA 02451-1128     USA
> > telephone: (781) 466-3076   fax: (781) 466-2838
> > [email-masked] [email-masked]  [email-masked]
> > ==========================
> >
==========================
Stuart Jacobs CISSP
PMTS - Sr. Technologist
Verizon Laboratories
40 Sylvan Road Waltham, MA 02451-1128   USA
telephone: (781) 466-3076 fax: (781) 466-2838
[email-masked] [email-masked] [email-masked]
==========================

==========================
Stuart Jacobs CISSP
PMTS - Sr. Technologist
Verizon Laboratories
40 Sylvan Road Waltham, MA 02451-1128     USA
telephone: (781) 466-3076   fax: (781) 466-2838
[email-masked] [email-masked]  [email-masked]
==========================

---

From: [email-masked]
Date: Sat, 22 Feb 2003 11:55:28 +0200

Hi Henry,

> Thanks for clarifying the fact that we have two issues. 
> 
> The 2nd item, why DIAMETER is not the best option for NG: It is too
> little, too late.
> 
> AAA is a natural part of e-commerce, that is of the web services
> architecture, as defined in W3C and numerous industry consortiums. It
> makes little sense for all the world to make payments and conduct
> transactions in the 'web services currency' and only phone calls to be
> paid in 'DIAMETER currency'. Actually two types of phones call
> 'currencies': Wired using RADIUS and mobile using DIAMETER. Not that
> DIAMETER is inherently evil or poorly engineered. It is just too little
> too late, when looking beyond RADIUS and its limitations. My 
> two cents.

Well, I would debate that there is a significant difference between Diameter
currencies and Web services' currencies.  Diameter, ultimately, is a transport
protocol for AAA, it does not define the format, etc.
 
> I would see the design jobs therefore this way:
> 
> 1-Near term: Use RADIUS-SIP to accommodate the huge isntalled base. The
> I-D's mentioned here. Including the OSP token for SIP.
>
> 2-Longer-term: The Web services architecture.

I would think that Web services are not in scope for the IETF, it is
much more of something for W3C, OMA or IRTF to take up, in my opinion.

I think the near term is what we should be working on, and I see
the solution to be RADIUS compatability & Diameter support - 
meaning that RADIUS may be able to support Authorization & Authentication,
but Accounting might not be possible, that is why Diameter should be 
considered.  There is as well a request from the 3G's that a Diameter
based application be supported.

> It appears the present discussion stems from the fact that we only have
> volonteers for a DIAMETER-SIP draft. None of the mentioned RADIUS-SIP
> authors have volunteered any work here, and this is the problem. So
> unless the no RADIUS or web services volonteer steps up, we will have
> neither 1 nor 2.

Well, what I suggest is that for the folks to whom RADIUS-SIP is important,
they should get together and get the resources to work on a solution.  The
work doesn't do it by itself.

br,
John

---

From: "Beck01, Wolfgang" <[email-masked]>
Date: Thu, 27 Feb 2003 13:21:06 +0100

From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Thursday, February 27, 2003 9:28 AM
> To: Jiri Kuthan
>
> Juha,
>
> Do you mean that you would like to see a note along these 
> lines added to
> the draft?
> 
> "Note that, in order to perform accounting, a SIP proxy server should
> see and authenticate every message sent over the dialog."
> 
I don't think it's possible to do reliable accounting within a proxy
if any or both of the UAs are cheating. The caller can deliberately
ignore Record-Route and bypass the proxy when sending an INVITE. The
callee can send broken BYEs that will be discarded by the caller but
will be accepted by the accounting proxy. 

What kind of accounting information do we want to collect: The number
of SIP messages per user? This is possible with an accounting proxy.
Call minutes? How does the proxy know what kind of session is being
established if the SDP is encrypted? Only the endpoints and the bandwidth
reservation infrastructure can do this kind of accounting.

The only way I see is to include some form of micropayment tokens ("postage stamps")
in SIP messages. draft-johnston-sip-osp-token-04.txt describes such a token.
Periodical session updates containing tokens prevent disputes about the actual
length of the call. If the callee has tokens, he can charge for the call. The
trusted third party that generates those tokens can be an OSP server or may be
a proxy that inserts some header.

(see http://www.ietf.org/internet-drafts/draft-beck-sipping-svc-charging-req-01.txt)

--
Wolfgang Beck
T-Systems Nova GmbH

---

From: [email-masked]
Date: Thu, 27 Feb 2003 14:36:48 +0200

Hi,

In the end, doesn't this also depend heavily on what the purpose for collecting accounting data is? If you're only doing accounting for the purposes of traffic analysis or logging, i.e., event based accounting at the proxy, I doubt that authentication or origin of the messages is real critical. 

On the other hand, if you're collecting data for charging purposes, then authentication and integrity of the SIP messages is critical. However, hasn't billing based on accounting data collected by proxies been discouraged on this list several times before?

Cheers,
Aki

 > Sent: 27 February, 2003 13:58
 > To: Gonzalo Camarillo
 > Cc: Jiri Kuthan; Stuart Jacobs; Allison Mankin; [email-masked]
 > Subject: Re: [Sip] Re: [Sipping] New version of the SIP-AAA 
 > reqs draft
 > 
 > 
 > Gonzalo Camarillo writes:
 > 
 > unfortunately in most common cases the sip proxy cannot authenticate
 > every message.  in order to be able to account a request, the proxy
 > should be able to either authenticate it (if it was send by its own
 > user) or know that i came from a trusted another proxy that 
 > has already
 > authenticated the request.
 > 
 > in order to know that the requstest was sent by its own 
 > user, the proxy
 > should either be dialog aware or have somekind of security 
 > association
 > with its user.  neither of these is possible with products 
 > that are in
 > common use today.
 > 
 > -- juha
 >

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 27 Feb 2003 16:19:49 -0500

I agree with Juha that it's pretty unlikely that a UA will have an X.509
cert it can use to do mutual TLS auth with a proxy. The proxy should
definitely authenticate itself to the UA with a certificate, but it is much
more plausible that the UA will authenticate itself to the proxy with
Digest. This is the model presented in RFC3261,  anyway.

Jon Peterson
NeuStar, Inc.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, February 27, 2003 7:25 AM
> To: Beck01, Wolfgang
> Cc: [email-masked]
> Beck01, Wolfgang writes:
>  > During TLS handshake, the proxy obtains a X509 certificate from the
>  > UA.
> 
> so you assume somekind of pki and mutual authentication of ua 
> and proxy?
> if so, we don't have any of it in real products and practices. 
> 
>  > The cert. contains a subject name that identifies the 
> peer. This can be
>  > used to create a P-Asserted-Identity header. Only the 
> proxy that is directly
>  > connected via TLS to the customer can do that of, of 
> course. All following
>  > proxies have to rely on P-Asserted-Identity (or 
> OSP-token?). You can use
>  > digest authentication on top of TLS to discriminate SIP 
> users that share a
>  > TLS connection using a proxy.
> 
> if you don't have the certificate system that you outlined above, the
> proxy can't do digest authentication, because you don't know 
> if the user
> sending the request is your user or not.  dialog state would help.
> another thing that would help is always using as fro uri the 
> uri of the
> sending user, which would allow the proxy to know if the user can be
> challenged or not. 
> 
> -- juha
>