[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Security considerations for L2TP (one last try)!
MIC is a solution that Pat and I had talked about long
time back. Also, I had summarized in an earlier
mail.
I am not against it. However, I do believe
that it is a limited solution (e.g., what happens if
someone proves MD5 is broken?).
Organizations have security policies and security
solutions must be flexible so that these policies
(and objectives there of) are realizable.
IPSEC is a framework under which you can have
flexible security solutions that can meet different
security requirements. Thus, it allows you to provide
value add and a product differentiate. Therefore, it
is a desired security protocol (both from business
and technical point of view). Therefore, we are
recommending IPSEC as the means of meeting
L2TP's security requirements when used over
IP. I am not against implementing other mechanisms
for L2TP over non-IP protocols (so, now there are
two!).
Baiju
Baiju
-----Original Message-----
From: Chris Boscolo [SMTP:chris.boscolo@sealabs.com]
Sent: Tuesday, June 10, 1997 2:03 PM
To: l2tp@zendo.com
Subject: Security considerations for L2TP (one last try)!
Baiju, and PatC,
I almost agreed with you until I had a night to think about it.
(This feels like a steep uphill battle but I will persist one last time
none the less.)
[Baiju Patel wrote]
> Chris, let me try to explain why IPSEC may not be as bad an
> idea. ...
First, don't get me wrong, it is not that I don't like IPSEC, it's that
I beleive there should be L2TP (with reasonable security) without
requiring anything else. (In this case IPSEC) I will pull another
"assumtion" I found in an ealier L2TP draft:
"End System transparency: Neither the remote end system nor his
home site hosts should require any special software to use this
service in a secure manner."
Image an ISP (in LAC mode) providing L2TP services that doesn't use
IPSEC. I am a PPP client connect to the ISP. Also, I am using an older
version of PPP which does not support any CCP encryption. Wouldn't this
mean that my tunnel is unenecrypted?
Lets take this a step further. Lets say thet I try to find L2TP client
software, (since I don't trust my ISP to do the encryption for me)
Then, in order to have a secure tunnel my client will also have to use
IPSEC.
I do agree with your previous point about a security soluttion looking
like IPSEC, but I bring the point up again, l2TP does not require IP.
If we keep making assumtions that it is based on IP we may as well stick
with PPTP since it is an IP only solution.
What would be nice is if L2TP offerd used an optioanl MIC for control
messages, and an optional MIC and ecryption for data. It seems like the
extra (128) bytes per control message would not be a huge price to pay
for. Since it is optional, if you were using IPSEC then you could elect
not to use the built into L2TP.
Here is how it could be added?
The option could be (in/ex)cluded vi the K bit, since the Key is being
removed. Also, the key field could be replaced by MIC len (2bytes) & 2
bytes PAD for the control messages. And by a MIC len 2 Bytes,
encryption data len (2bytes) for data packets. The actual data would
follow the MIC, and auth stuff. The MIC, and encryption used could be
negotiated. The actual size
of the use of the space for the MIC, and encryption data would depend on
the type negotiated.
The encryption data could be things like an IV.
(PatC, I wasn't sure how your MIC work fit in?)
So, I have said my piece. If I am the only one that feels this way, I
will say no more about it...
Thanks,
Chrisb
--
Chris Boscolo chris.boscolo@WatchGuard.com
Seattle Software Labs (206) 521-8348