Subject: Re: [saag] Request for guidance regarding E2E security over Diameter

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 21 Apr 2015 13:26:07 -0400

Hello,

A few weeks have past and I don't see any response to this request
on-list.  Are there any volunteers that would like to assist DIME with e2e
encryption for Diameter as described in Lionel's message?

Thanks,
Kathleen

On Thu, Mar 26, 2015 at 12:24 PM, <[email-masked]> wrote:

> Hi,
>
> As currently specified, the Diameter Base protocol (RFC6733) only offers
> transport level protection between neighboring Diameter peers, using either
> TLS/TCP, DTLS/SCTP, or IPsec as last resort. However, no mechanism has been
> defined to ensure E2E security for data (in the conveyed (in the form of
> Attribute-Value Pairs (AVPs)) in Diameter messages between two endpoints.
> Early 2000, at the beginning of the work on Diameter, CMS (Cryptographic
> Message Syntax) was identified as solution to provide AVP-level E2E
> security but this work was not completed due to lack of deployment interest
> (at least at that time) and the foreseen complexity of the developed
> solution for Diameter.
>
> Due to the renewed interest for E2E security over Diameter, mainly for
> inter-domain signaling in the mobile network environment, the DIME WG has
> decided to reactivate the work on E2E security for Diameter. The first step
> is almost completed, with a document (draft-ietf-dime-e2e-sec-req-02)
> defining the requirements for an AVP-level E2E security solution. The
> second step will be work on the specification of such mechanism. An early
> proposal was to derive a solution from JOSE, encapsulating JOSE objects for
> integrity protection and AVP encryption. It is however expected that other
> mechanisms could be proposed as candidate solutions. And we know already
> that there are existing discussions on alternative to JOSE (e.g. COSE).
>
> Whatever the proposed solution(s),the DIME WG has not (and will not have)
> the expertise required to evaluate and select the more appropriate security
> mechanism for E2E security over Diameter. We are therefore interested by
> any guidance and support from SAAG regarding the development of a solution
> for E2E security over Diameter, based on the requirements collected in
> draft-ietf-dime-e2e-sec-req-02.
>
> Regards,
>
> Lionel
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

-- 

Best regards,
Kathleen

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 21 Apr 2015 10:51:06 -0700

In practice, as I understand it, Diameter implementations utilize no transport security at all -  TLS, DTLS, Ipsec, etc. are not being used.  Since Diameter has no application security either, the only security deployed in the wild is firewalls.  Since an unprotected Diameter session carries information relating to user privacy such as usernames, location, etc. this makes it easy for an attacker snooping on the network to reap a bonanza of personal information about you - including your location at every moment. 
As the former AAA WG Chair who closed work on e2e security due to lack of interest from implementers, I am gratified to hear that work on e2e security is once again being considered.   However, it is a bit like having an illiterate express interest in reading Proust -- an admirable sentiment, but there are a few hurdles to get over first...

Date: Tue, 21 Apr 2015 13:26:07 -0400
From: [email-masked]
To: [email-masked]
CC: [email-masked]; [email-masked]
Subject: Re: [saag] Request for guidance regarding E2E security over Diameter

Hello,
A few weeks have past and I don't see any response to this request on-list.  Are there any volunteers that would like to assist DIME with e2e encryption for Diameter as described in Lionel's message?
Thanks,Kathleen
On Thu, Mar 26, 2015 at 12:24 PM,  <[email-masked]> wrote:
Hi,

As currently specified, the Diameter Base protocol (RFC6733) only offers transport level protection between neighboring Diameter peers, using either TLS/TCP, DTLS/SCTP, or IPsec as last resort. However, no mechanism has been defined to ensure E2E security for data (in the conveyed (in the form of Attribute-Value Pairs (AVPs)) in Diameter messages between two endpoints. Early 2000, at the beginning of the work on Diameter, CMS (Cryptographic Message Syntax) was identified as solution to provide AVP-level E2E security but this work was not completed due to lack of deployment interest (at least at that time) and the foreseen complexity of the developed solution for Diameter.

Due to the renewed interest for E2E security over Diameter, mainly for inter-domain signaling in the mobile network environment, the DIME WG has decided to reactivate the work on E2E security for Diameter. The first step is almost completed, with a document (draft-ietf-dime-e2e-sec-req-02) defining the requirements for an AVP-level E2E security solution. The second step will be work on the specification of such mechanism. An early proposal was to derive a solution from JOSE, encapsulating JOSE objects for integrity protection and AVP encryption. It is however expected that other mechanisms could be proposed as candidate solutions. And we know already that there are existing discussions on alternative to JOSE (e.g. COSE).

Whatever the proposed solution(s),the DIME WG has not (and will not have) the expertise required to evaluate and select the more appropriate security mechanism for E2E security over Diameter. We are therefore interested by any guidance and support from SAAG regarding the development of a solution for E2E security over Diameter, based on the requirements collected in draft-ietf-dime-e2e-sec-req-02.

Regards,

Lionel

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

saag mailing list

[email-masked]

-- 

Best regards,Kathleen

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Apr 2015 21:09:17 +0100

On 21/04/15 18:51, Bernard Aboba wrote:
> In practice, as I understand it, Diameter implementations utilize no
> transport security at all -  TLS, DTLS, Ipsec, etc. are not being
> used.  Since Diameter has no application security either, the only
> security deployed in the wild is firewalls.  Since an unprotected
> Diameter session carries information relating to user privacy such as
> usernames, location, etc. this makes it easy for an attacker snooping
> on the network to reap a bonanza of personal information about you -
> including your location at every moment. As the former AAA WG Chair
> who closed work on e2e security due to lack of interest from
> implementers, I am gratified to hear that work on e2e security is
> once again being considered.   However, it is a bit like having an
> illiterate express interest in reading Proust -- an admirable
> sentiment, but there are a few hurdles to get over first...

Heh. Yeah, I remember the previous Diameter e2e thing and how it
fizzled. I'm not up to speed on whether or not deployments are
turning on security, but in terms of RFC text things have gotten
better - I think the security stuff in RFC6733 shouldn't be too
hard to deploy at all. Of course, if it's only paper and not in
use, then yeah, things aren't really better.

I would have thought though that the likes of the Belgacom and
Gemalto incidents might have finally convinced AAA deployments
that they do need to turn this stuff on. If not, then I guess
we'll have to wait until some legislator or insurance company
forces 'em to do the right thing maybe.

But, maybe Lionel can say some more about the current state of
play?

S.

> 
> Date: Tue, 21 Apr 2015 13:26:07 -0400 From:
> [email-masked] To: [email-masked] CC:
> [email-masked]; [email-masked] Subject: Re: [saag] Request
> for guidance regarding E2E security over Diameter
> 
> Hello, A few weeks have past and I don't see any response to this
> request on-list.  Are there any volunteers that would like to assist
> DIME with e2e encryption for Diameter as described in Lionel's
> message? Thanks,Kathleen On Thu, Mar 26, 2015 at 12:24 PM,
> <[email-masked]> wrote: Hi,
> 
> 
> 
> As currently specified, the Diameter Base protocol (RFC6733) only
> offers transport level protection between neighboring Diameter peers,
> using either TLS/TCP, DTLS/SCTP, or IPsec as last resort. However, no
> mechanism has been defined to ensure E2E security for data (in the
> conveyed (in the form of Attribute-Value Pairs (AVPs)) in Diameter
> messages between two endpoints. Early 2000, at the beginning of the
> work on Diameter, CMS (Cryptographic Message Syntax) was identified
> as solution to provide AVP-level E2E security but this work was not
> completed due to lack of deployment interest (at least at that time)
> and the foreseen complexity of the developed solution for Diameter.
> 
> 
> 
> Due to the renewed interest for E2E security over Diameter, mainly
> for inter-domain signaling in the mobile network environment, the
> DIME WG has decided to reactivate the work on E2E security for
> Diameter. The first step is almost completed, with a document
> (draft-ietf-dime-e2e-sec-req-02) defining the requirements for an
> AVP-level E2E security solution. The second step will be work on the
> specification of such mechanism. An early proposal was to derive a
> solution from JOSE, encapsulating JOSE objects for integrity
> protection and AVP encryption. It is however expected that other
> mechanisms could be proposed as candidate solutions. And we know
> already that there are existing discussions on alternative to JOSE
> (e.g. COSE).
> 
> 
> 
> Whatever the proposed solution(s),the DIME WG has not (and will not
> have) the expertise required to evaluate and select the more
> appropriate security mechanism for E2E security over Diameter. We are
> therefore interested by any guidance and support from SAAG regarding
> the development of a solution for E2E security over Diameter, based
> on the requirements collected in draft-ietf-dime-e2e-sec-req-02.
> 
> 
> 
> Regards,
> 
> 
> 
> Lionel
> 
> 
> 
> pas etre diffuses, exploites ou copies sans autorisation. Si vous
> avez recu ce message par erreur, veuillez le signaler
> 
> a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages electroniques etant susceptibles d'alteration,
> 
> This message and its attachments may contain confidential or
> privileged information that may be protected by law;
> 
> If you have received this email in error, please notify the sender
> and delete this message and its attachments.
> 
> _______________________________________________ saag mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/saag
>

---

From: <[email-masked]>
Date: Wed, 22 Apr 2015 10:00:35 +0000

Hi Stephen,

When Diameter was used in Mobile networks for AAA-like procedures (user authentication, authorization profile management, etc.), the existing hop-by-hop security was quite OK, the overall security relying on trust relationship between mobile operators, through peering agreements or via GSMA roaming agreements. Especially in the early deployment of 4G networks in which few players were in the game when considering roaming use cases.

Now, the number of roaming partners is increasing and new models like roaming hub are deployed. Moreover, Diameter is now used also for other purposes, such as transport of SMS. Finally, Diameter has been enhanced to support overload control mechanism in which overload indication is exchanged E2E between mobile networks. 
In all these use cases, the primary security requirement is related to data origin authentication when requests are conveyed sometimes through one or more intermediaries.
There may be other requirements (I have to double check) but I think that the use cases given above are enough to reactivate the work on E2E security for Diameter. Obviously, the final E2E security framework would have to support other possible (future) use cases. 

Regards,

Lionel

-----Message d'origine-----
De : Stephen Farrell [mailto:[email-masked]] 
Envoyé : mardi 21 avril 2015 22:09
À : Bernard Aboba; Kathleen Moriarty; MORAND Lionel IMT/OLN
Cc : [email-masked]; [email-masked]
Objet : Re: [saag] Request for guidance regarding E2E security over Diameter

> sentiment, but there are a few hurdles to get over first...

Heh. Yeah, I remember the previous Diameter e2e thing and how it fizzled. I'm not up to speed on whether or not deployments are turning on security, but in terms of RFC text things have gotten better - I think the security stuff in RFC6733 shouldn't be too hard to deploy at all. Of course, if it's only paper and not in use, then yeah, things aren't really better.

I would have thought though that the likes of the Belgacom and Gemalto incidents might have finally convinced AAA deployments that they do need to turn this stuff on. If not, then I guess we'll have to wait until some legislator or insurance company forces 'em to do the right thing maybe.

But, maybe Lionel can say some more about the current state of play?

S.

> work on Diameter, CMS (Cryptographic Message Syntax) was identified as 
> solution to provide AVP-level E2E security but this work was not 
> inter-domain signaling in the mobile network environment, the DIME WG 
> has decided to reactivate the work on E2E security for Diameter. The 
> first step is almost completed, with a document
> the development of a solution for E2E security over Diameter, based on 
> the requirements collected in draft-ietf-dime-e2e-sec-req-02.
> 
> 
> 
> Regards,
> 
> 
> 
> Lionel
> 
> 
> 
> ______________________________________________________________________
> ___________________________________________________
>
> 
> 
>