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

[<[e-mail]>]

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; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Objet : Re: AW: [Dime] unexpected consequence of deprecating E2E security in RFC 3588 bis

On 09/29/2012 05:39 PM, [e-mail] 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.