Subject: [saag] PSK considered helpful

From: Watson Ladd <[email-masked]>
Date: Mon, 29 Dec 2014 11:00:51 -0500

Dear all,

The NSA is devoting a great deal of effort to exploiting IPsec, PPTP,
SSH, etc. From the documents it appears that the majority of effort is
in extracting configurations from routers that contain PSK keys, which
then permit the decryption of data.

There is no information on how the configurations are being extracted,
sadly, as the documents don't contain this detail.

I think the decision made in TLS 1.3 to use forward secure methods
exclusively ought to be emulated more broadly across the security
area. Would one BCP on this across everything make sense, or do we
have to do it one at a time?

Sincerely,
Watson

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Dec 2014 17:57:30 +0000

> sadly, as the documents don't contain this detail.

Yeah, pity about that. They do talk about mining config files
from routers in one of the files though, maybe that all starts
from admin/admin and builds from there, who knows;-)

I also haven't yet seen any info on how successful they claim
to be, e.g. with what probability would the "request key" call
give back a working key? The importance of this stuff would be
affected a lot by that I figure - if the probability is high
over all domains/VPNs then that'd be much worse than if the
probability was tiny for a randomly selected VPN.

> have to do it one at a time?

A BCP could be useful yes, but protocols (such as TLS) are only
really revised when there's sufficient reason for that and enough
folks want to do the work. So even with a generic BCP, the actual
protocol specs still need to be done one at a time. Hopefully,
if there were a generic BCP that'd feed into each instance of that
work though.

I also suspect there'd be push-back on trying to entirely
deprecate PSK - it's arguably just too useful to drop fully.
So what might make for a good BCP is to recommend something more
like an opportunistic DH exchange with a PSK used to authenticate
that there's no MitM (i.e. the PSK is only for authentication
and never for confidentiality).

Lastly, we do already have bcp107 [1] though, so what you're after
could be an updated version of that maybe. That update might
require more work than just adding "prefer forward secrecy" though.
I've found that bcp107 hasn't been that useful a guide for folks
developing protocols and nor has it been that useful a stick for
beating them with either when protocol developers ignore key
management. That's maybe because it's too late in the process by
the time a SEC AD tries to use bcp107 as a stick. So updating
bcp107 might require a good bit of thought/work. (If someone does
feel they have the ablity/interest/energy, ping Kathleen and I
I guess.)

Cheers,
S.

[1] https://tools.ietf.org/html/bcp107

> 
> Sincerely,
> Watson
> 
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
> 
>

---

From: Warren Kumari <[email-masked]>
Date: Wed, 31 Dec 2014 13:05:40 -0500

> deprecate PSK - it's arguably just too useful to drop fully.

Yup.
Many moons ago I used to spend significant amounts of time building
IPSec VPNs for a large ISP ('twas great - VoIP over GRE over IPsec
over crappy copper from Dulles, VA, USA to various call centers in
India - what could *possibly* go wrong....)

Anyway, we'd often end up with different vendors at each end
(Netscreen, Cisco (IOS/PIX/ASA), Checkpoint(!), 3COM, etc). I'd always
try and make this work with certs, but in many cases the only way to
make this work between Vendor X and Vendor Y to resort to a PSK, which
of course got slapped into NVRAM and never changed. For a while there
was an effort to make sure that all devices were wiped before being
RMA'ed, but this eventually fell by the wayside.
I had a large matrix of the highest security between all of the
vendors, and some scripts to generate the best configs, but eventually
engineers get bored, and everything ended up 3DES, SHA1, DH Group 2
and no PFS.

So, if you were sufficiently motivated you too could listen in on a
thousand call center reps all chanting "Have you tried turning it off
and on again?"

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 31 Dec 2014 14:22:57 -0800

> sadly, as the documents don't contain this detail.

Having looked at some (but certainly not all) of the recently-highlighted documents, I do not see discussion of IPsec and  PSK. Could you send this list a specific reference? I ask because PSK mode in IKE would not allow later decryption of data: it is only used for authentication.

You might instead be thinking of "static keying", which is in IPsec and not IKE, and would certainly allow later decryption because the IPsec session key never changes. If that is what you are referring to, this becomes much less worrisome from a protocol standpoint, because we have known and documented all along that static IPsec keying is horribly dangerous; most vendors make this clear in their admin front ends. If it is not what you are referring to, seeing the actual documents might help the IPsecME WG determine how to make IPsec and IKEv2 more secure.

--Paul Hoffman

---

From: Watson Ladd <[email-masked]>
Date: Wed, 31 Dec 2014 17:45:03 -0500

> You might instead be thinking of "static keying", which is in IPsec and not IKE, and would certainly allow later decryption because the IPsec session key never changes. If that is what you are refe…

So I asked Yoav Nir what was going on, and looked at some more
documents, in particular those relating POISONNUT. All of this was
from der Spiegel: I don't have access to any Snowden docs not
publically released, and the data that lead me to the conclusions
below is spread out over multiple ones.

What is happening, according to Yoav and the other documents I looked
at, is a MITM attack on IKE exchanges using PSK. In a first stage the
PSK is brute-forced or found via software vulnerabilities, or
interception of email or IM chat containing it. In the second stage
when an IKE exchange is observed using this PSK, a MITM attack is
performed, and the data can be decrypted. I'm less certain of the
second half then the first.

What is true is the data decryption requires a near real time passing
of the IKE exchange to a CES computer, which runs the attack.

It's basically IKEcrack on steroids.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 31 Dec 2014 15:01:03 -0800

> second half then the first.

Thanks, that makes perfect sense. When you wrote "which then permit the decryption of data", I thought you meant "decrypt passively snooped data" and/or "decrypt previously captured data". If an attacker can see your config and find the PSK for authentication, they can probably also see the private key for asymmetric keying authentication.

> of the IKE exchange to a CES computer, which runs the attack.

The attack you describe should require a true "in the middle" that is decrypting from one end and then impersonating before re-encrypting on the other. Simply seeing the traffic in near-real-time would not be sufficient. Possibly that's what you are saying but, if so, I'm not sure why you say "near real time".

> It's basically IKEcrack on steroids.

The attack above is unrelated to IKEcrack in that IKEcrack only worked with Aggressive mode in IKEv1, and was used to determine the PSK by brute force.

--Paul Hoffman