Subject: [radext] #22: Review

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

#22: Review
--------------------------------+-------------------------------------------
 Reporter:  jsalowey@…          |       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 14, 2008
 Reference:  http://ops.ietf.org/lists/radiusext/2008/msg00480.html
 Section: 4.2, 4.6

 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?

 [David Nelson]

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

 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?

 > 2. Section 4.6:
 >
 > Section 4.6 makes reference to security considerations text about key
 > 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?

 [Joe Salowey]

 > Perhaps I've misunderstood your comment.  Could you give an example?
 >
 [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.

 > > 2. Section 4.6:
 > >
 > > Section 4.6 makes reference to security considerations text
 > about key
 > > 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?
 >
 [Joe] I'll try to provide some text by the end of the week.
 Issue 274: Review
 Submitter name: Joe Salowey
 Submitter email address: [email-masked]
 Date first submitted:  August 14, 2008
 Reference:  http://ops.ietf.org/lists/radiusext/2008/msg00480.html
 Document: draft-ietf-radext-crypto-agility-requirements-00.txt
 Comment type: Technical
 Priority: S
 Section: 4.2, 4.6
 Rationale/Explanation of issue:

 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?

 [David Nelson]

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

 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?

 > 2. Section 4.6:
 >
 > Section 4.6 makes reference to security considerations text about key
 > 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?

 [Joe Salowey]

 > Perhaps I've misunderstood your comment.  Could you give an example?
 >
 [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.

 > > 2. Section 4.6:
 > >
 > > Section 4.6 makes reference to security considerations text
 > about key
 > > 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?
 >
 [Joe] I'll try to provide some text by the end of the week.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/22>
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/>