[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[radext] #23: Comments
#23: Comments
----------------------------------+-----------------------------------------
Reporter: glenzorn@â | Owner: bernard_aboba@â
Type: defect | Status: new
Priority: major | Milestone: milestone1
Component: Crypto-Agility | Version: 1.0
Severity: Active WG Document | Keywords:
----------------------------------+-----------------------------------------
Date first submitted: August 15, 2008
Reference: http://ops.ietf.org/lists/radiusext/2008/msg00483.html
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?
[David Nelson]
> 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.
> 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/
OK.
> 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?
As of submission of the -00 draft, the IESG was still deliberating the
re-charter request. Will be fixed in -01.
> 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)...
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
> 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".
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.
> 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.
Please explain.
> 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 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? :-)
--
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/23>
radext <http://tools.ietf.org/radext/>
--
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/>