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

[Glen Zorn <[e-mail]>]

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.