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

From: Glen Zorn <[email-masked]>
Date: Wed, 26 Sep 2012 17:46:36 +0700

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.

---

From: <[email-masked]>
Date: Wed, 26 Sep 2012 18:26:41 +0000

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

Lionel

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 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

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
[email-masked]
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.

---

From: Glen Zorn <[email-masked]>
Date: Thu, 27 Sep 2012 10:57:55 +0700

On 09/27/2012 01:26 AM, [email-masked] wrote:

Copying the Security ADs.

> Is it somehow covered in
 > http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-34#section-13.3?
 >
 >
 >
> 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
 > Do you think that it is needed to add somewhere that "the originator
 > 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 : [email-masked]
 > [mailto:[email-masked]] 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.
 >
 > 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
 > [email-masked] 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.
 >

---

From: <[email-masked]>
Date: Thu, 27 Sep 2012 12:01:35 +0200

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

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.

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. 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Glen Zorn
Gesendet: Donnerstag, 27. September 2012 05:58
An: [email-masked]
Cc: draft-ietf-dime-rfc3588bis; dime mailing list; turners; Stephen Farrell
Betreff: Re: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis

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

---

From: Glen Zorn <[email-masked]>
Date: Thu, 27 Sep 2012 18:03:57 +0700

On 09/27/2012 05:01 PM, [email-masked] 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 +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
 >
 > -----Ursprüngliche Nachricht----- Von: [email-masked]
 > [mailto:[email-masked]] Im Auftrag von Glen Zorn Gesendet:
 > Donnerstag, 27. September 2012 05:58 An: [email-masked] Cc:
 > draft-ietf-dime-rfc3588bis; dime mailing list; turners; Stephen
 > Farrell Betreff: Re: [Dime] unexpected consequence of deprecating E2E
 > security in RFC 3588 bis
 >
 >> > 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:
 >
 > addition, those messages MUST NOT be sent via intermediate nodes
 > unless there is end-to-end security between the originator and
 > indicates that end-to-end security is not needed (for example, where
 > an intermediary is known to be operated as part of the same
 > probability of being able to compromise the endpoints as well). Note,
 > however, that no end-to-end security mechanism is specified in this
 > document.
 >
 > 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
 >>
 >>
 >> mercredi 26 septembre 2012 12:47 À : draft-ietf-dime-rfc3588bis Cc
 >> : dime mailing list Objet : [Dime] unexpected consequence of
 >> 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.
 >>
 >> 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 [email-masked]
 >> 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.
 >>
 >> 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: Sat, 29 Sep 2012 10:08:15 +0000

Hi Glen,

I'm OK with the "MUST NOT... unless" approach that is stronger than "SHOULD NOT... unless".
The last part could be slightly modified as follow:

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

The "may not be required" indicates that it is a design option and the default rule is "E2E security is required for those AVPs".

Regards,

Lionel

-----Message d'origine-----
De : Glen Zorn [mailto:[email-masked]] 
Envoyé : jeudi 27 septembre 2012 13:04
À : [email-masked]
Cc : [email-masked]; MORAND Lionel RD-CORE; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Objet : Re: AW: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis

---

From: Glen Zorn <[email-masked]>
Date: Sat, 29 Sep 2012 17:19:51 +0700

On 09/29/2012 05:08 PM, [email-masked] wrote:

> Hi Glen,
 >
 > I'm OK with the "MUST NOT... unless" approach that is stronger than
 > "SHOULD NOT... unless". The last part could be slightly modified as
 > follow:
 >
 > 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
 > probability of being able to compromise the endpoints as well. Note
 > that no end-to-end security mechanism is specified in this document.
 >
 > The "may not be required" indicates that it is a design option and
 > the default rule is "E2E security is required for those AVPs".

This is fine.  I noticed that another important piece of data was lost 
in the shuffle, as well: in RFC 3588, the AVPs considered to contain 
security-sensitive data were marked as such in the AVP tables, but in 
the revision they're not.  This makes the MUST NOT above pretty close to 
useless.  I think that we probably need to list those AVPs in this 
section, as well.

>
 > Regards,
 >
 > Lionel
 >
 > -----Message d'origine----- De : Glen Zorn
 > [mailto:[email-masked]] Envoyé : jeudi 27 septembre 2012 13:04 À
 > : [email-masked] Cc : [email-masked]; MORAND Lionel
 > RD-CORE; [email-masked]; [email-masked];
 > [email-masked]; [email-masked];
 > [email-masked] Objet : Re: AW: [Dime] unexpected
 > consequence of deprecating E2E security in RFC 3588 bis
 >
 >> 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.
 >
 >> 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.
 >
 >> 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.
 >
 > 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).
 >
 >>
 >> 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.
 >>
 >> Claudia Nemat, Prof. Dr. Marion Schick Handelsregister:
 >> Amtsgericht Bonn HRB 6794 Sitz der Gesellschaft Bonn USt-IdNr. DE
 >> 123475223
 >>
 >> Donnerstag, 27. September 2012 05:58 An: [email-masked]
 >> Cc: draft-ietf-dime-rfc3588bis; dime mailing list; turners;
 >> Stephen Farrell Betreff: Re: [Dime] unexpected consequence of
 >>> 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.
 >>>
 >>> 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:
 >>
 >> 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
 >> 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.
 >>
 >>> mercredi 26 septembre 2012 12:47 À : draft-ietf-dime-rfc3588bis
 >>> Cc : dime mailing list Objet : [Dime] unexpected consequence of
 >>> 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
 >>> 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
 >>> the recipient or the originator has locally trusted configuration
 >>> that indicates that end-to-end security is not needed.
 >>>
 >>> security solution.
 >>> pas etre diffuses, exploites ou copies sans autorisation. Si
 >>> vous avez recu ce message par erreur, veuillez le signaler a
 >>> Telecom - Orange decline toute responsabilite si ce message a
 >>> ete altere, deforme ou falsifie. Merci.
 >>>
 >>> 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: Sat, 29 Sep 2012 10:39:03 +0000

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.

Lionel

-----Message d'origine-----
De : Glen Zorn [mailto:[email-masked]] 
Envoyé : samedi 29 septembre 2012 12:20
À : 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

 >>> MUST

---

From: Glen Zorn <[email-masked]>
Date: Sat, 29 Sep 2012 19:33:29 +0700

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.

---

From: <[email-masked]>
Date: Sun, 30 Sep 2012 11:15:11 +0000

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

13.3.  AVP Considerations

    o  Acct-Interim-Interval

    o  Acct-Multi-Session-Id

    o  Accounting-Record-Type

    o  Accounting-Session-Id

    o  Class

    o  Session-Id

    o  Session-Binding

    o  User-Name

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 30 Sep 2012 14:48:08 +0100

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.

---

From: Glen Zorn <[email-masked]>
Date: Mon, 01 Oct 2012 10:32:29 +0700

On 09/30/2012 06:15 PM, [email-masked] wrote:

 > "Diameter messages containing these AVPs and any other AVP considered
 > as security-sensitive MUST only be sent..."

OK.

...

---

From: Glen Zorn <[email-masked]>
Date: Mon, 01 Oct 2012 10:34:30 +0700

On 09/30/2012 08:48 PM, Stephen Farrell wrote:

>
 > Just checking I've got this right. The plan now is to say you MUST
 > NOT send "e2e-sensitive" AVPs without e2e security

Or explicit policy that says it's OK.

> and to have a list
 > of currently known e2e-sensitive AVPs in 3588bis.

Yup.

> If so, that seems
 > like a good thing to me.

OK, cool.

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

I think later is better.

...