Subject: [saag] Woefully deficient security considerations section.

From: Watson Ladd <[email-masked]>
Date: Fri, 22 Jan 2016 20:51:10 -0800

Dear all,

MIKEY-IBAKE and MIKEY-SAKKE are in the news as enabling LE intercept.
Imagine my surprise when I found not just one, but two RFCs describing
these options, both failing to mention the security properties they
had when trusted parties would be compromised, and in particular the
possibility of retroactive decryption in SAKKE. This should have been
noted by someone at some point. How do we make sure this doesn't
happen because reviews are being done by the wrong people?

Sincerely,
Watson

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 22 Jan 2016 21:44:10 -0800

Watson -

MIKEY-IBAKE (RFC6267) and MIKEY-SAKKE (RFC 6509) are both Informational RFCs.  It is common for such documents to receive less scrutiny than standards track documents.

IMHO, we could be more transparent about the level of review that Informational documents receive. For example, here is an (understated) IESG note from EAP-SIM, RFC 4186:

IESG Note 

The EAP-SIM protocol was developed by 3GPP. The documentation of EAP-SIM is provided as information to the Internet community. While the EAP WG has verified that EAP-SIM is compatible with EAP, as defined in RFC 3748, no other review has been done, including validation of the security claims. The IETF has also not reviewed the security of the cryptographic algorithms.

> On Jan 22, 2016, at 20:51, Watson Ladd <[email-masked]> wrote:
> 
> Dear all,
> 
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Jeffrey Walton <[email-masked]>
Date: Sat, 23 Jan 2016 01:12:42 -0500

> happen because reviews are being done by the wrong people?
Related, in mobile, we always consider infrastructure to be
compromised. Anything that interacts with a carrier's network is
burned.

"Carrier's network" is wishful thinking. Your device will camp to the
strongest signal. The network does not authenticate to the handset, so
you don't even know what network you are on or who is controlling it.
Also see Chris Paget's tricks with GNU Radio.

Secure mobile architectures, like NSA's Fishbowl, effectively tunnel
back to a server controlled by the organization. That's where VoIP and
SIP services are terminated. See, for example,Section 2.1.1, Security
Relevant Components, in the NSA Mobility Capability Package.

Jeff

---

From: Eliot Lear <[email-masked]>
Date: Sat, 23 Jan 2016 09:16:08 +0100

On the other hand, speaking as both a past WG chair and an author, I
never refuse help on security considerations section.  And here's a
reminder: not everyone is security savvy, and even those who are could
use a second, third, and fourth pair of eyes in that area.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 23 Jan 2016 17:06:41 +0000

Hi Watson,

> MIKEY-IBAKE and MIKEY-SAKKE are in the news as enabling LE intercept.

Yes. Not that it's news of course;-) Mind you, afaik about the only
users of those schemes are folks employed by those who tend to be
doing the interception. If that's not the case, that'd definitely
be interesting to know about.

As Bernard noted, these are informational RFCs and hence don't fall
under RFC2804, which says that we don't standardise LI.

> happen because reviews are being done by the wrong people?

Well, I don't think that's quite the right question. Phrases like
"wrong people" isn't going to help, and in this case the people
involved didn't do any wrong that I can see.

What we need to do is ensure as far as possible (given we're dealing
with volunteer effort) that drafts get good review. In these cases I'd
say the review was ok-ish, but it predates my time on the IESG so I
wasn't involved directly. If you're interested, the document histories
[1,2] and the secdir review threads [3,4] are as visible as ever. I'm
not sure but wouldn't be surprised if there had been previous discussion
on some wg lists.

But, similarly to the more recent case with IBS [5], it can be hard
to get folks to review what can be perceived as odd corner-case
crypto specs. The dual-ec fiasco of course does make that more clearly
important than was the case when these documents were processed.
In the case of [5], I'm still holding a discuss (>1 year later) [6]
on the basis that the scheme hasn't had public review. It's probably
fair to say that we're less tolerant of that lack now, than we were
5 years ago.

But note that even in the case of [5], all that the authors now need
to get me to unblock it is ack that public review will be one of the
things that would be needed to get that spec on the standards track at
some point. (I expect they may do that and an RFC will issue but we'll
see.) So this will likely end up similar to [1,2] in that there will
be an RFC describing a scheme vulnerable to a big brother, albeit
not on the standards track, a distinction that is not well understood
even within the IETF community sometimes. Changing that ("the
difference between standards-track and other kinds of RFC") would be
a fairly major undertaking, and not one that likely to succeed in a
useful manner IMO.

Lastly, in this case, if you (or anyone) think some specifications
really ought to be updated, then you are entirely free to write an
Internet-draft clarifying the situation that formally updates the RFC(s)
in question.

I'd certainly look positively on a draft that supplied important
missing information about the security properties of these, (or any),
IETF stream RFC. So if you (or anyone else) needs help/advice on how
one might go about doing that, just send me offlist mail and I'll try
help.

In the meantime, thanks Watson for accepting my invite to join the
secdir review process - that is certainly one way to try help improve
things.

Cheers,
S.

[1] https://datatracker.ietf.org/doc/rfc6509/history/
[2] https://datatracker.ietf.org/doc/rfc6267/history/
[3] https://www.ietf.org/mail-archive/web/secdir/current/msg02434.html
[4] https://www.ietf.org/mail-archive/web/secdir/current/msg02036.html
[5]
https://mailarchive.ietf.org/arch/search/?email_list=cfrg&gbt=1&index=rlo4nJkqio4HnVzS9_OIq9__byQ
[6] https://datatracker.ietf.org/doc/draft-ietf-manet-ibs/ballot/

---

From: Steve Crocker <[email-masked]>
Date: Sat, 23 Jan 2016 12:53:00 -0500

FWIW, as the first security area director, I created the SAAG to provide security expertise to working groups outside of the security area precisely because the concepts involved in security are different from functionality, which is usually the focus in the other areas, and because expertise was in short supply.

We didn't develop specific standards or requirements initially. Maybe it's time for such, even if only in lightweight form such as a checklist, eg "forward security?", etc.

Steve

Sent from my iPhone

> On Jan 23, 2016, at 3:16 AM, Eliot Lear <[email-masked]> wrote:
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 23 Jan 2016 20:28:19 +0100

Two issues:

* The security area directorate reviews all documents but the assignment
of reviewers to documents is sort of random. Hence, it is not
necessarily ensured that the right expertise is available with the right
reviewer. In this case, the reviewer of both documents was not a VoIP
security expert.

* The requirements for reviews change over time. There is a bit of
history related to the VoIP work -- see my other email. It is sometimes
difficult for the IETF to make decisions when it comes to certain
business models. Just look at the discussions that relate to what
network operators should be doing with traffic:
https://www.iab.org/activities/workshops/marnew/

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 23 Jan 2016 20:28:36 +0100

[A personal note on this subject.]

Hi Watson,

I worked on VoIP security and contributed various specifications to that
topic. At that time, there was the desire to accomplish an alignment
between the 3GPP and the IETF. But, as you can imagine, the requirements
were somewhat different and a few companies in the 3GPP had the desire
to consider lawful intercept in the design of their solution.

In the end both organizations went into a different direction but the
MIKEY RFC required extensions to go through the IETF process. Several
organizations, companies & persons wanted their own VoIP security
extensions standardized, which required folks in the IETF to-do a fair
amount of work for something nobody (in the IETF) was interested in.
Recognizing the problems these rules were relaxed, see
https://tools.ietf.org/html/rfc6309

But before those rules got relaxed various specifications were processed
by the IETF*. They unfortunately received only minimal review but got
published through the Standards Track and were shepherded by area
directors.

Unfortunately, these circumstances were not noted in the publication of
those RFCs and now it appears that those documents had gone through a
fair amount of review (and that those solutions are even endorsed by the
IETF). Needless to say that this far from the through.

Just as one data point, I commented on this difficult situation in a
mail early 2012:
https://www.ietf.org/mail-archive/web/emu/current/msg01844.html

I believe there is a lesson to be learned for the future, namely to more
clearly indicate the history of documents and the level of review
documents have received. While it may be obvious to those who were
involved in the work at that point in time it is less so after a few
years by external parties.

When you search for reviews done in the IETF for these specifications
then it is clear that very little had been done. I wonder whether the
IESG should have published a document with so little review as an
Informational RFC through the Standards Track process.

Ciao
Hannes

PS: I do not fully understand why MIKEY-SAKKE was published as an
information RFC through the Standards Track process given that the IANA
rules were relaxed already months before the publication of MIKEY-SAKKE.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 26 Jan 2016 15:33:39 +0200

> reviewer. In this case, the reviewer of both documents was not a VoIP

Actually that is partially by design. If we pick someone who is
familiar with the area (i.e. VoIP expert) he is most likely already
involved with the document, i.e., it is very likely that he has
reviewed the draft and thinks it ok.

Completely new fresh security review might find completely new issues
in the draft, especially as that new reviewer do not assume that much
on the things outside the spec. I.e. there has been reviews saying, I
do not see how this protocol protects against X, it might be
somewhere, but I cannot see it from this spec. And then we either
might find out that yes, there is another document which is used with
this and that protect from X (and add that to security considerations
section), or we might notice that no, there actually is nothing there
to protect from X.

Of course if you are security expert in some protocol or area, you
should really review all protocols related to that regardless whether
they are going to be assigned for you in secdir or not.

I myself for example try to review all IKE and IPsec related drafts. I
do hope that others do similar things.

You can also do secondary secdir review if you think you have
something to say on the subject even if you are not assigned as
reviewer, and if you send email to [email-masked], I can
also give you credit for your review, i.e. mark you on the list that
you will be skipped next time you do review...
-- 
[email-masked]