Subject: [radext] #23: Comments

From: "radext issue tracker" <[email-masked]>
Date: Fri, 14 May 2010 02:14:50 -0000

#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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>