RE: Thoughts on Requirements for RADIUS crypto-agility

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Alan DeKok <> allegedly scribbled on Friday, February 23, 2007 2:39 AM:

...

> 
>   A NIT (or question):
> 
> ...
>> 3. Proposals MUST support replay protection. ...
>> 11. Crypto-agility solutions should not require fundamental changes
>> to 
>> the RADIUS operational model, such as the introduction of new
>> commands 
>> or maintenance of state on the RADIUS server.
> 
>   Most methods to obtain replay protection involve maintenance of
> some kind of state on the RADIUS server.  Maybe global server state,
> or per-client state.  

Either that or globally synchronized clocks; do we really want to go
there?

> 
>   I also see reply protection as being potentially independent of
> crypto work. 

Initially, I agreed with you on this, bur re-reading David's message I
wonder if the replay protection stuff just applies to the crypto
algorithm negotiation mechanism?  If not, the straw-man requirements
would appear to be self-contradictory since requirement 11 states
"Similarly, the addition of new capabilities to the RADIUS protocol is
out of scope; a proposal should focus on the crypto-agility problem and
nothing else." yet (IMHO) strong replay protection is certainly a new
capability for RADIUS & it is a crypto application, rather than an
agility thing.

...

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>