Many thanks Alan for the thorough review.
We¹ll collate all your comments and respond shortly.
On 12/10/2016 22:35, "Alan DeKok" wrote:
> My $0.02 on the contents of the Security Considerations section. I'm
>sure I've missed things.
>
> Please also comment if the suggestions here are wrong
My $0.02 on the contents of the Security Considerations section. I'm sure
I've missed things.
Please also comment if the suggestions here are wrong or unworkable.
9. Security Considerations
The protocol described in this document has been in widespread use
since specified in "The Dra
Continuing with Section 8
... Privilege Levels are ordered values from 0 to 15
with each level representing a privilege level that is a superset of
the next lower value.
* nit: perhaps this could be "each level is defined to be a superset of the
next lower value", instead of "repres
Continuing with 4.4.3
While the order of hosts in this packet indicates a preference, but
the client is not obliged to use that ordering.
* the use of "obliged" is unusual here. Perhaps "the order used by the client
is implementation specific, and does not have to follow the order s
> But do we want to change it all at this time?
yes. a proper sec cons does not change the protocol but advises as to
its use.
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
FWIW - I agree with much of Alan's observation and with his approach here.
Documenting an existing protocol does not mean changing it. Asking for
changes in the content of the document (including more details about
implementation of parts of the protocols, and security implications of
deploying thi
One comment: stating that (for example) “this protocol has no security” leave
no illusions (covers the situation completely), but convinces security
practitioners that its advancement should be blocked/vetoed (“discuss” in IETF
lingo J) until the “no security” situation changes.
--
Regards,
Hi,
Regarding your a) b) c) elements, we are happy to work through the issues
in a different thread, and will wait your final instalment. This specific
question/thread regarded security, hence the handy change of subject.
The reason I would go along the lines of your proposal at the end (but
with
On Oct 6, 2016, at 1:34 PM, Douglas Gash (dcmgash) wrote:
> Regarding the security concern, the approach we have with the current
> document is:
>
> 1) A statement that the protocol does not provide security in a modern
> environment.
I'm happy with that.
> 2) The two common approaches to su
lt;mailto:draft-ietf-opsawg-tacacs...@tools.ietf.org>"
mailto:draft-ietf-opsawg-tacacs...@tools.ietf.org>>,
"opsawg@ietf.org<mailto:opsawg@ietf.org>"
mailto:OpsAWG@ietf.org>>
Subject: Re: [OPSAWG] Start of WGLC for TACACS+ document.
A protocol description needs to include
A protocol description needs to include: (a) what threats/attacks become
possible as a result of its introduction, (b) how the protocol defends against
[at least some of] them, (c) how the remaining attacks can be mitigated, (d)
what are the remaining risks.
Yes, dissection of vulnerabilitie
Hi Alan,
Regarding the security concern, the approach we have with the current
document is:
1) A statement that the protocol does not provide security in a modern
environment.
2) The two common approaches to support T+ so that it may be used.
3) An indication that a version with built-in securit
On Oct 6, 2016, at 12:19 PM, t.petch wrote:
> You are not, and I did not mean to imply that you were. I mean that
> your changes seem to me reflect a different approach, a different style
> which I do not see as that of the authors. I see the existing style as
> unusual, but not wrong, and am co
- Original Message -
From: "Alan DeKok"
Sent: Thursday, October 06, 2016 2:56 PM
On Oct 6, 2016, at 6:00 AM, t.petch wrote:
> Alan is right to pick up on the style - philosophical - and the
> security - lack of.
>
> But do we want to change it all at this time?
Please show where I'm
Hi Alan,
Thank you for your detailed review so far. When we get the last
instalment, we¹ll categorise the comments and respond.
Best regards,
Doug.
On 06/10/2016 14:56, "Alan DeKok" wrote:
>On Oct 6, 2016, at 6:00 AM, t.petch wrote:
>> Alan is right to pick up on the style - philosophical -
On Oct 6, 2016, at 6:00 AM, t.petch wrote:
> Alan is right to pick up on the style - philosophical - and the
> security - lack of.
>
> But do we want to change it all at this time?
Please show where I'm trying to change the protocol.
> This is an Informational document describing the state of
Um
Alan is right to pick up on the style - philosophical - and the
security - lack of.
But do we want to change it all at this time?
This is an Informational document describing the state of play as of
some time past, perhaps not as far back as 1997 but not for 2016. It
would require many chang
Continuing...
Summary: the spec is still fairly descriptive / philosophical instead of
prescriptive. Many optional parts of the protocol are described, "A and B are
allowed", but there is often no description of what to *do* when either A or B
is present. I've suggested descriptive text,
Some comments. Mostly little nits and clarifications.
The major points for me are related to security. The "Security
Considerations" section is almost empty, and will certainly not pass a review
from the security area. They will in all likelihood block publication until
substantive comme
Dear OpsAWG WG,
The authors of draft-ietf-opsawg-tacacs-05 have indicated that they
believe that the document is ready, and have asked for Working Group
Last Call.
This WGLC ends Mon 17-Oct-2016.
Please review this draft to see if you think it is ready for
publication and send comments to the li
20 matches
Mail list logo
