Subject: Re: [ippm] Stephen Farrell's Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS and COMMENT)

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 20 May 2015 15:04:45 -0500

Again, just following up ...

On Wed, Apr 8, 2015 at 11:57 AM, MORTON, ALFRED C (AL) <[email-masked]>
wrote:

> Hi Stephen,
> a reply to your comment from a non-author--*wamp-watcher below,
>
>
> > -----Original Message-----
> > From: ippm [mailto:[email-masked]] On Behalf Of Stephen Farrell
> > Sent: Wednesday, April 08, 2015 12:35 PM
> ...
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> >
> > Since you're touching on the key managment code, I'd have loved to see
> > you also update the O/TWAMP crypto itself to e.g.
> > use an AEAD cipher rather than AES-CBC. Did the WG consider that? (I
> > assume it's too late now, but I'm not clear from the write-up if this is
> > implemented or not, so I guess there's a small chance that the WG may
> > want to update more than just the key mgmt.)
> >
>
> The IPsec feature is an optional capability, and that's the scope limit of
> the draft, so it falls far short of replacing the current crypto features.
>
> Way back in <IETF meeting after Dublin>, I investigated using a "more
> conventional"
> crypto for TWAMP (at least for the Control connection)
> and asked whether the WG was interested - no takers.
> Pasi Eronen (SEC AD at the time) had encouraged the
> investigation/question2wg
> following the IESG review/approval of the TWAMP spec.
> At some future time, the answer might be different.

I saw Al's response to Stephen's Discuss, but I haven't seen anything
further from the authors. Could someone let us know if Al's response is the
one we should be discussing with Stephen?

Thanks,

Spencer

> Al

---

From: Kostas Pentikousis <[email-masked]>
Date: Fri, 29 May 2015 15:41:50 +0200

Dear Stephen, all,
| ----------------------------------------------------------------------
| DISCUSS:
| ----------------------------------------------------------------------
| 
| 
| Are O/TWAMP vulnerable to reflection attacks with this scheme?
| If so that's not good. Sorry that I didn't manage to figure that out in the
| time available but I'm hoping you can just tell me the answer quickly:-) If
| it's not vulnerable, that's great though it might be worth making that
| clearer. If it is, then that seems like a bad plan about which we ought chat.
| The usual solution would be to derive different keys for each direction of
| use, and just say to use those appropriately.
| And even if O/TWAMP are thusly vulnerable with a PSK, it'd be fine, and quite
| possible to fix that here now we're doing better key mgmt.
| 

No, it's not vulnerable. The security mechanisms in RFC4656 and RFC5618 are all based on PSK. This draft only proposed to derive PSK from IKEv2 SA.

| ----------------------------------------------------------------------
| COMMENT:
| ----------------------------------------------------------------------
| 
| 
| Since you're touching on the key managment code, I'd have loved to see you
| also update the O/TWAMP crypto itself to e.g.
| use an AEAD cipher rather than AES-CBC. Did the WG consider that? (I assume
| it's too late now, but I'm not clear from the write-up if this is implemented
| or not, so I guess there's a small chance that the WG may want to update more
| than just the key mgmt.)

This draft does not update the O/TWAMP crypto, which is still as defined as per RFC4656 and RFC5618. So this is out of scope for this document.

Best regards,

Kostas

---

From: Kostas Pentikousis <[email-masked]>
Date: Fri, 29 May 2015 15:43:42 +0200

Hi Al, all,

| Way back in <IETF meeting after Dublin>, I investigated using a "more
| conventional"
| crypto for TWAMP (at least for the Control connection)
| and asked whether the WG was interested - no takers.
| Pasi Eronen (SEC AD at the time) had encouraged the investigation/question2wg
| following the IESG review/approval of the TWAMP spec.
| At some future time, the answer might be different.

I think once this draft is done, we could put some effort to work on this. I would be interested in contributing at least.

Best regards,

Kostas

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 May 2015 15:39:47 +0100

On 29/05/15 14:41, Kostas Pentikousis wrote:
> Dear Stephen, all, |
|
> | | Are O/TWAMP vulnerable to reflection attacks with this scheme? |
> If so that's not good. Sorry that I didn't manage to figure that out
> in the | time available but I'm hoping you can just tell me the
> answer quickly:-) If | it's not vulnerable, that's great though it
> might be worth making that | clearer. If it is, then that seems like
> a bad plan about which we ought chat. | The usual solution would be
> to derive different keys for each direction of | use, and just say to
> use those appropriately. | And even if O/TWAMP are thusly vulnerable
> with a PSK, it'd be fine, and quite | possible to fix that here now
> we're doing better key mgmt. |
> 
> No, it's not vulnerable. The security mechanisms in RFC4656 and
> RFC5618 are all based on PSK. This draft only proposed to derive PSK
> from IKEv2 SA.

Ok thanks - I've cleared.

Cheers,
S.

|
> | | Since you're touching on the key managment code, I'd have loved
> to see you | also update the O/TWAMP crypto itself to e.g. | use an
> AEAD cipher rather than AES-CBC. Did the WG consider that? (I assume 
> | it's too late now, but I'm not clear from the write-up if this is
> implemented | or not, so I guess there's a small chance that the WG
> may want to update more | than just the key mgmt.)
> 
> This draft does not update the O/TWAMP crypto, which is still as
> defined as per RFC4656 and RFC5618. So this is out of scope for this
> document.
> 
> Best regards,
> 
> Kostas
>