Subject: Re: [Dime] RE : Re: AW: unexpected consequence of deprecating E2E security in RFC 3588 bis

From: <[email-masked]>
Date: Mon, 1 Oct 2012 10:12:51 +0200

Hello all
if I understood Lionel correctly he proposes and I would clearly support that
 "you MUST NOT send messages with "e2e-sensitive" AVPs without e2e security"

Best regards Dieter 

-----Ursprüngliche Nachricht-----
Von: Stephen Farrell [mailto:[email-masked]] 
Gesendet: Sonntag, 30. September 2012 15:48
An: [email-masked]
Cc: Glen Zorn; Jacobsohn, Dieter; [email-masked]; [email-masked]; [email-masked]; Schröder, Stefan
Betreff: Re: RE : Re: AW: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis

Just checking I've got this right. The plan now is to say you MUST NOT send "e2e-sensitive" AVPs without e2e security and to have a list of currently known e2e-sensitive AVPs in 3588bis. If so, that seems like a good thing to me.

Maybe consider an IANA registry listing the e2e-sensitive AVPs that could be updated via expert review for when the current list gets outdated? Could be done later if needed though, so just a suggestion.

S.

On 09/30/2012 12:15 PM, [email-masked] wrote:
> Hi Glen,
> 
> After the list of avps, we should say:
> 
> "Diameter messages containing these AVPs and any other AVP considered as security-sensitive MUST only be sent..."
> 
> Regards,
> 
> Lionel
> -----Message d'origine-----
> De : Glen Zorn
> Envoyé :  29/09/2012, 14:33
> À : MORAND Lionel RD-CORE
> CC : Glen Zorn; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked] Objet : Re: 
> AW: [Dime] unexpected consequence of deprecating E2E security in RFC 
> 3588 bis
> 
> On 09/29/2012 05:39 PM, [email-masked] wrote:
> 
>> It is actually needed if we  don't want to lose info. These AVPs
>  > should be listed in a table in these sections with an indication 
> that  > is a list of AVPs that can be considered as 
> security-sensitive, in  > order to not start a discussion on which AVP 
> is really sensitive and  > which not. Anyway, designers will have to 
> decide what they want to do  > and this list is mainly for information.
>  >
> OK, this is what I've got now:
> 
> 13.3.  AVP Considerations
> 
>     Diameter AVPs often contain security-sensitive data; for example,
>     user passwords and location data, network addresses and cryptographic
>     keys.  The following AVPs defined in this document are considered to
>     be security-sensitive:
> 
>     o  Acct-Interim-Interval
> 
>     o  Accounting-Realtime-Required
> 
>     o  Acct-Multi-Session-Id
> 
>     o  Accounting-Record-Number
> 
>     o  Accounting-Record-Type
> 
>     o  Accounting-Session-Id
> 
>     o  Accounting-Sub-Session-Id
> 
>     o  Class
> 
>     o  Session-Id
> 
>     o  Session-Binding
> 
>     o  Session-Server-Failover
> 
>     o  User-Name
> 
>     Diameter messages containing these AVPs MUST only be sent protected
>     via mutually authenticated TLS or IPsec.  In addition, those messages
>     MUST NOT be sent via intermediate nodes unless there is end-to-end
>     security between the originator and recipient or the originator has
>     locally trusted configuration that indicates that end-to-end security
>     is not needed.  For example, end-to-end security may not be required
>     in the case where an intermediary node is known to be operated as
>     part of the same administrative domain as the endpoints so that an
>     ability to successfully compromise the intermediary would imply a
>     high probability of being able to compromise the endpoints as well.
>     Note that no end-to-end security mechanism is specified in this
>     document.
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> 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, France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>

---

From: <[email-masked]>
Date: Tue, 2 Oct 2012 12:40:27 +0200

Hello all
a question for me is also what exactly do we mean by:

> "MUST NOT be sent via intermediate nodes unless there is end-to-end 
> security between the originator and recipient "

Which kind of e2e security? There is no such thing in Diameter right now, or did I miss something?
We can only do e2e security by hop-by-hop security (IPsec or TLS), if there is NO intermediate (Diameter) node.
So, either we have e2e security, then there is no intermediate node - or we have intermediate nodes, then there can't be e2e security. 

Best regards
Dieter Jacobsohn

Deutsche Telekom AG
Group Technology
Dieter Jacobsohn
Landgrabenweg 151, 53227 Bonn
+49 228 936-18445 (Tel.)
+49 391 5801 46624 (Fax)
+49 171 2088 710 (Mobil)
E-Mail: [email-masked]
www.telekom.com    

Erleben, was verbindet.  

Deutsche Telekom AG
Aufsichtsrat: Prof. Dr. Ulrich Lehner (Vorsitzender)
Vorstand: René Obermann (Vorsitzender),
Dr. Manfred Balz, Reinhard Clemens, Niek Jan van Damme,
Timotheus Höttges, Claudia Nemat,  Prof. Dr. Marion Schick
Handelsregister: Amtsgericht Bonn HRB 6794
Sitz der Gesellschaft Bonn
USt-IdNr. DE 123475223

Große Veränderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken.

---

From: jouni korhonen <[email-masked]>
Date: Wed, 3 Oct 2012 11:43:35 +0300

> Which kind of e2e security? There is no such thing in Diameter right now, or did I miss something?

There is no such thing.. But we have the lack of it reflected in our charter.
Two meetings ago we had some discussion around the topic during the WG meeting.

> So, either we have e2e security, then there is no intermediate node - or we have intermediate nodes, then there can't be e2e security. 

As for now, you can go around this for coming applications by application
specific means; like defining AVPs that inherently only carry encrypted
payload etc.

- Jouni

> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime