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

RE: Crypto-agility requirements: Operational Model (from Issue 303)

One approach to addressing this issue would be to refer to the Design Guidelines document (which also touches on discussion of changes to the Operational Model).




From: bernard_aboba@hotmail.com
To: radiusext@ops.ietf.org
Subject: Crypto-agility requirements: Operational Model (from Issue 303)
Date: Sun, 28 Jun 2009 14:05:54 -0700


In Issue 303, Pasi Eronen said:

"
"Operational model"?

Section 4.3 says "Crypto-agility solutions SHOULD NOT require changes
to the RADIUS operational model, such as the introduction of new
commands or maintenance of [additional] state on the RADIUS server."

I'm not sure what "operational" means here -- at first I thought it
might mean "operations and management" (so the requirement would be
basically "SHOULD not complicate life for administrators"), but the
two examples given don't seem to fit that very well. And it seems any
solution that e.g. derives fresh session keys will involve some small
(but greater than zero) amount of additional state on clients and
servers.

If the intent was really operations and management, perhaps the should
be rephased something like "When using long-term shared secrets for
authentication, crypto-agility solutions SHOULD NOT require more
operations and management work than the current solutions."
"




i'm EMAILING FOR THE GREATER GOOD
Join me