Subject: RE: [Isms] RE: TLA

From: "Khanh Nguyen \(khanhvn\)" <[email-masked]>
Date: Mon, 2 May 2005 16:05:54 -0700

> From: Randy Presuhn
>
> Hi -
> 
> > From: "Khanh Nguyen (khanhvn)" <[email-masked]>
> ...
> > USM breaks PFS by using the same privKey for all SNMP messages.
> ...
> 
> No, the issue is how key changes work.
> 
> With USM, cracking a key (by whatever means) allows 
> decryption of all messages encrypted with that key.  This is 
> true of *any* system.

Of course.  But the difference is USM keys are re-used repeatedly 
for encryption, while in TLS, for example, the master keys are 
generated dynamically using Diffie-Hellman or RSA key exchange.
One the session is over, TLS master keys are destroyed - no 
trace left.  But in USM, the keys stay in the device 
indefinitely (until someone changes them manually).  That's
why attackers can look back to decrypt past communications.

Again, as I said, this is not USM fault, but a common problem
for all sessionless methods.

> 
> Due to the way USM key updates work, cracking a USM key does 
> not help the attacker figure out what key was used prior to 
> the cracked key, unless the key update was done in the clear. 

No argument about this.  My point is that USM keys are very 
static.  They can be changed manually once in a while, but are
not dynamically generated as in other session-based methods.  
USM auth/privKeys are generated from the user passwords, and 
people don't change their passwords every hour.

BTW, USM lack of PFS is not something new.  It has been mentioned
earlier elsewhere (e.g. draft-ietf-isms-proposal-comparison-00)

Khanh

>  What some folks would like, and what USM does *not* provide 
> (unless one uses RFC 2786) is the ability to prevent cracking 
> a key from helping an attacker figure out a key used *after* 
> the cracked one.
> 
> Randy
> 
> 
> 
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/isms
> 

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 2 May 2005 16:43:41 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Monday, May 02, 2005 4:05 PM
> Subject: RE: [Isms] RE: TLA
...
> for all sessionless methods.

Let's not confuse PFS with the desire to limit key lifetimes.
One can limit key lifetimes without providing PFS, and one
can have PFS without limiting key lifetimes.
Both are valuable, but they're not the same thing.

...
> My point is that USM keys are very

USM does not limit the frequency of key updates.  That's up to the
user/SA.  The remaining question is that of limiting key lifetime,
which can be accomplished by far less drastic means than these.

For example, an automated security administrator could delete
"old" usm user entries.  When a user app needed to interact with a
managed system, it could ask the security administrator application
to (re-)create its entry, possibly using 2786 to establish the key(s),
and possibly consulting with some AAA infrastructure.
What would require some thought/discussion is the question of
how the end of a session is detected.  For example, users could
be permitted to delete their own usm user entries, or the security
administrator application could do it on their behalf.

...

Passphrases, but I agree with this point inasmuch as it applies to
authentication keys.  Encryption keys are a different matter, particularly
in light of how one might use RFC 2786.

Randy

---

From: "Tom Petch" <[email-masked]>
Date: Wed, 4 May 2005 14:00:09 +0200

Thanks for all the information on PFS; I wish I had asked when it first
arose:-(  I have had in mind the RFC2828 definition which includes

'(C) Some existing RFCs use the term "perfect forward secrecy" but
      either do not define it or do not define it precisely. While
      preparing this Glossary, we tried to find a good definition for
      that term, but found this to be a muddled area. Experts did not
      agree. For all practical purposes, the literature defines "perfect
      forward secrecy" by stating the Diffie-Hellman algorithm.'

which I think covers the bases:-)

Tom Petch