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

[Glen Zorn <[e-mail]>]

On 09/27/2012 05:01 PM, [e-mail] wrote:
>
 > Hello Glen After discussing it also with some security people I think
 > that the existing text is more accurate and should stay. The existing
 > text refers to "intermediary is known to be operated as part of the
 > same administrative domain as the endpoints", which is fine.

The current text assumes that exactly the same security measures are 
applied to the endpoints and any intermediates.  I think that this 
assumption is basically groundless.

> We don't have end-to-end  security in 3588bis, true. But 13.3 offers
 > exactly this party1-to-party2 security as almost equivalent to e2e
 > security.

AFAICT, it offers the assertion that "Our network is secure." and 
basically nothing else.

>
 > The new proposed text would allow other alternatives beyond that,
 > based on "locally trusted configuration". But what does that mean in
 > practice? I think such a statement would allow just anything and move
 > away from any tangible technical security.

Unless bare assertions constitute technical security, it doesn't move 
away from anything.  Be that as it may, the current text says "In 
addition, those messages SHOULD NOT be sent via intermediate nodes that 
would expose the sensitive data at those nodes".   As I understand it, 
"SHOULD NOT" means "don't do it unless you have a good reason to", but 
the definition of "good reason" is pretty much up in the air.  Is the 
simple assertion of security a "good reason"?  Sounds like it.  By 
contrast, RFC 3588 says that messages containing sensitive AVPs MUST NOT 
be sent through untrusted intermediaries; that is the part I want to see 
remain.  Admittedly, it's a small thing, but it's something; I'm sure 
that people are going to do whatever they like anyway, but at least they 
might stop and think a bit more when they see a MUST.  "Blindly trust 
every host in this domain because I say so" could still be the policy, 
but it would need to be configured as such (which I suspect is actually 
the issue here).

>
 > Best Regards Dieter Jacobsohn
 >
 >
 > Deutsche Telekom AG Group Technology Dieter Jacobsohn Landgrabenweg
 > 151, 53227 Bonn [phone] (Tel.) [phone] (Fax) +49
 > 171 2088 710 (Mobil) E-Mail: [e-mail]
 > 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.
 >
 >
 > -----Ursprüngliche Nachricht----- Von: [e-mail]
 > [mailto:[e-mail]] Im Auftrag von Glen Zorn Gesendet:
 > Donnerstag, 27. September 2012 05:58 An: [e-mail] Cc:
 > draft-ietf-dime-rfc3588bis; dime mailing list; turners; Stephen
 > Farrell Betreff: Re: [Dime] unexpected consequence of deprecating E2E
 > security in RFC 3588 bis
 >
 > On 09/27/2012 01:26 AM, [e-mail] wrote:
 >
 > Copying the Security ADs.
 >
 >> Is it somehow covered in
 >> http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-34#section-13.3?
 >
 >>
 >
 >>
 >>
 > Diameter AVPs often contain security-sensitive data; for example,
 >> user passwords and location data, network addresses and
 >> cryptographic keys. The Diameter messages containing such AVPs MUST
 >> > only be sent protected via mutually authenticated TLS or IPsec.
 >> In > addition, those messages SHOULD NOT be sent via intermediate
 >> nodes > that would expose the sensitive data at those nodes except
 >> in cases > where an intermediary 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.
 >>
 >> Do you think that it is needed to add somewhere that "the
 >> originator > has locally trusted configuration that indicates that
 >> end-to-end > security is not needed"?
 >
 > I think that something should be done since as it stands the language
 > is weaker in bis than in RFC 3588; the protocol is actually less
 > secure :-(. I would suggest changing Section 13.3 (quoted above) to
 > say some thing like this:
 >
 > Diameter AVPs often contain security-sensitive data; for example,
 > user passwords and location data, network addresses and
 > cryptographic keys. The Diameter messages containing such 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, where
 > an intermediary 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,
 > however, that no end-to-end security mechanism is specified in this
 > document.
 >
 > However, I don't really want to delay publication any more than I
 > already have ;-), so if that change would trigger a whole new IESG
 > review (or worse, another IETF LC) I would rather handle it in an
 > erratum later.
 >
 >>
 >>
 >> Lionel
 >>
 >>
 >> -----Message d'origine----- De : [e-mail]
 >> [mailto:[e-mail]] De la part de Glen Zorn Envoyé :
 >> mercredi 26 septembre 2012 12:47 À : draft-ietf-dime-rfc3588bis Cc
 >> : dime mailing list Objet : [Dime] unexpected consequence of
 >> deprecating E2E security in RFC 3588 bis
 >>
 >> Section 4.5 of RFC 3588 says: The following table describes the
 >> Diameter AVPs defined in the base protocol, their AVP Code values,
 >> types, possible flag values and whether the AVP MAY be encrypted.
 >> For the originator of a Diameter message, "Encr" (Encryption)
 >> means that if a message containing that AVP is to be sent via a
 >> Diameter agent (proxy, redirect or relay) then the message MUST NOT
 >> be sent unless there is end-to-end security between the originator
 >> and the recipient and integrity / confidentiality protection is
 >> offered for this AVP OR the originator has locally trusted
 >> configuration that indicates that end-to-end security is not
 >> needed. Similarly, for the originator of a Diameter message, a "P"
 >> in the "MAY" column means that if a message containing that AVP is
 >> to be sent via a Diameter agent (proxy, redirect or relay) then the
 >> message MUST NOT be sent unless there is end-to-end security
 >> between the originator and the recipient or the originator has
 >> locally trusted configuration that indicates that end-to-end
 >> security is not needed.
 >>
 >> The corresponding section of 3588bis says: The following table
 >> describes the Diameter AVPs defined in the base protocol, their
 >> AVP Code values, types, and possible flag values.
 >>
 >> Considerable information (and normative guidance) seems to have
 >> been lost here: in particular, the statements that "the message
 >> MUST NOT be sent unless... the originator has locally trusted
 >> configuration that indicates that end-to-end security is not
 >> needed" would seem to be valid even in the absence of an E2E
 >> security solution. _______________________________________________
 >> DiME mailing list [e-mail]
 >> https://www.ietf.org/mailman/listinfo/dime
 >>
 >>
 > 
_________________________________________________________________________________________________________________________
 >
 >
 >
 >>
 >>
 > 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.
 >>
 >
 >
 > _______________________________________________ DiME mailing list
 > [e-mail] https://www.ietf.org/mailman/listinfo/dime