[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: l2tp as ipsra solution

Sara Bitan wrote:
> We should let the remote access guys do what they do best, while this WG will
> provide them with what we know to do best - namely security.
> But not security married to a particular RA protocol but rather security
> for *any* RA protocol. That is, you guys choose your favorite RA protocol
> (which is what you know to do best), get an IP address, bootstrap a secure ipsec
> SA using the
> remote authentication mechanism that ipsra provides, then run ipsec, and
> finally run RA on top of it. Simple, hierarchical, transparent, and even
> secure...

	Look at this from a key management perspective. The 'use ipsec to
secure l2tp' approach would authenticate end users but would only
provide privacy service keying material based on machine level
authentication within IKE. This disassociation of authentication and key
management seems troublesome to me even if you do in fact trust your
vendors implementation to bind PPP access filters with IPsec privacy
services. People who are more expert than me are on record saying that
if you trust this binding, then you have an acceptably secure solution.
But in my in-expert opinion (insert standard "not a cryptographer"
equivocation here), I still can't shake the "it just bugs me" feeling.
Associating a key with a proxy for your endpoint when you could have
associated the key with the endpoint itself just seems weaker. It's like
the longer the list of trust requirements I have for a system, the less
I trust the overall result eventhough I may trust in each individual

	Using ipsec to secure l2tp may be sufficient to combat certain threat
models. Maybe even popular ones. But I do not think that the ipsra group
should choose to be limited to key management at a machine level. Even
if ipsra chooses to endorse the 'ipsec secures l2tp' approach as valid
for some scenarios, I still think that we should go on to provide a
mechanism for true key material association with end users.

	From what I've learned of history by reading this (and related)
thread(s), it seems that the l2tpnext and pppnext WGs have been directed
by their ADs to not attempt to re-invent key management and privacy
services but instead leverage ipsec. I guess this was motivated by the
'don't reinvent when you can reuse' philosophy. But this has the
unfourtunate consequence of breaking the association of authenticating
parties and managing key material for parties because those roles just
got divided between EAP and IKE. Now EAP will authenticate users, but
IKE will authenticate machines. And this enforced division between user
level authentication and machine level key managment seems like a bad
thing to me. I personally feel there is sufficient motivation to
re-invent here, rather than just re-use.

	Therefore, I think it unwise for ipsra to shun the task of bringing
true key material management based on end user authentication to remote
access. I do not think that our group should say "yeah, PPP based users
filters and machine level IKE to build IPsec privacy SAs are good enough
for every body" and stop there. 

	I think that some group in IETF will have to take on the task of
associating end users with new key material to feed privacy services. I
would like that group to be ipsra. And I hope that our group will at
least remain open to discussing it.

  Ricky Charlet   : Redcreek Communications   : usa (510) 795-6903