Subject: RADEXT WG re-charter

From: Bernard Aboba <[email-masked]>
Date: Tue, 1 Apr 2008 12:40:58 -0700

As we discussed at IETF 71, the RADEXT WG is looking at a re-charter.  A strawman re-charter proposal is enclosed below.  
Once comments from WG participants have been incorporated, we will begin a formal WG consensus call on the proposed
re-charter by the end of the month. 
 
==================================
 
Description of Working Group:
The RADIUS Extensions Working Group will focus on extensions to the
RADIUS protocol required to define extensions to the standard
attribute space as well as to address cryptographic algorithm
agility and use over new secure transports. In addition, RADEXT will
work on RADIUS Design Guidelines and define new attributes for 
particular applications of authentication, authorization and 
accounting such as NAS management and local area network (LAN) usage. 

In order to enable interoperation of heterogeneous RADIUS/Diameter
deployments, all RADEXT WG work items MUST contain a Diameter
compatibility section, outlining how interoperability with
Diameter will be maintained.

Furthermore, to ensure backward compatibility with existing RADIUS
implementations, as well as compatibility between RADIUS and Diameter,
the following restrictions are imposed on extensions considered by the
RADEXT WG:

- All RADIUS work MUST be backward compatible with existing RADIUS
RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,
4675, 5080, 5090 and 5176.

- All RADIUS work MUST be compatible with equivalent facilities in
Diameter. Where possible, new attributes should be defined so that
the same attribute can be used in both RADIUS and Diameter without
translation. In other cases a translation considerations
section should be included in the specification.

Work Items

The immediate goals of the RADEXT working group are to address the
following issues:

- RADIUS design guidelines. This document will provide guidelines for
design of RADIUS attributes. It will specifically consider how
complex data types may be introduced in a robust manner, maintaining
backwards compatibility with existing RADIUS RFCs, across all the
classes of attributes: Standard, Vendor-Specific and SDO-Specific.
In addition, it will review RADIUS data types and associated
backwards compatibility issues.
 
- RADIUS Management authorization. This document will define the
use of RADIUS for NAS management over IP. 

-RADIUS attribute space extension. The standard RADIUS attribute
space is currently being depleted. This document will provide
additional standard attribute space, while maintaining backward
compatibility with existing attributes.

-RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally 
relied on MD5 for both per-packet integrity and authentication as well
as attribute confidentiality. Given the increasingly successful
attacks being mounted against MD5, the ability to support
alternative algorithms is required. This work item will
include documentation of RADIUS crypto-agility requirements,
as well as development of one or more Experimental RFCs providing
support for negotiation of alternative cryptographic algorithms
to protect RADIUS.

- IEEE 802 attributes. New attributes have been proposed to
support IEEE 802 standards for wired and wireless LANs. This
work item will support authentication, authorization and
accounting attributes needed by IEEE 802 groups including
IEEE 802.1, IEEE 802.11 and IEEE 802.16.

- New RADIUS transports. New secure transports for RADIUS will
be developed, including TCP/TLS (RADSEC) and UDP/DTLS.

- Documentation of Status-Server usage. A document
describing usage of the Status-Server facility will be
developed.

Goals and Milestones:
Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice RFC
Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed Standard RFC
Sep 2008 RADIUS Crypto-agility Requirements submitted as an Informational RFC
Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RC
Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC
Mar 2009 RADSEC draft submitted as an Experimental RFC
June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC
June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an Experimental RFC

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 2 Apr 2008 10:55:49 -0400

Bernard Aboba writes... 

> As we discussed at IETF 71, the RADEXT WG is looking at a re-charter.
> A strawman re-charter proposal is enclosed below.

Wow.  Silence.  I have to wonder if the RADEXT WG mailing list server is
broken, or all the RADEXT WG members are on vacation.  BTW, infer nothing
from the date on which this message was issued.   This is a serious
proposal, not an April Fool's joke. :-)

Discussion, please?

--
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: Alan DeKok <[email-masked]>
Date: Wed, 02 Apr 2008 17:22:36 +0200

> Discussion, please?

  The time frames look a little longer than "ideal".  Given the past
history of this WG, they should be fine.

  Alan DeKok.

---

From: [email-masked]
Date: Fri, 04 Apr 2008 09:40:14 +0200

Hi,

> proposal, not an April Fool's joke. :-)

I'm on vacation indeed :-)

The proposed text surpasses my expectations. I would have been fine  
with just taking out the one dash about no new transports.
This new text also "fixes" the questions like "Why is DTLS not against  
the charter, being a new security mechanism?", which have been asked  
in the past several times, including at IETF-71. The new text has more  
"truth in advertising" in that respect.

The proposed time frame of March 2009 looks plausible to me.

Greetings,

Stefan Winter

---

From: "Stephen Hanna" <[email-masked]>
Date: Fri, 4 Apr 2008 06:30:24 -0400

Sorry for taking a few days to respond. This looks like a good proposal
to me.
 
One nit. The milestone for Extended Attributes says "RC" instead of RFC.
 
Thanks,
 
Steve

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Bernard Aboba
Sent: Tuesday, April 01, 2008 3:41 PM
To: [email-masked]
Subject: RADEXT WG re-charter

As we discussed at IETF 71, the RADEXT WG is looking at a re-charter.  A
strawman re-charter proposal is enclosed below.  
Once comments from WG participants have been incorporated, we will begin
a formal WG consensus call on the proposed
re-charter by the end of the month. 

Work Items

 

Goals and Milestones:
Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice
RFC
Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed
Standard RFC
Sep 2008 RADIUS Crypto-agility Requirements submitted as an
Informational RFC
Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RC
Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC
Mar 2009 RADSEC draft submitted as an Experimental RFC
June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC
June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an
Experimental RFC

---

From: Mudit Goel <[email-masked]>
Date: Fri, 4 Apr 2008 15:31:05 -0700

Nicely worded. I like the proposal for the charter.

Mudit Goel

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Tuesday, April 01, 2008 3:41 PM
To: [email-masked]
Subject: RADEXT WG re-charter

Work Items

Goals and Milestones:

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 8 Apr 2008 21:22:09 -0700

Some questions on the proposed charter:

>All RADIUS work MUST be backward compatible with existing 
> RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 
> 3580, 4668-4673, 4675, 5080, 5090 and 5176.

What does it mean for a new transport to be backward compatible?

> be developed, including TCP/TLS (RADSEC) and UDP/DTLS.

What are we trying to gain by including new transports, especially TCP?
Is it just crypto agility or are there other goals as well?  This seems
like a lot of work to gain crypto agility, it would be good to
understand what else we have to gain.

What is the intended status of this work?  Experimental? Standards
track?  

> -RADIUS Cryptographic Algorithm Agility. RADIUS has 
> traditionally relied on MD5 for both per-packet integrity and 
> authentication as well as attribute confidentiality. Given 
> the increasingly successful attacks being mounted against 
> MD5, the ability to support alternative algorithms is 
> required. This work item will include documentation of RADIUS 
> crypto-agility requirements, as well as development of one or 
> more Experimental RFCs providing support for negotiation of 
> alternative cryptographic algorithms to protect RADIUS.
>  

Now that we have a separate item for secure transports shouldn't this
explicitly refer to attribute based encryption, message authentication
and key transport?  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Tuesday, April 01, 2008 12:41 PM
> As we discussed at IETF 71, the RADEXT WG is looking at a 
> re-charter.  A strawman re-charter proposal is enclosed below.  
> Once comments from WG participants have been incorporated, we 
> will begin a formal WG consensus call on the proposed 
> The RADIUS Extensions Working Group will focus on extensions 
> to the RADIUS protocol required to define extensions to the 
> standard attribute space as well as to address cryptographic 
> algorithm agility and use over new secure transports. In 
> addition, RADEXT will work on RADIUS Design Guidelines and 
> define new attributes for particular applications of 
> authentication, authorization and accounting such as NAS 
> management and local area network (LAN) usage. 
> 
> In order to enable interoperation of heterogeneous 
> RADIUS/Diameter deployments, all RADEXT WG work items MUST 
> contain a Diameter compatibility section, outlining how 
> interoperability with Diameter will be maintained.
>  
> 
> Furthermore, to ensure backward compatibility with existing 
> RADIUS implementations, as well as compatibility between 
> RADIUS and Diameter, the following restrictions are imposed 
> on extensions considered by the RADEXT WG:
>  
> 
> - All RADIUS work MUST be backward compatible with existing 
> RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 
> 3580, 4668-4673, 4675, 5080, 5090 and 5176.
>  
> 
> - All RADIUS work MUST be compatible with equivalent 
> facilities in Diameter. Where possible, new attributes should 
> be defined so that the same attribute can be used in both 
> RADIUS and Diameter without translation. In other cases a 
> translation considerations section should be included in the 
> specification.
>  
> 
> Work Items
>  
> 
> The immediate goals of the RADEXT working group are to 
> address the following issues:
>  
> 
> - RADIUS design guidelines. This document will provide 
> guidelines for design of RADIUS attributes. It will 
> specifically consider how complex data types may be 
> introduced in a robust manner, maintaining backwards 
> compatibility with existing RADIUS RFCs, across all the 
> - RADIUS Management authorization. This document will define 
> the use of RADIUS for NAS management over IP. 
>  
> 
> -RADIUS attribute space extension. The standard RADIUS 
> attribute space is currently being depleted. This document 
> will provide additional standard attribute space, while 
> maintaining backward compatibility with existing attributes.
>  
> 
> -RADIUS Cryptographic Algorithm Agility. RADIUS has 
> traditionally relied on MD5 for both per-packet integrity and 
> authentication as well as attribute confidentiality. Given 
> the increasingly successful attacks being mounted against 
> MD5, the ability to support alternative algorithms is 
> required. This work item will include documentation of RADIUS 
> crypto-agility requirements, as well as development of one or 
> more Experimental RFCs providing support for negotiation of 
> alternative cryptographic algorithms to protect RADIUS.
>  
>

---

From: <[email-masked]>
Date: Thu, 10 Apr 2008 09:45:58 -0700

> What does it mean for a new transport to be backward compatible?

I think it means that it is possible to write a transport proxy that goes 
to/from
RADIUS as it exists today (e.g. over UDP) and encapsulates it to/from the
new transport, with minimal (ideally no) changes to the RADIUS packet.

> understand what else we have to gain?

The contemplated work includes both DTLS/UDP and TLS/TCP
transports.   The arguments for the former relate primarily to
security;  the arguments for the later relate to both security
and transport considerations.   The benefits in both areas
have been laid out in presentations to the RADEXT WG
over the last year and a half.

Transport issues were examined in detail in the AAA WG,
which described AAA requirements (including transport) in
RFC 2989.   Reliable transport was chosen, as a result of
concerns over accounting reliability as well as experience
with the drawbacks of the undefined transport behavior
of RADIUS (discussed in RFC 5080 Section 2.2.1).

The behavior of AAA over reliable transport was analyzed in
RFC 3539, which also develops a transport profile and
suggests failover and load balancing algorithms.

Together, these documents provide a response to
RFC 2865 Section 2.4, which lays out four reasons why
RADIUS uses UDP:

   1. If the request to a primary Authentication server fails, a
      secondary server must be queried.
   2. The timing requirements of this particular protocol are
      significantly different than TCP provides.
   3. The stateless nature of this protocol simplifies the use of UDP.
   4. UDP simplifies the server implementation.

RFC 3539 provides  for failover and load balancing (1 & 2).
Since RADIUS was first standardized in the mid 1990s,
implementations have grown in sophistication and the
underlying hardware has increased by several orders of magnitude
in performance.   As a result, considerations 3 and 4 have lessened
in importance.

> What is the intended status of this work?  Experimental? Standards

The transport documents are slated for Experimental status
(as stated in the charter).

> explicitly refer to attribute based encryption, message authentication

The detailed requirements are going to be developed in a separate
document.  However, as discussed in the HOKEY WG meeting, the
focus of the RADEXT WG will be on providing a generic security
solution, including confidentiality, and message integrity/authentication.
As discussed in the HOKEY WG meeting, key management attributes
specific to ERX will be developed in HOKEY WG and will be independent
of the specific RADIUS crypto-agility mechanism.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 11 Apr 2008 15:37:32 -0700

Hi Bernard,

Thanks for the detailed explanation. 

With respect to the key transport item, I don't recall this discussion
on the HOKEY list. I might have missed it.  In any case I don't think
this is the right approach.  Key transport is a general problem that can
be solved with a general solution. 

Joe

> I think it means that it is possible to write a transport 
> proxy that goes to/from RADIUS as it exists today (e.g. over 
> UDP) and encapsulates it to/from the new transport, with 
> minimal (ideally no) changes to the RADIUS packet.
> 
> > Is it just crypto agility or are there other goals as well?  This 
> > seems like a lot of work to gain crypto agility, it would 
> be good to 
> have been laid out in presentations to the RADEXT WG over the 
> last year and a half.
> 
> Transport issues were examined in detail in the AAA WG, which 
> described AAA requirements (including transport) in
> with the drawbacks of the undefined transport behavior of 
> RADIUS (discussed in RFC 5080 Section 2.2.1).
> 
> Together, these documents provide a response to RFC 2865 
> Section 2.4, which lays out four reasons why RADIUS uses UDP:
> 
> The detailed requirements are going to be developed in a 
> separate document.  However, as discussed in the HOKEY WG 
> meeting, the focus of the RADEXT WG will be on providing a 
> generic security solution, including confidentiality, and 
> message integrity/authentication.
> As discussed in the HOKEY WG meeting, key management 
> attributes specific to ERX will be developed in HOKEY WG and 
> will be independent of the specific RADIUS crypto-agility mechanism.
> 

> re-charter.  
> >> Once comments from WG participants have been incorporated, we will 
> >> begin a formal WG consensus call on the proposed re-charter by the 
> >> end of the month.
> >>
> >> attribute space as well as to address cryptographic 
> algorithm agility 
> >> and use over new secure transports. In addition, RADEXT 
> will work on 
> >> RADIUS Design Guidelines and define new attributes for particular 
> >> applications of authentication, authorization and 
> accounting such as 
> >> NAS management and local area network (LAN) usage.
> >>
> >> implementations, as well as compatibility between RADIUS and 
> >> Diameter, the following restrictions are imposed on extensions 
> >> considered by the RADEXT WG:
> >>
> >>
> >> translation. In other cases a translation considerations section 
> >> should be included in the specification.
> >>
> >>
> >> Work Items
> >>
> >>
> guidelines for 
> >> - RADIUS Management authorization. This document will 
> define the use 
> >> of RADIUS for NAS management over IP.
> >>
> >>
> >> relied on MD5 for both per-packet integrity and authentication as 
> >> well as attribute confidentiality. Given the increasingly 
> successful 
> alternative 
> >> algorithms is required. This work item will include 
> documentation of 
> >> RADIUS crypto-agility requirements, as well as development 
> of one or 
> >> - IEEE 802 attributes. New attributes have been proposed 
> to support 
> >> IEEE 802 standards for wired and wireless LANs. This work 
> item will 
> >> support authentication, authorization and accounting attributes 
> >> needed by IEEE 802 groups including IEEE 802.1, IEEE 
> 802.11 and IEEE 
> >> 802.16.
> >>
> >>
> >> - New RADIUS transports. New secure transports for RADIUS will be 
> >> developed, including TCP/TLS (RADSEC) and UDP/DTLS.
> >>
> describing usage 
> >> of the Status-Server facility will be developed.
> >>
> >>
> >> Goals and Milestones:
> >> Jun 2008 RADIUS Design Guidelines submitted as a Best Current 
> >> Practice RFC Jun 2008 RADIUS Management Authorization I-D 
> submitted 
> >> as a Proposed Standard RFC Sep 2008 RADIUS Crypto-agility 
> >> Requirements submitted as an Informational RFC Sep 2008 Extended 
> >> Attributes I-D submitted as a Proposed Standard RC Dec 
> 2008 IEEE 802 
> >> Attributes I-D submitted as a Proposed Standard RFC Mar 2009 
> >> Status-Server I-D submitted as a Proposed Standard RFC Mar 2009 
> >> RADSEC draft submitted as an Experimental RFC June 2009 
> RADIUS over 
> >> DTLS I-D submitted as an Experimental RFC June 2009 RADIUS 
> >> Cryptographic Algorithm Agility I-D submitted as an 
> Experimental RFC
> >>
> >>
> > 
>

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 11 Apr 2008 18:58:22 -0400

Joseph Salowey writes...

> be solved with a general solution.

The discussion in the HOKEY session at IETF-71, as I recall it, centered
around whether HOKEY ought to define a non-protected RADIUS (Diameter)
attribute for key transport (I called this a key container attribute) that
could utilize various options for protection, one of which might be a
generalized Encrypted Attribute format, as described in a RADEXT
Crypto-Agility draft.

Follow up discussion in the RADEXT WG session included the issue of whether
or not the cryptographic requirements for key wrap (key transport) were
sufficiently different from the cryptographic requirements for transport of
bulk data that a separate protection mechanism needed to be defined.

We leaned that special purpose key wrap mechanisms could be "simpler" in
some cryptographic sense because one can rely on the property of keys that
their content is highly random.  The question that I think was never
satisfactorily answered is why one would need to deploy special purpose key
wrap mechanisms in addition to general propose attribute encryption
mechanisms.

Having said that, it is true that the RADIUS community has existing "special
purpose" key wrap attributes (the MSPPE key attributes) that do not meet the
crypto-agility requirements.  We need to decide what to do about these.
They are widely deployed today, e.g. in 802.11.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 14 Apr 2008 20:48:07 +0700

[email-masked] <> scribbled on Saturday, April 12, 2008
5:58 AM:

> Joseph Salowey writes...
> 
>> With respect to the key transport item, I don't recall this
>> discussion on the HOKEY list. I might have missed it.  In any case I
>> don't think this is the right approach.  Key transport is a general
>> problem that can be solved with a general solution.
> 
> The discussion in the HOKEY session at IETF-71, as I recall
> it, centered around whether HOKEY ought to define a
> non-protected RADIUS (Diameter) attribute for key transport (I
> called this a key container attribute) that could utilize
> various options for protection, one of which might be a

There was indeed discussion, but mostly in the form of various
assertions by the radext Chairs that this would be a good idea; I don't
recall anything like consensus around this topic.  

> 
> Follow up discussion in the RADEXT WG session included the
> issue of whether or not the cryptographic requirements for key
> wrap (key transport) were sufficiently different from the
> cryptographic requirements for transport of bulk data that a
> separate protection mechanism needed to be defined.
> 
> We leaned that special purpose key wrap mechanisms could be
> "simpler" in some cryptographic sense because one can rely on
> the property of keys that their content is highly random.  The
> question that I think was never satisfactorily answered is why
> one would need to deploy special purpose key wrap mechanisms
> in addition to general propose attribute encryption mechanisms.

I guess, then, that "gaining FIPS certification" is an unsatisfactory
answer, since that was the one I (among others) gave.  So what would be
a satisfactory answer?

> 
> Having said that, it is true that the RADIUS community has
> existing "special purpose" key wrap attributes (the MSPPE key
> attributes) that do not meet the crypto-agility requirements.
> We need to decide what to do about these.

Can you say "deprecate"? :-)

> to unsubscribe send a message to
> [email-masked] with the word 'unsubscribe' in
> a single line as the message text body.

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 14 Apr 2008 10:47:57 -0400

Glen Zorn writes...

> assertions by the radext Chairs that this would be a good idea;

That much is largely true.

>... I don't recall anything like consensus around this topic.

Unless I much mistake the poll questions and results that Charles
facilitated during the HOKEY meeting, there was consensus in the room.  Of
course, that is subject to consensus on the list.  I'm also aware that you
think this it not a good idea.

> answer, since that was the one I (among others) gave.  So what would
> be a satisfactory answer?

Well, "gaining FIPS certification" for a product release is likely a very
fine thing indeed.  I guess the question is whether the only way to do that
is to use the AES key-wrap as described in draft-zorn-radius-keywrap-13.txt,
or whether another NIST-approved algorithm, designed for bulk data
encryption might also be used?  In the latter case we solve the more general
problem, without requiring separate attribute formats for keys and general
purpose data.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 14 Apr 2008 23:47:52 +0700

[email-masked] <> scribbled on Monday, April 14, 2008 9:48
PM:

> Unless I much mistake the poll questions and results that
> Charles facilitated during the HOKEY meeting, there was
> consensus in the room.  

I really appreciate your judgment of consensus in the hokey WG.  Please
drop by more often.

> Of course, that is subject to
> consensus on the list.  I'm also aware that you think this it not a
> good idea. 

See below.

> Well, "gaining FIPS certification" for a product release is
> likely a very fine thing indeed.  I guess the question is
> whether the only way to do that is to use the AES key-wrap as
> described in draft-zorn-radius-keywrap-13.txt, or whether
> another NIST-approved algorithm, designed for bulk data
> encryption might also be used?  
> In the latter case we solve
> the more general problem, without requiring separate attribute
> formats for keys and general purpose data.

'Frankly, my dear, I don't give a damn.'  I do find it quite fascinating
to observe this whole thing happening in (very) slow motion.  It's been
nearly 4 years (!) since draft-zorn-radius-keywrap-00.txt was posted &
in that period of time every trick in the book (& I'm sure some that
were new additions) has been used to ignore, delay or kill it;
furthermore, for at least 3 years there have been at 2 (or more)
independent, interoperable implementations that were FIPS-certified.
But wait!  Let's spend a little (lot) more time conjecturing about
another way, a way to solve "the general problem" (AKA "boiling the
ocean" if it's a proposal we don't care for).  Well, gosh, no thanks,
but you guys go ahead & have fun!

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 14 Apr 2008 13:29:10 -0400

Glen Zorn writes...

> 'Frankly, my dear, I don't give a damn.' 

Cute...

> It's been nearly 4 years (!) since draft-zorn-radius-keywrap-00.txt
> was posted ... for at least 3 years there have been at 2 (or more)

Given that there are implementations of this key-wrap scheme, presumably
using VSAs, it might be well to publish an Information RFC, describing the
actual implementations, using those VSAs.

> but you guys go ahead & have fun!

RADEXT has a chartered work item to address crypto-agility.  We have
requirements for this wok, and we now have an ID capturing those
requirements.  We don't have a requirement to specifically address key-wrap,
as a separate problem.  My questions is whether RADEXT really needs to
create two drafts to satisfy the crypto-agility work item, one for key-wrap
and one for general purpose encrypted attributes.  The fact that solutions,
and drafts, exist to address key-wrap and encrypted attributes separately is
a point in favor of retaining the separation.  I'm just questioning whether
that's a sufficient basis on which to decide that we need such separation of
concerns.

If the consensus us of the WG is that we should proceed with separate
documents for key-wrap and general crypto-agility, we can propose doing that
in our revised charter.  It would be nice, however, to have a reason beyond
the existence of (4 year old) drafts that are structured that way.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 15 Apr 2008 13:07:24 -0700

There are a few reasons why you would want to wrap keys separately from
other data.  As you mentioned, the recommended algorithms for key wrap
may not be suitable for encrypting bulk data without special
consideration and some bulk data encryption algorithms may not be
recommended for key wrap without special consideration.  Another reason
is that you may want the entity that handles the keys and their context
to be different from the entity that handles the rest of the attributes.

Neither of these reasons forces you to have encryption tied directly to
the key attribute.  It is convenient since one is very often interested
in encrypting keys, but you can achieve the same thing with a generic
encryption attribute if you take care.  You need to support multiple
pieces of data encrypted with different keys (key IDs, alg IDs, message
boundaries, etc.) in the same message and you need to make sure that the
various supported encryption algorithms are used correctly (type of
cleartext, sufficient randomization, integrity protection, etc.).  These
things don't necessarily happen automatically or come for free. 

If you don't consider keys as part of the data you are wrapping for
crypto agility, I'm not sure you will end up with a result that is very
useful.  

Joe 
> From: David B. Nelson [mailto:[email-masked]] 
> Sent: Monday, April 14, 2008 10:29 AM
> To: [email-masked]; 'Glen Zorn'
> Cc: Joseph Salowey (jsalowey); [email-masked]
> Subject: RE: RADEXT WG re-charter
> 
> Glen Zorn writes...
> 
> Given that there are implementations of this key-wrap scheme, 
> presumably using VSAs, it might be well to publish an 
> Information RFC, describing the actual implementations, using 
> those VSAs.
> 
> RADEXT has a chartered work item to address crypto-agility.  
> We have requirements for this wok, and we now have an ID 
> capturing those requirements.  We don't have a requirement to 
> specifically address key-wrap, as a separate problem.  My 
> questions is whether RADEXT really needs to create two drafts 
> to satisfy the crypto-agility work item, one for key-wrap and 
> one for general purpose encrypted attributes.  The fact that 
> solutions, and drafts, exist to address key-wrap and 
> encrypted attributes separately is a point in favor of 
> retaining the separation.  I'm just questioning whether 
> that's a sufficient basis on which to decide that we need 
> such separation of concerns.
> 
> If the consensus us of the WG is that we should proceed with 
> separate documents for key-wrap and general crypto-agility, 
> we can propose doing that in our revised charter.  It would 
> be nice, however, to have a reason beyond the existence of (4 
> year old) drafts that are structured that way.
> 
> 
>

---

From: Alan DeKok <[email-masked]>
Date: Tue, 15 Apr 2008 23:48:21 +0200

> to be different from the entity that handles the rest of the attributes.

  i.e. distributing wireless keys to a NAS.  For reasons outlined in RFC
3538, RadSec is likely not a good idea for NAS -> local AAA
communications.  DTLS is better for transport, but still may be
difficult for some to implement.  Encrypting only the keys is likely
sufficient.

  Alan DeKok.

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 16 Apr 2008 08:52:02 -0400

Joseph Salowey writes...
 
> consideration  ...

Yes, because in those cases you are *relying* on the randomness of the key
material.

> ... and some bulk data encryption algorithms may not be
> recommended for key wrap without special consideration. 

That's the part I still don't understand.  The only "consideration" I've
heard so far is that "NIST hasn't blessed it", which is political and not
technical.  Of course, if you think that a critical goal of RADIUS
Crypto-Agility is to facilitate creating FIPS certifiable products, then
maybe this should be listed in the RADIUS Crypto-Agility Requirements draft.

> Another reason is that you may want the entity that handles the keys 
> and their context to be different from the entity that handles the rest
> of the attributes.

Perhaps.  You could provide that enforced "separation of concerns" by using
a separate KEK for the keys and a DEK for the data.  The algorithm and mode
need not be different to provide the isolation.  Since the key management
and distribution, e.g. automated key management, is currently out of scope
for RADIUS Crypto-Agility, that shouldn't present an impediment.

> encryption attribute if you take care. 

OK.  What care do we need to take?

> You need to support multiple pieces of data encrypted with different 
> keys (key IDs, alg IDs, message boundaries, etc.) in the same message 
> and you need to make sure that the various supported encryption 
> algorithms are used correctly (type of cleartext, sufficient 
> randomization, integrity protection, etc.). 

If we determine that the algorithm and mode that do not depend upon a random
payload, but are still strong when the payload happens to be random, what's
the issue?

> crypto agility, I'm not sure you will end up with a result that is very

Sure.  We need to have a method that works for keys, too.  I'm trying to
figure out if there is a "one size fits all" algorithm and method (assuming
a separate KEK), and if not, why not.  So far the only impediment that I see
remaining is the "it's not blessed by NIST" for that particular application,
e.g. key wrap.

BTW, thank you very much for a *technical* discussion of the issue.  It's
quite refreshing.  :-)

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 16 Apr 2008 15:28:49 -0700

> [mailto:[email-masked]] On Behalf Of David B. Nelson
> Sent: Wednesday, April 16, 2008 5:52 AM
> > There are a few reasons why you would want to wrap keys separately 
> > from other data.  As you mentioned, the recommended 
> algorithms for key 
> > wrap may not be suitable for encrypting bulk data without special 
> > consideration  ...
> 
> Yes, because in those cases you are *relying* on the 
> randomness of the key material.
> 
[Joe] That's at least part of the problem, but in general these
algorithms were not designed for bulk data encryption so there may be
other issues that I don't know about. 

> > ... and some bulk data encryption algorithms may not be recommended 
> > for key wrap without special consideration.
> 
> That's the part I still don't understand.  The only 
> "consideration" I've heard so far is that "NIST hasn't 
> blessed it", which is political and not technical.  Of 
> course, if you think that a critical goal of RADIUS 
> Crypto-Agility is to facilitate creating FIPS certifiable 
> products, then maybe this should be listed in the RADIUS 
> Crypto-Agility Requirements draft.
> 
[Joe] I wouldn't say this is just political.  NIST has designed an
algorithm for the purpose of wrapping keys.  While this may not be
everybody's favorite solution it seems silly to design a crypto-agility
solution that cannot accommodate it. I would say the requirement is to
support key wrapping. 

> > and their context to be different from the entity that handles the 
> > rest of the attributes.
> 
> Perhaps.  You could provide that enforced "separation of 
> concerns" by using a separate KEK for the keys and a DEK for 
> the data.  The algorithm and mode need not be different to 
> provide the isolation.  Since the key management and 
> distribution, e.g. automated key management, is currently out 
> of scope for RADIUS Crypto-Agility, that shouldn't present an 
> impediment.
> 
[Joe] Yes, at the very least the keys must be different, but for the
reasons discussed above you may want to vary the algorithms as well.  I
would think if you can figure out how to have different keys you can
also figure out how to support different algorithms. 

> > Neither of these reasons forces you to have encryption tied 
> directly 
> > to the key attribute.  It is convenient since one is very often 
> > interested in encrypting keys, but you can achieve the same 
> thing with 
> > a generic encryption attribute if you take care.
> 
[Joe] That's what I scribbled about on parenthesis below. 

> If we determine that the algorithm and mode that do not 
> depend upon a random payload, but are still strong when the 
> payload happens to be random, what's the issue?
> 
[Joe] As stated above the issues are using the algorithms for what they
are designed for and support separation between keys and their context
from other attributes.  There can be multiple ways we can design this
which would work out fine by pushing some of the inconvenient bits to
different places. 

> > crypto agility, I'm not sure you will end up with a result that is 
> > very useful.
> 
> Sure.  We need to have a method that works for keys, too.  
> I'm trying to figure out if there is a "one size fits all" 
> algorithm and method (assuming a separate KEK), and if not, 
> why not.  So far the only impediment that I see remaining is 
> the "it's not blessed by NIST" for that particular 
> application, e.g. key wrap.
> 
[Joe] NIST as defined a key wrapping algorithm, it may not be the best
thing for all purposes, but it is good enough for key wrapping and it
has been implemented for this purpose in various solutions.  Designing a
crypto-agility solution that cannot support this seems short-sighted
since NIST validation is an important part of many customer's
requirements.  This is especially true since one of the main pieces of
data people are concerned about protecting in today's deployments are
keys.  While I favor a specific attribute for key wrap solution, I do
not think it is necessary to design it this way.  If we support
different encrypted payloads in the same message with different keys and
different algorithms you have effectively the same thing (you just
wouldn't know that it was a key and its context that was wrapped).  We
should limit the usage of key-wrap specific algorithms to the purpose
they were designed for.   

> BTW, thank you very much for a *technical* discussion of the 
> issue.  It's quite refreshing.  :-)
> 
> 
> 
> --

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 16 Apr 2008 17:25:57 -0700

> technical.

At IETF 71, the technical discussion brought up the following points:

a.  The integrity protection for keywrap is considerably *weaker* (e.g. 64 
bits)
than for standard MIC algorithms.
b.  Encryption algorithms for keywrap cannot be securely used to do bulk 
encryption
of data, but algorithms that can do bulk encryption can securely be used to
encrypt keys.
c. Existing IETF standards (such as Diameter EAP, RFC 4702) use TLS to 
protect keys.
There are no known security issues relating to this.

As far as the "politics" goes,  at various points during this discussion, 
assertions
have been made with respect to NIST's position.   However, when
NIST was contacted to verify those assertions, they indicated that the 
assertions
either did not represent the official position of NIST, or that NIST had not 
yet
taken a position.

Given this, I would suggest that assertions made about NIST positions should
be ruled out of scope, unless they come directly from representatives of 
NIST.

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 17 Apr 2008 18:02:34 -0400

Bernard Aboba writes...

> a.  The integrity protection for keywrap is considerably *weaker* 
> (e.g. 64 bits) than for standard MIC algorithms.
> b.  Encryption algorithms for keywrap cannot be securely used to do
> bulk encryption of data, but algorithms that can do bulk encryption
> can securely be used to encrypt keys.

Are there specific recommendations (e.g. an "SP" series document) from NIST
that cover the use of bulk encryption algorithms to encrypt keys?

> Given this, I would suggest that assertions made about NIST positions
> should be ruled out of scope, unless they come directly from
> representatives of NIST.

Or presumably from existing NIST publications...

I tend to think (individual opinion) that facilitating FIPS "certifiable"
implementations might be a reasonable requirement to be added into the
RADIUS Crypto-Agility Requirements draft, assuming the reference is to an
existing NIST publication.  I understand that these publications would
discuss algorithms and modes only, and not cover how to encapsulate a key in
a RADIUS attribute.

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 17 Apr 2008 16:04:26 -0700 (PDT)

A very intersting discussion....

  Yes, bulk data protection with the current key wrapping scheme (RFC3394)
is problematic. It requires things to be 64-bit aligned, it doesn't
allow "associated data" (AD) which is authenticated but not encrypted, and
while it is probably secure it does not have a formal proof of security
behind it. All of these problems can be addressed by the SIV mode of AES.

  SIV can provide deterministic "key wrapping" when a component of the
plaintext is random, and it can provide nonce-based bulk data encryption.
In both variants it allows AD. It also provides security even in the
presence of nonce reuse. This last issue is especially critical when one
does not have a dynamic key exchange but, instead, uses statically
provisioned keys on the client and server. If one side crashes and loses
state (like a counter value or knowledge of previously used nonces) the
security of the system must not suffer, nor is it realistic to require
each side to checkpoint state in some non-volatile storage.

  Secure key wrapping with AD plus bulk data encryption with AD that is
resistant to nonce reuse, all in one cipher mode. That sounds useful....

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 18 Apr 2008 10:38:58 -0700 (PDT)

Hi Joe,

  Pardon me for leaping so far back in this thread.

  Is it a requirement to support multiple pieces of data encrypted with
different keys in the same message? If it is then apparently both DTLS
and IPsec are out-of-the-running since both those options secure the
entire payload with one set of keys. Is this your view?

  regards,

  Dan.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 18 Apr 2008 11:16:39 -0700

This is not a requirement for all deployments. If it is a requirement
then transport security presents a challenge, but it seems you could
encrypt the attributes that need to be separated, such as keys, with an
appropriate algorithm, such as SIV or the ever unpopular AES keywrap,
and then encapsulate the whole message including the encrypted
attributes with DTLS, IPSEC, etc. to protect additional attributes in
transit.  

So, I don't view these mechanisms as mutually exclusive. 

> From: Dan Harkins [mailto:[email-masked]] 
> Sent: Friday, April 18, 2008 10:39 AM
> To: Joseph Salowey (jsalowey)
> Cc: David B. Nelson; [email-masked]; Glen Zorn; 
> [email-masked]
>   Is it a requirement to support multiple pieces of data 
> encrypted with different keys in the same message? If it is 
> then apparently both DTLS and IPsec are out-of-the-running 
> since both those options secure the entire payload with one 
> set of keys. Is this your view?
> 
>   regards,
> 
>   Dan.
> 
> > recommended for key wrap without special consideration.  Another 
> > reason is that you may want the entity that handles the 
> keys and their 
> > context to be different from the entity that handles the 
> rest of the attributes.
> >
> >
> > a generic encryption attribute if you take care.  You need 
> to support 
> > multiple pieces of data encrypted with different keys (key IDs, alg 
> > IDs, message boundaries, etc.) in the same message and you need to 
> > make sure that the various supported encryption algorithms are used 
> > correctly (type of cleartext, sufficient randomization, integrity 
> > protection, etc.).  These things don't necessarily happen 
> automatically or come for free.
> >
> >> presumably using VSAs, it might be well to publish an Information 
> >> RFC, describing the actual implementations, using those VSAs.
> >>
> >> We have requirements for this wok, and we now have an ID capturing 
> >> those requirements.  We don't have a requirement to specifically 
> >> address key-wrap, as a separate problem.  My questions is whether 
> >> RADEXT really needs to create two drafts to satisfy the 
> >> crypto-agility work item, one for key-wrap and one for general 
> >> purpose encrypted attributes.  The fact that solutions, 
> and drafts, 
> >> exist to address key-wrap and encrypted attributes separately is a 
> >> point in favor of retaining the separation.  I'm just questioning 
> >> whether that's a sufficient basis on which to decide that we need 
> >> documents for key-wrap and general crypto-agility, we can propose 
> >> doing that in our revised charter.  It would be nice, however, to 
> >> have a reason beyond the existence of (4 year old) drafts that are 
> >> structured that way.
> >>
> >>
> >>
> >
> > --
> [email-masked] with

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 18 Apr 2008 14:18:32 -0400

Joseph Salowey writes...

> ...you could encrypt the attributes that need to be separated, such
> as keys, with an appropriate algorithm, such as SIV or the ever 
> unpopular AES keywrap, and then encapsulate the whole message 
> including the encrypted attributes with DTLS, IPSEC, etc. to 
> protect additional attributes in transit.
> 

In point of fact, based on the notion that NASes may be required to continue
using the legacy UDP-based RADIUS, these approaches may be complementary.
There may be cases where encrypted attributes are preferable to encrypted
transport.  The converse may also be true.