Re: [secdir] Security review of draft-ietf-perc-srtp-ekt-diet-08

[Benjamin Kaduk <[e-mail]>]

On Wed, Dec 19, 2018 at 11:15:08AM -0500, Richard Barnes wrote:
> Hi Hilarie,
> 
> Thanks for the review.  Sorry for the delay in responding.  Responses
> inline.
> 
> On Wed, Oct 31, 2018 at 4:39 PM Hilarie Orman <[e-mail]>
> wrote:
> 
> > Security review of Encrypted Key Transport for DTLS and Secure RTP
> > draft-ietf-perc-srtp-ekt-diet-08
> >
> > Do not be alarmed.  I have reviewed this document as part of the
> > security directorate's ongoing effort to review all IETF documents
> > being processed by the IESG.  These comments were written primarily
> > for the benefit of the security area directors.  Document editors and
> > WG chairs should treat these comments just like any other last call
> > comments.
> >
> > The draft defines a way by which each sender in a multi-participant
> > session can communicate its encrypting key (called a "master key") to
> > the other participants.  In this scheme, all participants learn a
> > key encrypting key (EKTKey) that is used to protect sender's
> > encrypting keys during transit.
> >
> > "This specification also defines a way to send the encrypted SRTP
> >    master key (with the EKTKey) along with the SRTP packet ...
> >    Endpoints that receive this and know the EKTKey can use the EKTKey
> >    to decrypt the SRTP master key which can then be used to decrypt
> >    the SRTP packet."
> >
> > I think that the paragraph above would be clearer if "(with the
> > EKTkey)" were changed to "(encrypted with the EKTkey)".
> >
> 
> Ack, queued pending resolution of other topics here.

(I don't see this in the -09; am I looking in the wrong place?)

> 
> 
> > I do not understand the security model.  If all participants know the
> > EKTkey, then why do senders need to separately select their own
> > individual keys?  Cannot all participants use something derived from
> > the EKTkey?  Is this a legacy thing?
> >
> 
> Yes, it's precisely a legacy thing, in a couple of ways.  The most
> important one is that in the SRTP conferencing context, there's not really
> an identifier that you can rely on being distinct per participant, so
> basically you don't have a label to put into the KDF.  A secondary
> consideration (not required for PERC AFAIK) is that this allows keys from
> external systems to be bridged into an EKT-enabled conference.
> 
> If there were only the first concern, you could do something like use the
> random value the endpoints make up as a KDF input (together with the master
> key) instead of a key.  But that would cut off the second use case, which I
> would hesitate to do without some list discussion.
> 
> Do you have a security concern here, or is this just a question for
> understanding?  I agree that there's some risk that endpoints will generate
> bad keys, but it seems like if you're unable to generate good keys, you
> have bigger problems.

I guess there's a little bit more overhead in schlepping around more key
material, but it's probably in the noise here.

> 
> >
> > Section 4.4 states that
> >    "EKT uses an authenticated cipher to encrypt and authenticate the
> >    EKTPlaintext."
> >
> > Also section 6 (security considerations) states:
> >    The EKT Cipher includes its own authentication/integrity check.  For
> >    an attacker to successfully forge a FullEKTField, it would need to
> >    defeat the authentication mechanisms of the EKT Cipher authentication
> >    mechanism.
> >
> > Section 4.4.1 state "The default EKT Cipher is the Advanced Encryption
> >    Standard (AES) Key Wrap with Padding [RFC5649] algorithm."
> >
> > RFC5649 does not purport to define an authenticated cipher.  I am not
> > sure what properties of RFC5649 are the ones that are considered
> > important, so I cannot recommend appropriate wording, though I suspect
> > that "integrity" is the right word, not "authentication".
> >
> 
> What do you consider the difference between "integrity" and
> "authentication" here?  ISTM that these two are usually are very commonly
> conflated at the crypto layer (vs. higher layers of authentication like
> PKIs).  For example, message *authentication* codes are a commonly used for
> integrity protection.

Yes ... but an "authentication mechanism" I would tend to expect to provide
authentication that's strong enough to be useful for an authorization
decision (i.e., binding to some name or other identity).

> 
> 
> > I have one concern about the requirement that all senders change their
> > keys when the EKTKey changes.  Suppose a malicious participant manages
> > to create a replay attack that sends a EKTkey message with a key that
> > was previously used, perhaps even the same one that is currently used.
> > This would force all participants to change their keys, perhaps at a
> > very high rate, and this might lead to denial of service.
> > Participants might be advised to ignore EKTkey messages that repeat
> > the current EKTkey.
> >
> 
> This is a good idea.  Queued pending resolution of other topics here.

Thanks for that.

-Benjamin