Subject: RE: Reminder: automated key management is often required for new protocols

From: "David B. Nelson" <[email-masked]>
Date: Tue, 13 Nov 2007 16:21:58 -0500

Hi Sam,

The RADIUS Extensions (RADEXT) WG chairs forwarded the attached message
(from you) to the RADEXT WG list back in August, requesting that the WG
members review RFC 4107 as it may apply to the RADIUS Crypto-Agility work
item.  RADEXT is considering a few proposals to introduce crypto-agility,
i.e. the ability to incorporate new cipher suites and cryptographic methods
into the legacy RADIUS protocol.  We are doing this based on the general
request from the Security Area Directorate for all WGs to undertake an
analysis of the crypto-agility properties of existing IETF protocols, and
recommended enhancements where feasible.   As it currently exists, RADIUS
relies on message digests and stream ciphers based on MD5.

The scope of the RADEXT Crypto-Agility work item is summarized here:

http://ops.ietf.org/lists/radiusext/2007/msg00185.html

The WG has not been able to determine if your guidance on the applicability
of requirements for automated key management in new protocols would extend
to crypto-agility "retro-fit" efforts such as this.  We seek further
clarification on this issue, so that we can make some progress in
determining which (if any) of the current proposals for RADIUS
Crypto-Agility will be acceptable.  Not all of them embrace automated key
management.

Regards,

Dave Nelson
Co-Chair RADEXT WG

> >From: Sam Hartman <[email-masked]>
> >To: [email-masked]
> >Subject: Reminder: automated key management is often required for
> >new protocols
> >Date: Tue, 21 Aug 2007 12:38:10 -0400 (EDT)
> >
> >I wanted to send out a brief reminder to working group chairs about
> >RFC 4107.  This BCP, published in June of 2005, gives guidance on when
> >our protocols need to have an automated key management mechanism.
> >
> >By this point, you should expect to need to follow RFC 4107 for any
> >new protocols and should not be surprised when you are required to
> >update protocols to comply with RFC 4107 in order to significantly
> >increase their applicability.
> >
> >In many cases, this means you will need to have an automated mechanism
> >for doing key management for security mechanisms your protocol.  This
> >does not mean you need to support PKIs or even public-key operations.
> >
> >If you have not already taken a look at RFC 4107 in the context of
> >your working group, please do so.  If you have any questions Tim and I
> >would be happy to answer them.
> >
> >I'm writing because it looks like I will file a number of discuss
> >positions this week asking for significant additional security work to
> >be done on protocols before they can be published.  I'd like to avoid
> >such late surprises for future work.
> >
> >
> >Sam Hartman
> >Security Area Director

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 14 Nov 2007 11:33:54 -0500

Sam,

> So, my question to you is what is driving this work besides a desire
> to be good security citizens?

Well, besides that, some folks at Cisco expressed a desire to replace 
the crypto elements of RADIUS (e.g. key wrap, MAC, etc.) with algorithms 
and modes that would allow systems including RADIUS to receive FIPS 
certification, for solutions in government and financial services markets.

Additionally, the folks behind the EduRoam consortium in Europe have 
deployed RADIUS over TLS for inter-university roaming authentication.

There may be other use cases.  I encourage anyone on the RADEXT list to 
add their perspective.