[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[radext] #22: Review
#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: jsalowey@cisco.com
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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>