Subject: PILC IETF-51 discussion on LINK Security Considerations

From: Aaron Falk <[email-masked]>
Date: Tue, 07 Aug 2001 12:51:52 -0400

Phil-

(saag list cc'ed for heads up. Ref: draft-ietf-pilc-link-design-06.txt 
section on security considerations)

This is my take on the issues that were raised today regarding the Security 
Considerations section of LINK:

* end-to-end encryption is the best way to protect user data: clear 
consensus

* subnet designers should use security mechanisms to protect the network: 
clear consensus

* subnets may protect against traffic analysis: clear consensus

* subnets may use link encryption to protect against traffic analysis: 
mixed         consensus, evesdroppers may gain access to cleartext at 
access points,     pre-encryption

* it is not appropriate for PILC to recommend use of link encryption to 
protect user data: clear consensus, it's easy to get wrong, it can lead to 
a false sense of security

* wireline equivalent privacy is a poorly defined concept which PILC should 
not advocate: rough consensus

Now, my thoughts:

IP encryption does not provide complete privacy: IP addresses are still in 
the clear and it is possibly that an evesdropper could identify which web 
site a user is accessing, e.g., the sex.com example. So, perhaps we can get 
consensus if we add a statement that traffic analysis can violate user 
privacy. IANASE, but there doesn't seem to be a better way of hiding IP 
addresses over a wireless link than link encryption. So, while link 
encryption is not a complete solution to traffic analysis it does yield 
some capabilities that IP encryption cannot. However, we also need to do 
what we can to avoid the impression that link encryption can protect user 
data -- it only offers protection of IP addresses. IP or higher layer 
security mechanisms should be used to protect user data.

I think we should discuss this further at the SAAG meeting (Thurs, 3:30) to 
get more Security Area input.

--aaron

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 08 Aug 2001 10:20:43 +0100

At 12:51 PM 8/7/2001 -0400, Aaron Falk wrote:

>site a user is accessing, e.g., the sex.com example. So, perhaps we can 
>get consensus if we add a statement that traffic analysis can violate user 

I have been looking at this vis-a-vis 802.11i.  ESP is very usable as a 
link layer protection mechanism.  It just needs an applicable KME for 
sub-IP (layer 2.5 if you will).

This of course is a 'different' ESP than 2406.  The nature of the SA is 
different, no IP address for the tuple, at least.  But the format and much 
of the code would be the same.

ESP overhead can be 'managed' by selection of the transform.  ESP 
contributes 10 bytes (14 if we increase the size of the 
Seq#).  3DES-HMAC-SHA1-96 contributes 20 bytes with an average 2 bytes 
padding.  But a dual-mode AES transform could be much less overhead 
(conversations with Phil Rogaway seems to indicate that AES128-OCB64 would 
be 8 bytes plus padding).

An effort in the security area to define a common security mechinism for 
link layers would be a benifit to the community.  When I attended the 
802.11i meeting in Portland, it was mentioned that it WOULD be nice if IETF 
did this generically, but since they don't WEP2 needs to come out of the 
11i group.

Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 08 Aug 2001 06:38:25 -0400

We want to be very very careful about what we say about traffic analysis.

My sense is that it's harder to defeat traffic analysis than to
engineer systems to be robust in the face of denial-of-service
attacks.

Adversaries can choose to attack things other than just the abstract
bitstream at the link layer -- there are no doubt many opportunities
to distinguish between transmitters using physical layer techniques
like radio direction finding, waveform shapes, etc., etc.,

An adversary with taps on both sides of a router who can see frame
boundaries can likely correlate traffic going in and coming out.

Merely using something like ESP at the link layer isn't going to help
much against traffic analysis since you'll still be able to do TA
using the ESP SPI's.

Modern bridges and routers often run very complex software systems and
likely have some of the same vulnerability-to-remote-compromise issues
as host software.  Code Red's buffer-overrun attack reportedly also
crashed certain routers... what's the chance that the crash involved
an exploitable buffer overrun?

Security is hard.

					- Bill

---

From: Phil Karn <[email-masked]>
Date: Wed, 8 Aug 2001 16:44:35 +0100

>We want to be very very careful about what we say about traffic analysis.

I agree fully, and I will word the text I am writing very carefully.

Phil

---

From: Stephen Kent <[email-masked]>
Date: Fri, 17 Aug 2001 16:18:26 -0400

At 10:20 AM +0100 8/8/01, Robert Moskowitz wrote:
>
>I have been looking at this vis-a-vis 802.11i.  ESP is very usable 
>as a link layer protection mechanism.  It just needs an applicable 
>KME for sub-IP (layer 2.5 if you will).

What's a KME?

>This of course is a 'different' ESP than 2406.  The nature of the SA 
>is different, no IP address for the tuple, at least.  But the format 
>and much of the code would be the same.

Remember, Bob, a protocol is not just syntax, it's the processing 
part too. What you suggest is definitely not ESP anymore.

>contributes 10 bytes (14 if we increase the size of the Seq#). 
>3DES-HMAC-SHA1-96 contributes 20 bytes with an average 2 bytes 
>(conversations with Phil Rogaway seems to indicate that AES128-OCB64 
>would be 8 bytes plus padding).

I saw Phil's message, and it talked about covering static data, but 
the sequence number, unlike the SPI, is not static, so there might be 
additional overhead.

>
>An effort in the security area to define a common security mechinism 
>for link layers would be a benifit to the community.  When I 
>attended the 802.11i meeting in Portland, it was mentioned that it 
>WOULD be nice if IETF did this generically, but since they don't 
>WEP2 needs to come out of the 11i group.

IEEE has a layer 2 security protocol (802.10-SDE) that 802.11 seems 
to be ignoring. I wonder why? That protocol already has a format 
appropriate to the MAC layer.

Steve

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 17 Aug 2001 19:53:40 -0400

At 16:18 17/08/01, Stephen Kent wrote:
>IEEE has a layer 2 security protocol (802.10-SDE) that 802.11 seems to be ignoring. I wonder why? That protocol already has a format appropriate to the MAC layer.

        I've been wondering this myself.  It would seem that the
obvious approach for 802.11 is to use the existing 802.10 work,
yet they ignored it earlier and seem to be ignoring it now.

Ran
[email-masked]

---

From: Derek Atkins <[email-masked]>
Date: 19 Aug 2001 10:16:30 -0400

Do we know anyone on the IEEE WEP-2 committee?

-derek

RJ Atkinson <[email-masked]> writes:

> _______________________________________________
> saag mailing list
> [email-masked]
> http://jis.mit.edu/mailman/listinfo/saag

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Randy Bush <[email-masked]>
Date: Sun, 19 Aug 2001 09:11:19 -0700

> Do we know anyone on the IEEE WEP-2 committee?

i forwarded the hint.

randy

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 20 Aug 2001 00:09:47 -0400

>Do we know anyone on the IEEE WEP-2 committee?

Jesse Walker of INTEL (use to by Shiva, I think in IPsec) is co-chair.

Glenn Zorn and Bernard Aboba are there.

I recently joined.

Robert Moskowitz
ICSA

---

From: Joe Touch <[email-masked]>
Date: Mon, 20 Aug 2001 07:26:33 -0700

> security mechanisms should be used to protect user data.

Hi, Aaron et al..

Regarding the above, how does link encryption protect anything, per se?
Users who want their IP addresses private want global privacy (nobody 
can know); keeping this information private over a single hop is of
dubious utility - the ends of the link, under no control of the user,
are exposed. 

Further, link security isn't the only way to provide this privacy.
IP addresses on a single hop or even multiple hops can be hidden
using tunnels (IPsec tunnel mode or, IMO preferably, IPIP encapsulation on
an IPsec transport mode association).

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 20 Aug 2001 16:12:44 +0100 (BST)

On Mon, 20 Aug 2001, Joe Touch wrote:

> > privacy. 

Yes.

> > IANASE, but there doesn't seem to be a better way of hiding IP
> can know);

global privacy is a strawman.

As a user, I want administratively separate pools of privacy
containing partial knowledge about me, where no-one can easily come to
know everything about me by connecting the pools of partial knowledge
together.

link encryption can help maintain that separation, protecting against
attackers with partial knowledge. It's therefore a benefit to me.

> keeping this information private over a single hop is of

local traffic analysis is still possible. It's not what you sent
across the link, it's the fact that you sent across the link then.

The IPSec mantra is all very well - I heard it smugly repeated enough
times in enough WG meets at IETF 51 - but it has precious little to do
with the reality of service deployment for the average user.

[My European take on this is that many Americans have absolutely no
 idea what privacy means. It's all one extreme - IPSec and paranoia -
 or the other, where they put their social security number on
 everything and broadcast their home addresses and phone numbers to
 the world. Middle ground? ha.]

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Joe Touch <[email-masked]>
Date: Mon, 20 Aug 2001 08:22:10 -0700

> attackers with partial knowledge. It's therefore a benefit to me.

I'm not advocating against link encryption. I was only advocating
that it does not provide unique assurances of hiding IP addresses.

> across the link, it's the fact that you sent across the link then.

Same is true for link encryption, in that case. What we need
then is traffic hiding, which can be implemented, as with IP
address hiding, at either the link or IPIP tunnel layer.

> with the reality of service deployment for the average user.

Perhaps. However, I've also heard the WEP mantra, which was OK until
it was cracked. Now we have tons of deployed hardware that assumed
that link encryption was sufficient. I can change software, e.g.,
at the IP layer more easily than I can change the link.

Again, I'm not advocating IPsec vs. link encryption, but that
link encryption doesn't _uniquely_ provide protection, esp. that
tunneling wouldn't as easily provide. And I do use tunnels all 
the time, universally, over different link technologies (some of which
would need to be redesigned to provide link encryption).

Joe

---

From: Dan Grossman <[email-masked]>
Date: Mon, 20 Aug 2001 11:51:05 -0400

> > security mechanisms should be used to protect user data.
Disagree strongly.

It gets back to the first steps of a security analysis: threats, assets and 
vulnerabilities.  No question that link encryption, in itself, is insufficient 
to protect high valued assets like business secrets or credit card numbers 
against attackers seeking to profit by stealing them.  However, wireless and 
other shared media environments are extremely vulnerable, even to accidental 
attacks.  Lower valued assets, like the fact that somebody happens to be 
surfing sex.com are probably not worth the effort of most attackers to exploit 
more difficult vulnerabilities.  However, if they're easy pickings, they will 
be widely exploited. 
> dubious utility - the ends of the link, under no control of the user,
See above.  Close off the most gaping vulnerabilities, and you close off all 
but the most skilled and determined attackers.

> an IPsec transport mode association).
Sure, and how many commercial web sites use IPsec tunnel mode or IPIP 
encapsulation on IPsec transport mode?  

This discussion seems to be going further and further down a "fundamentalist" 
path.  It's like the Family Research Council claiming that condoms should be 
banned because they occasionally fail and permit transmission of HIV.   We 
need to reconnect with the real world, even though it's not exactly the world 
we want. 

We can and should and have warned about reliance solely on link mechanisms to 
maintain confidentiality.  But we have to deal with two incontrovertible 
facts:  1) regardless of what we preach, commercial web sites and other 
applications will not bother with end-to-end security for relatively low 
valued assets and 2) no link designer is going to not put in encryption 
because we said not to:  it would be market suicide.  

So what's at stake here is the credibility of the Links draft.  If we say that 
link encryption is absolutely useless, then we lose the opportunity to urge 
good design and our audience will simply ignore that recommendation anyway 
(and possibly be more sceptical of the remaining recommendations).  If we say 
that link encryption in itself is insufficient to protect high valued assets, 
and outline steps for good security design, we will have provided a useful 
service to the link design community.
> Joe
Dan

---

From: Dan Grossman <[email-masked]>
Date: Mon, 20 Aug 2001 12:20:31 -0400

> at the IP layer more easily than I can change the link.
The problem with WEP is not that it's a link layer mechanism, but rather that 
802.11 made some design mistakes which should have gotten caught in review.  I 
was a bit surprised, since (at least at the time) 802.10 had an oversight role 
and some good people with crypto backgrounds who were supposed to be advising. 
 Don't know whether advice was proffered and ignored, or whether the problems 
just slipped through.  I was working on 802.14 security in about the same 
timeframe, and recall some valuable suggestions from the 802.10 chair and 
vice-chair.  

On the other hand, anybody who has a DOCSIS or Euro-DOCSIS cable modem is 
depending on BPI+ for web surfing privacy.  To my knowledge, nobody has found 
a practical exploit (brute force attacks on DES don't count) on BPI+.  
Speaking for myself, were I to trade my home DSL for cable modem, I would see 
no reason to modify my online behavior.

Incidentally, there's nothing that stops people from using IPSec (or TLS or 
SSL or whatever over 802.11). It doesn't happen to be burned into the hardware 
(and for that matter, it's not cooked into the dominant operating system), but 
people do run IPsec-based VPNs over it all the time.

---

From: Joe Touch <[email-masked]>
Date: Mon, 20 Aug 2001 09:32:48 -0700

Dan Grossman wrote:
> Joe Touch wrote:

Presumably you're hinting that they _do_ use SSL?

Whether a commercial website uses link encryption or IPsec tunnels
is a link (or, in the case of tunnels, pseudo-link) issue, and cannot
be determined E2E. Some use such encryption to get to a trusted core 
provider using a series of insecure intermediate 1st and 2nd tier ISPs,
where, for whatever reason, they don't want their traffic analyze by the
intermediate ISPs (snoop for advertisements, etc.)

This is useful even where (or especially where) the website doesn't
want or need SSL to the end user, but still wants to keep its content
and statistics private from snooping ISPs on its end.

> service to the link design community.

Link encryption provides no NEW capability, e.g., compared with tunnel
encryption. That is NOT to say that either is useless, just that neither
is unique.

I was going for clarification of the bathwater, not tossing it out.

Joe