Subject: RE: [RPSEC] Re: no TCP-MD5 replacement please

From: "Bora Akyol" <[email-masked]>
Date: Fri, 27 Jan 2006 12:39:08 -0800

> Wrt the operational needs of IPsec and key mgmt ... it 
> already is specified and there is wide implementation of sync 
> rollover, management, distribution, etc. 
> 
> 0.02$
> 
> -DWard
> 

Thank you,

I am more familiar with the IPSEC case then the TCP-MD5 case,
can you please define "wide"?

For VPN access using one time passwords or certs, yes, there are
many tools. However, for connectivity between two hosts that
are not under the same administrative domain, other than using
certificates issued by a mutually trusted root, what other mechanisms do
we
have to synhcronize rollover of pre-shared keys and manage this on 
a lot of routers?

If you have any pointers to published work, I would appreciate it.
I am hoping that such work exists after the blind TCP reset issue that
appeared a couple years ago.

Thanks

Bora

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Merike Kaeo <[email-masked]>
Date: Fri, 27 Jan 2006 13:48:25 -0800

While it is true that pre-shared key roll-over is the same problem as 
changing the MD-5 keys used in today's non-IPsec authentication 
implementations,  IPsec works a bit differently.  The pre-shared key is 
used to originally authenticate the communicating peers (i.e. the 
Diffie-Hellman exchange) which then results in a shared secret.  This 
shared secret is then used to derive the actual key used for the MD-5 
or SHA-1 authentication used in IPsec.  These authentication keys are 
refreshed based on a defined lifetime, which is the so-called 
'automated' key rollover.

So, at least you change the keys used to perform the actual 
authentication........and you also keep your options open for a PKI 
infrastructure solution which provides 'better' dynamic authentication 
for the communicating peers (which I still have an optimistic view of 
happening in my lifetime)

- merike

---

From: Brian Weis <[email-masked]>
Date: Mon, 30 Jan 2006 10:39:04 -0800

Merike Kaeo wrote:
> shared secret is then used to derive the actual key used for the MD-5 or 
> SHA-1 authentication used in IPsec.  These authentication keys are 

The real roll-over problem is that an IPsec system can have only one 
valid IPsec pre-shared key for each peer, and if the two peers disagree 
on the value of the current key at any point in time the connection will 
fail.

What Merike describes above shows that that once authentication 
completes, there is usually a few hours before it gets used again. Under 
ordinary circumstances, this gives the operations staffs of the two 
peers a period of a few hours to synchronize changing the key. But if 
one peer unexpectedly has a need to re-authenticate when only one side 
has installed the new key, they won't be able to bring up the BGP 
session just as in the case when keyed-MD5 authentication keys are 
different.

Whether or not this level of risk is acceptable to operators is unknown 
to me, but in any case it has to be considered.

Brian

-- 
Brian Weis
Advanced Security Development, Security Technology Group, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: Shane Amante <[email-masked]>
Date: Mon, 30 Jan 2006 21:36:41 -0700

Brian,

On Jan 30, 2006, at 11:39 AM, Brian Weis wrote:
> Merike Kaeo wrote:
>> While it is true that pre-shared key roll-over is the same problem  
>> as changing the MD-5 keys used in today's non-IPsec authentication  
>> implementations,  IPsec works a bit differently.  The pre-shared  
>> key is used to originally authenticate the communicating peers  
>> (i.e. the Diffie-Hellman exchange) which then results in a shared  
>> secret.  This shared secret is then used to derive the actual key  
>> used for the MD-5 or SHA-1 authentication used in IPsec.  These  
>> authentication keys are refreshed based on a defined lifetime,  
>> which is the so-called 'automated' key rollover.
>
> The real roll-over problem is that an IPsec system can have only  
> one valid IPsec pre-shared key for each peer, and if the two peers  
> disagree on the value of the current key at any point in time the  
> connection will fail.
>
> completes, there is usually a few hours before it gets used again.  
> Under ordinary circumstances, this gives the operations staffs of  
> the two peers a period of a few hours to synchronize changing the  
> key. But if one peer unexpectedly has a need to re-authenticate  
> when only one side has installed the new key, they won't be able to  
> bring up the BGP session just as in the case when keyed-MD5  
> authentication keys are different.
>
> Whether or not this level of risk is acceptable to operators is  
> unknown to me, but in any case it has to be considered.

Speaking as an operator, this is an acceptable risk, which (as you  
already said) I have to deal with anyway today for keyed MD5.

Here's some additional points, (probably re-stating some of what's  
already been said):
1)  Re-using a _standard_ authentication protocol, such as IKE+IPsec,  
is advantageous in that crypto/security experts, plus developers!,  
have worked on the protocol for quite a while and understand its  
inherent strengths and weaknesses. Furthermore, IKE+IPsec attracts  
(and, presumably, will continue to attract) a good deal of peer  
review in the crypto/security community, which gives me a good deal  
of confidence that if weaknesses are exposed in IKE+IPsec, it's bound  
to be noticed and fixed in relatively short order.
2)  That said, we need to ensure the proper balance between throwing  
too much functionality (a.k.a.: knobs) into IKE+IPsec making it  
difficult, bordering on impossible, to deploy.  I'd advocate choosing  
a very, very small set of pre-defined 'crypto suites' analogous to  
what the IPsec WG almost adopted during the re-spin of IKEv1 into  
IKEv2.  This ensures you don't have two operators (in two different  
organizations) arguing whether or not they want 3DES, SHA-1 or AES  
for IKE Phase 1, PFS on/off, Phase 1 & Phase 2 key lifetimes, etc.,  
etc., etc.  Just define 3 crypto-suites (High, Medium, Low?), bake  
'em in and then Ops can tell each other: "Just use Crypto Suite 1",  
throw in a pre-shared (secret) key and they're off.  I'm sure there  
will be much gnashing of teeth on the appropriate list over exactly  
what options get defined in those suites, but that's a good thing: 1)  
That means a lot of people have looked at it and came to rough  
consensus on the "best" (or "least evil", depending on your  
viewpoint) set of choices for a pre-defined suite; 2) vendors only  
need to code & test against a narrow set of standard options; 3) it  
will save Ops tons of time and hair-pulling down the road; and, 4) it  
will ensure more widespread deployment because "it's super-easy to  
enable".
3)  It's not clear to me why we'd want to include IS-IS as "in scope"  
for this effort, since: a) it's an IGP; and, b) because it's an IGP,  
it should only be run across "trusted" links, anyway, otherwise  
caveat emptor.  If people really want to secure it with IPsec, let  
them go to IS-IS WG, first, and try to rescuitate the IS-IS/IPv4  
work ... good luck with that, BTW ;-).  (Alternatively, convert your  
IGP to OSPF, which could use IPsec, or use one of the proprietary,  
but interoperable, mechanisms already supported by numerous vendors  
for securing IS-IS domains :-).

>> authentication........and you also keep your options open for a  
>> PKI infrastructure solution which provides 'better' dynamic  
>> authentication for the communicating peers (which I still have an  
>> optimistic view of happening in my lifetime)

Although somewhat contradictory to what I said in #2, but along the  
lines of what Merike just said, I would favor an approach where we  
first defined IKE+IPsec using pre-shared (secret) keys and then look  
at enabling a more dynamic mechanism to exchange keying material  
along the lines of what is (or could be) done in "Opportunistic  
Encryption":
http://www.ietf.org/rfc/rfc4322.txt

... but modified to be for authentication, not [just] encryption, if  
I understand it correctly.  In this case, DNS+DNSSEC is used to  
publish, fetch + authenticate public keys to bootstrap IKE  
endpoints.  In this way, Ops can publish DNS RR's for their public  
keys, which allows an iBGP mesh to change over relatively easily or,  
alternatively, an external peer (or, perhaps, set of peers) to change  
over easily w/out coordination as in the case of pre-shared keys.   
One huge obstacle of this approach would be deployment of DNSSEC (if  
you wanted to do it right), which may or may not happen within our  
lifetime, but who said this would be easy?  ;-)

-shane