Subject: REMINDER: RADEXT WG Last Call on "Crypto-Agility Requirements for RADIUS"

From: Bernard Aboba <[email-masked]>
Date: Wed, 13 Aug 2008 19:05:48 -0700 (PDT)

This is a reminder of the ongoing RADEXT WG Last Call on "Crypto-Agility 
Requirements for RADIUS" prior to requesting that the IESG publish it as 
an Informational RFC. 
 
The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-00.txt
 
WG Last Call was to have lasted until August 10, 2008.   Since there 
have been no comments posted yet, we will extend the last call for 
another two weeks (until August 31, 2008).  Please 
review the document and post your comments to the RADEXT WG mailing list 
([email-masked]) in the format described on the RADEXT WG Issues 
list (http://www.drizzle.com/~aboba/RADEXT/).   
 
If you have read the document and approve of its publication, but have no
comments, please also post this to the list. 

--
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: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 14 Aug 2008 13:04:34 -0700

I have read the draft and for the most part it looks good.

I have a few comments:

1. Section 4.2:

In cases where the client needs to protect all or part of the radius
request the "hint and select" negotiation the client would provide more
than a hint when it chooses the algorithms for protection.  Perhaps hint
and select is not quite the right term, may be specify and select?  The
client specifies what it uses and can specify a list it supports that
the server can use. 

2. Section 4.6:

Section 4.6 makes reference to security considerations text about key
management.  Shouldn't this text be in this document?

Thanks,

Joe

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Wednesday, August 13, 2008 7:06 PM
> To: [email-masked]
> Subject: REMINDER: RADEXT WG Last Call on "Crypto-Agility 
> Requirements for RADIUS"
> 
> This is a reminder of the ongoing RADEXT WG Last Call on 
> "Crypto-Agility Requirements for RADIUS" prior to requesting 
> that the IESG publish it as an Informational RFC. 
>  
http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-req
uirements-00.txt
> have been no comments posted yet, we will extend the last 
> call for another two weeks (until August 31, 2008).  Please 
> If you have read the document and approve of its publication, 
> but have no comments, please also post this to the list. 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 14 Aug 2008 13:04:34 -0700

I have a few comments:

1. Section 4.2:

2. Section 4.6:

Thanks,

Joe

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 15 Aug 2008 15:53:55 +0700

Questions:

The WG Charter states that all of the existing crypto-agility proposals are
to be published as Experimental RFCs.  In that case, how can the requirement
that " at least one mandatory to implement algorithm will be defined"
(section 1.2) be fulfilled?

Editorial comments:

Front page header:
Since the source of the document is stated in section 1.1 to be the radext
WG, David's role should probably be "Editor".

Section 1.2:
s/propose one of more Internet Drafts/propose one or more Internet-Drafts/

Section 2:
s/Crypto-Agility is the ability for/Crypto-agility is the ability of/

Section 4.5, paragraph 5 states:

   Editorial Note: With the expected acceptance of the proposed RADEXT
   WG Charter revision, some of the issues raised in the preceding
   paragraphs become moot, and this section ought to be revised to
   reflect the revised charter.

Haven't those charter revisions already taken place?

Technical comments:

Section 2, paragraph 2 states:

   In the specific context of the RADIUS protocol and RADIUS
   implementations, crypto-agility may be better defined as the ability
   of RADIUS implementations to negotiate cryptographic algorithms for
   use in RADIUS exchanges, including the cryptographic algorithms used
   to protect RADIUS packets and to hide RADIUS Attributes.  This
   capability covers all RADIUS message types: Access-Request/Response,
   Accounting-Request/Response, and CoA/Disconnect-Request/Response.

Since RADIUS has no negotiation method of I'm aware (hint & accept/ignore is
hardly a negotiation mechanism) I find these statements very curious,
especially in light of the earlier statement (section 2, paragraph 3) that
the password-hiding function will be negotiable.  Basically, what is being
called for is impossible in the context of the RADIUS protocol, implying
that the negotiations would take place outside of RADIUS (e.g., in TLS).  I
think that it is at least inappropriate in a requirements document, in that
it assumes a solution.

Section 4.1: 
Once again, assuming a solution.  State the requirements that a solution
must meet, not your personal assumptions about the form which the solution
will take.  I say "personal" because a fair subset of the active WG (of
which this document is purportedly a product) _does not_ share the
expectation that " proposals will utilize other techniques".

Section 4.2, paragraph 2 states:

   Included in negotiation techniques are "hint and consent" mechanisms
   where the NAS provides a list of algorithms and the server selects
   one.

If the server is required to select from the list it can hardly be called a
hint.  Once again, I can't see at all how this mechanism could be made to
work in the case of the Access-Request message.

Section 4.3, paragraph 1 states:

   Solutions to the problem MUST demonstrate backward compatibility with
   existing RADIUS implementations.  

I would _really_ like to see some rationale for this requirement (aside from
"backward compatibility is sacred and must never be questioned" ;-).  Given
that this is new and presumably desirable functionality, why is a simple
upgrade path not sufficient?

Section 4.5, paragraph 3 states:

   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.  

OK, I'll bite: how, exactly, does the introduction of a new command
fundamentally change the RADIUS operational model?

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 15 Aug 2008 13:17:12 -0400

Joseph Salowey writes...

> request the "hint and select" negotiation the client would provide 
> more than a hint when it chooses the algorithms for protection. 
> Perhaps hint and select is not quite the right term, may be specify
> and select?

While adding a more robust form of capabilities negotiation to RADIUS might
be a useful thing, it's not a charted work item.  I think we are stuck with
the current "hint and select" paradigm that is common usage in RADIUS today.

Perhaps I've misunderstood your comment.  Could you give an example?

> management.  Shouldn't this text be in this document?

Yes, I think so.  Would anyone like to propose some text and a citation into
RFC 4017?

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 15 Aug 2008 13:35:20 -0400

Glen Zorn writes...

> The WG Charter states that all of the existing crypto-agility
> proposals are to be published as Experimental RFCs.  In that case,
> how can the requirement that " at least one mandatory to implement 
> algorithm will be defined" (section 1.2) be fulfilled?

Why not?  The algorithms are defined in existing documents.

> Front page header:
> Since the source of the document is stated in section 1.1 to be
> the radext WG, David's role should probably be "Editor".

Yes.

> s/Crypto-Agility is the ability for/Crypto-agility is the ability of/

OK.

> Haven't those charter revisions already taken place?

As of submission of the -00 draft, the IESG was still deliberating the
re-charter request.  Will be fixed in -01.

> Since RADIUS has no negotiation method of I'm aware (hint & 
> accept/ignore is hardly a negotiation mechanism)...

Yeah, but it's what we've got.

>... I find these statements very curious, especially in light of the
> earlier statement (section 2, paragraph 3) that the password-hiding
> function will be negotiable.  Basically, what is being called for is
> impossible in the context of the RADIUS protocol, implying that the
> negotiations would take place outside of RADIUS (e.g., in TLS).

That wasn't what I understood when I transcribed that text.  It's true that
"hint and consent" is a bit crude, but I'd like to see a more in-depth
technical exploration of why you think it makes crypto-agility impossible
within RADIUS

> expectation that " proposals will utilize other techniques".

I take that text to means that RADIUS over IPSec has already been defined,
and therefore proposing RADIUS over IPSec is not what we're looking for to
address RADIUS crypto-agility.  After all, if an existing solution needs
everyone's needs, why waste time on a requirements document, never mind a
solution document?  Therefore, it's reasonable to say that "Just use IPSec."
is out of scope for RADIUS crypto-agility.

> If the server is required to select from the list it can hardly be 
> called a hint.  Once again, I can't see at all how this mechanism 
> could be made to work in the case of the Access-Request message.

Please explain.

>    Solutions to the problem MUST demonstrate backward compatibility
>    with existing RADIUS implementations.
> 
> I would _really_ like to see some rationale for this requirement 
> (aside from "backward compatibility is sacred and must never be 
> questioned" ;-).

Given that the RADIUS protocol doesn't have a protocol version field,
maintaining backward compatibility seems pretty basic.

> Given that this is new and presumably desirable functionality,
> why is a simple upgrade path not sufficient?

A "fork-lift" upgrade?  :-)

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 16 Aug 2008 15:17:03 +0700

> Why not?  The algorithms are defined in existing documents.

What documents?  Since an Experimental RFC holds no standing as a standard,
how can it specify _anything_ as mandatory?

...

> technical exploration of why you think it makes crypto-agility

The last time I checked (please correct me if I'm wrong), the "hint" was
from a NAS to a server regarding what the NAS wanted returned.  In many
cases, these "hints" would not be anything of the sort; instead, they will
be a simple statement of the algorithm used by the NAS.  Examples are the
User-Password Attribute & request authentication/integrity protection.  The
only way that I can think of for the server to refuse the "hint" would be if
we were to hi-jack the Access-Challenge message, which in itself constitutes
a novel negotiation method for RADIUS.

> is out of scope for RADIUS crypto-agility.

The text to which I was referring is "Therefore, it is expected that
proposals will utilize other techniques".

> > could be made to work in the case of the Access-Request message.

See above.

> maintaining backward compatibility seems pretty basic.

OK, so that sounds an awful lot like " backward compatibility is sacred and
must never be questioned" to me.  

> A "fork-lift" upgrade?  :-)

Hardly. New messages and or capabilities can fairly easily be introduced in
a piece-meal fashion, as long as it is done with care.

---

From: "David B. Nelson" <[email-masked]>
Date: Sat, 16 Aug 2008 10:13:26 -0400

Glen Zorn writes...

> What documents?

Those defining the cipher suites to be used.  Surely we're not going to
attempt to define them within a RADIUS document?

> Since an Experimental RFC holds no standing as a standard, how can it
> specify _anything_ as mandatory?

Sorry to be repetitive, buy why not?

> be a simple statement of the algorithm used by the NAS.

How is that not a hint?  Sorry, but I simply don't see where you're going
with this.

> Examples are the User-Password Attribute & request
> authentication/integrity protection.

Eh?

> The only way that I can think of for the server to refuse the
> "hint" would be if we were to hi-jack the Access-Challenge message,
> which in itself constitutes a novel negotiation method for RADIUS.

Well, yes.  We discussed that briefly during an ill-fated attempt to add
generic capabilities negotiation to RADIUS.  So, yes there is no "NAK" and
counter-proposal capability, simply offer and accept or offer and reject.  I
fail to see why that would not allow a rudimentary form of crypto-agility.
The way a server refuses the hint by means of an Access-Reject message.

> > Therefore, it's reasonable to say that "Just use IPSec."

Well, if "Just use IPSec" is out of scope, doesn't it follow that "proposals
will use other methods" [besides IPSec)?  Again, I simply don't see where
you're going with this.

> OK, so that sounds an awful lot like " backward compatibility is sacred
> and must never be questioned" to me.

If you say so...

> Hardly. New messages and or capabilities can fairly easily be introduced
> in a piece-meal fashion, as long as it is done with care.

Well _that_ sounds a bit like "and a miracle occurs here".  That which is a
simple upgrade path to some is a deployment nightmare to others.  We need to
be a bit more specific, I think.

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 17 Aug 2008 17:11:37 +0700

> attempt to define them within a RADIUS document?

Define what?  Whether the algorithm is mandatory to implement for use in
RADIUS?  I sincerely hope so!

> How is that not a hint?  

Some definitions of "hint":

an indirect suggestion
a slight indication
a clue

What about any of those suggests a declarative statement?

...

> The way a server refuses the hint by means of an Access-Reject message.

And the client knows that this is a refusal of this particular hint (instead
of the multiple other conditions that might elicit an Access-Reject how,
exactly?  Parsing the Reply-Message Attribute that may or may not be
present?

...

> Well _that_ sounds a bit like "and a miracle occurs here".  

I guess miracles really do happen every day then ;-): support for EAP,
dynamic authorization, 802.11...

...

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 18 Aug 2008 14:05:48 -0700

> [mailto:[email-masked]] On Behalf Of David B. Nelson
> Sent: Friday, August 15, 2008 10:17 AM
> Subject: RE: REMINDER: RADEXT WG Last Call on "Crypto-Agility 
> Requirements for RADIUS"
> 
> Joseph Salowey writes...
> 
> > 1. Section 4.2:
> > 
> While adding a more robust form of capabilities negotiation 
> to RADIUS might be a useful thing, it's not a charted work 
> item.  I think we are stuck with the current "hint and 
> select" paradigm that is common usage in RADIUS today.
> 
[Joe] There is some confusion.  I don't want to change the behavior, I
just think the term "hint and select" is a bit misleading since the
client will have to select some algorithm to protect its messages.  This
is a bit more than a "hint".  The client can "hint to the server what it
supports.  

> Yes, I think so.  Would anyone like to propose some text and 
> a citation into RFC 4017?
> 
[Joe] I'll try to provide some text by the end of the week.

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 18 Aug 2008 17:21:21 -0400

Joseph Salowey writes...

> [Joe] There is some confusion.

I think an example packet exchange, showing how the client and server
"negotiate" the algorithm they will mutually use would be helpful.

> [Joe] I'll try to provide some text by the end of the week.

Thanks.