RE: RADIUS keywrap attributes

["Nancy Winget \(ncamwing\)" <ncamwing@cisco.com>]

The proposed draft-zorn-radius-keywrap-08.txt focuses mainly on the
keying attributes which we believe need to be protected and has been a
requirement for quite some time now.  Draft-zorn-radius-keywrap-08.txt
does not attempt to introduce a full new security mechanism to RADIUS as
is suggested by draft-aboba-radext-wlan-00.txt but merely addresses how
the keying material should be protected.

If we can agree that this is a work item for this group, then we can
discuss the merits of the different proposed approaches by either
draft-zorn-radius-keywrap-08.txt or your newly proposed
draft-aboba-radext-wlan-00.txt and make progress on this particular
requirement.

We can always determine the criteria for IESG approval as well but that
should not stall our progress in addressing this requirement.

	Nancy.

-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
On Behalf Of Bernard Aboba
Sent: Sunday, August 21, 2005 12:29 AM
To: radiusext@ops.ietf.org
Cc: Zhang, Tiebing; Russ Housley
Subject: RE: RADIUS keywrap attributes

> > I was under the impression that this was outside the scope of the WG

> > charter.  Has this changed recently?

The RADEXT WG charter was written based on liaison requests from SDOs
including IEEE 802.11.  The IEEE 802 attribute draft, developed to
respond to those requests, included keying attributes from the
beginning.  
So yes, keying attributes are within the RADEXT WG charter.

While keying attributes are within the scope of the RADEXT WG charter, I
am not clear what the criteria are for IESG approval. Satisfying the
requirements in "AAA Key Management" (draft-housley) could prove quite
difficult.  One of the requirements of draft-housley is to avoid
disclosure of keying material to unauthorized parties.  This hurdle was
overcome in RFC 4072 using Diameter redirect.

However, it is not clear to me that it would be possible to retrofit a
redirect mechanism within RADIUS.  Since CMS failed to gain traction
within Diameter, I see no reason why that would be viable for RADIUS,
either.  The presentation at IETF 63 discussed a number of other
alternatives, some of which are subjects of current research (the DNSSEC
approach under development within Terena).  


--
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/>

--
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/>