Re: [Dime] Stephen Farrell's Discuss on draft-ietf-dime-erp-16: (with DISCUSS and COMMENT)

[Benoit Claise <[e-mail]>]

draft-ietf-dime-erp authors,

Please address this feedback, ideally before the IESG telechat this 
Thursday.

Regards, Benoit
> Stephen Farrell has entered the following ballot position for
> draft-ietf-dime-erp-16: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
>
> This might be a no-brainer, but I wanted to check. RFC 6734
> says that messages containing keys MUST be protected either
> via some Diameter-specific scheme (an e2e scheme is being
> developed, but is not yet done, right?) or else via
> mutually-authenticated TLS or IPsec. This draft says that the
> security considerations of 6734 apply, which means that the
> response messages MUST be protected like that if they contain
> keys. So far so good.  However, that leaves open the
> possibility that the request or error messages defined here
> could be sent unprotected, or am I mis-reading things? If not,
> then any attack that could be mounted based on a cleartext
> request would arguably be new here.  Are there such attacks?
> I'm not sure. Would it help in any case to re-state the MUST
> from 6734 here but to also include the request messages that
> (all going well) cause keys to be sent in responses (and error
> messages) and say that all that has to use the same e.g. TLS
> session or involve the same entities? (If e.g. TLS was only
> turned on for responses, then I'd start to be worried about
> the kind of problem that caused us to do the TLS
> re-negotiation fix, RFC 5746, but I've not tried to figure out
> if there's a real new attack yet, maybe the authors thought
> that through already?)
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> - I think it'd be clearer to say TBD1 everywhere you mean that
> rather than sometimes say <Diameter ERP>. Also, are those
> angle brackets missing in the 1st para of section 7?
>
> - Ought there be a space in the name of the TBD4 value in 9.1?
> (I guess not since its not in 10.3)
>
>
>
>