Re: [OPSAWG] Action Items on TACACS+ informational draft v 10
> On 10 Jul 2018, at 22:38, Joe Clarke wrote: > >> >> Let us (authors) take this recent feedback on board and reword things >> along the lines: >> - Use MUST where we want programmers to do the right thing, but be >> careful not to distort the actual protocol as currently implemented. >> Handling secrets, passwords seem like good targets for this. > > With the particular point of handling secrets and passwords, linking to > specific suggestions of this would be a plus, too. > >> - Keep and improve verbiage documenting known risks. >> - Give either MUST verbiage where there's only one thing to do (e.g. >> secured transport is a MUST). >> - Give SHOULD where there's multiple things (e.g. PAP vs. CHAP is >> closely related to password management on the server side). >> >> Would this be the right way or not really? > > This sounds like the right approach to me. Daytime job caught up with me, I'll start the writeup on the weekend. Andrej. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Action Items on TACACS+ informational draft v 10
On 7/10/18 11:42, Andrej Ota wrote: >>> Since this makes secured transport a minimal necessary requirement >>> for any secure deployment, what benefit is there to try and find >>> further examples of what can be mandated if none of the mandates >>> would meaningfully change the end result? >> >> It's useful to explain *what* behaviours are insecure, and *why* >> they are insecure. > > Agreed. We (authors) were trying to put in more of the background as to > what are the threats for this reason - empowering those who need to > deploy the protocol to make the correct call. I wholeheartedly agree we should point these out and offer suggestions to operators (and vendors) on how to best mitigate them. > > Though I'd flip this and put emphasis on what behaviours are secure and > declare others explicitly unsecure. That works for me. > >> >> The alternative is to leave the reader to fend for himself. >> "Hmm... the authors didn't say this was bad, so let's do it!" > > No, that would be really bad outcome and I agree we must avoid it. Agreed, and I was not suggesting this. > > Let us (authors) take this recent feedback on board and reword things > along the lines: > - Use MUST where we want programmers to do the right thing, but be > careful not to distort the actual protocol as currently implemented. > Handling secrets, passwords seem like good targets for this. With the particular point of handling secrets and passwords, linking to specific suggestions of this would be a plus, too. > - Keep and improve verbiage documenting known risks. > - Give either MUST verbiage where there's only one thing to do (e.g. > secured transport is a MUST). > - Give SHOULD where there's multiple things (e.g. PAP vs. CHAP is > closely related to password management on the server side). > > Would this be the right way or not really? This sounds like the right approach to me. Joe ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Action Items on TACACS+ informational draft v 10
On Jul 10, 2018, at 11:42 AM, Andrej Ota wrote: > Agreed. We (authors) were trying to put in more of the background as to what > are the threats for this reason - empowering those who need to deploy the > protocol to make the correct call. > > Though I'd flip this and put emphasis on what behaviours are secure and > declare others explicitly insecure. Sure. It would be useful to explain why they're insecure. But that's largely a nit, not a serious disagreement. >> The alternative is to leave the reader to fend for himself. "Hmm... the >> authors didn't say this was bad, so let's do it!" > > No, that would be really bad outcome and I agree we must avoid it. > > Let us (authors) take this recent feedback on board and reword things along > the lines: > - Use MUST where we want programmers to do the right thing, but be careful > not to distort the actual protocol as currently implemented. I agree that we shouldn't *change* the protocol. But *deprecating* portions is entirely appropriate. Given the insecure nature of it, I would say it's *required* that we deprecate insecure portions of the protocol. > Handling secrets, passwords seem like good targets for this. > - Keep and improve verbiage documenting known risks. > - Give either MUST verbiage where there's only one thing to do (e.g. secured > transport is a MUST). > - Give SHOULD where there's multiple things (e.g. PAP vs. CHAP is closely > related to password management on the server side). > > Would this be the right way or not really? Yes. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Action Items on TACACS+ informational draft v 10
On 07/10/2018 03:48 PM, Alan DeKok wrote: On Jul 10, 2018, at 10:11 AM, Andrej Ota wrote: Actually, both PAP and CHAP are irrelevant in this case. If Eve is in a position to intercept TACACS+ traffic, she can flip a single bit in the authentication response and that will ensure that the device (client) will consider authentication to have succeeded. Obfuscation doesn't help, only secured transport does. Yes. Thus it's irrelevant to specifically mention any particular currently used authentication method as all of them fail in exactly the same way *and* it's irrelevant to distinguish between obfuscated and non-obfuscated variety as MitM will succeed regardless. Yes and no. It's still bad to send clear-text passwords over a clear channel. That can be called out and explained. Agreed. Since this makes secured transport a minimal necessary requirement for any secure deployment, what benefit is there to try and find further examples of what can be mandated if none of the mandates would meaningfully change the end result? It's useful to explain *what* behaviours are insecure, and *why* they are insecure. Agreed. We (authors) were trying to put in more of the background as to what are the threats for this reason - empowering those who need to deploy the protocol to make the correct call. Though I'd flip this and put emphasis on what behaviours are secure and declare others explicitly unsecure. The alternative is to leave the reader to fend for himself. "Hmm... the authors didn't say this was bad, so let's do it!" No, that would be really bad outcome and I agree we must avoid it. Let us (authors) take this recent feedback on board and reword things along the lines: - Use MUST where we want programmers to do the right thing, but be careful not to distort the actual protocol as currently implemented. Handling secrets, passwords seem like good targets for this. - Keep and improve verbiage documenting known risks. - Give either MUST verbiage where there's only one thing to do (e.g. secured transport is a MUST). - Give SHOULD where there's multiple things (e.g. PAP vs. CHAP is closely related to password management on the server side). Would this be the right way or not really? Andrej. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Action Items on TACACS+ informational draft v 10
On Jul 10, 2018, at 10:11 AM, Andrej Ota wrote: > Actually, both PAP and CHAP are irrelevant in this case. If Eve is in a > position to intercept TACACS+ traffic, she can flip a single bit in the > authentication response and that will ensure that the device (client) will > consider authentication to have succeeded. Obfuscation doesn't help, only > secured transport does. Yes. > Thus it's irrelevant to specifically mention any particular currently used > authentication method as all of them fail in exactly the same way *and* it's > irrelevant to distinguish between obfuscated and non-obfuscated variety as > MitM will succeed regardless. Yes and no. It's still bad to send clear-text passwords over a clear channel. That can be called out and explained. > Since this makes secured transport a minimal necessary requirement for any > secure deployment, what benefit is there to try and find further examples of > what can be mandated if none of the mandates would meaningfully change the > end result? It's useful to explain *what* behaviours are insecure, and *why* they are insecure. The alternative is to leave the reader to fend for himself. "Hmm... the authors didn't say this was bad, so let's do it!" Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Action Items on TACACS+ informational draft v 10
On 07/10/2018 12:34 PM, Alan DeKok wrote: On Jul 10, 2018, at 3:52 AM, Andrej Ota wrote: Could it be that we misunderstood each other as to what b) pertains to? a) is obviously wrong as we certainly don't have to stop at documenting current practices or even care about current practices if they result in an insecure deployment. For b) I don't find it controversial as long as we can agree that "implementation" means "how clients and servers implement documented protocol" and not "how do operators deploy clients and servers". I.e. "implementation" and "practice" refer to two different things. The draft should document how to implement *and* deploy TACACS+ as securely as we know how. If that "invalidates" current implementations and practices, too bad. Again, vendors and administrators are free to ignore the recommendations of the draft. But they need to *know*. If the draft permits deployments we know to be insecure, then that's wrong. And yes, such practice *would be* "rubber stamping" existing practices. While the requirement is to document the historical protocol, that does *not* mean endorsing 20 year-old insecure practices. The IETF has a responsibility to secure the Internet, among other things. Where that responsibility conflicts with vendor / operator desire to do insecure things, then the larger Internet security will prevail. Then we can comb for ambiguous statements like "server MUST implement CHAP in exclusion to PAP" and reword them to say "operators MUST use servers and clients configured to disallow authentication methods other that CHAP". PAP is fine so long as (a) it's in a management network, or (b) it's "protected" by the obfuscation mechanism. The spec should just describe the requirements. How the implementors and administrators deploy it is up to them. e.g. "PAP MUST NOT be used outside of management networks, unless the packets are protected by the obfuscation mechanism." Actually, both PAP and CHAP are irrelevant in this case. If Eve is in a position to intercept TACACS+ traffic, she can flip a single bit in the authentication response and that will ensure that the device (client) will consider authentication to have succeeded. Obfuscation doesn't help, only secured transport does. Thus it's irrelevant to specifically mention any particular currently used authentication method as all of them fail in exactly the same way *and* it's irrelevant to distinguish between obfuscated and non-obfuscated variety as MitM will succeed regardless. Since this makes secured transport a minimal necessary requirement for any secure deployment, what benefit is there to try and find further examples of what can be mandated if none of the mandates would meaningfully change the end result? Andrej. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Action Items on TACACS+ informational draft v 10
On Jul 10, 2018, at 3:52 AM, Andrej Ota wrote: > > Could it be that we misunderstood each other as to what b) pertains to? a) is > obviously wrong as we certainly don't have to stop at documenting current > practices or even care about current practices if they result in an insecure > deployment. > > For b) I don't find it controversial as long as we can agree that > "implementation" means "how clients and servers implement documented > protocol" and not "how do operators deploy clients and servers". I.e. > "implementation" and "practice" refer to two different things. The draft should document how to implement *and* deploy TACACS+ as securely as we know how. If that "invalidates" current implementations and practices, too bad. Again, vendors and administrators are free to ignore the recommendations of the draft. But they need to *know*. If the draft permits deployments we know to be insecure, then that's wrong. And yes, such practice *would be* "rubber stamping" existing practices. While the requirement is to document the historical protocol, that does *not* mean endorsing 20 year-old insecure practices. The IETF has a responsibility to secure the Internet, among other things. Where that responsibility conflicts with vendor / operator desire to do insecure things, then the larger Internet security will prevail. > Then we can comb for ambiguous statements like "server MUST implement CHAP in > exclusion to PAP" and reword them to say "operators MUST use servers and > clients configured to disallow authentication methods other that CHAP". PAP is fine so long as (a) it's in a management network, or (b) it's "protected" by the obfuscation mechanism. The spec should just describe the requirements. How the implementors and administrators deploy it is up to them. e.g. "PAP MUST NOT be used outside of management networks, unless the packets are protected by the obfuscation mechanism." Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Action Items on TACACS+ informational draft v 10
On 10/07/2018 02:56, Alan DeKok wrote: On Jul 9, 2018, at 9:17 PM, Scott O. Bradner wrote: imo - documenting existing practice is not the same thing as “rubber stamping” Perhaps my messages were unclear. I'm not opposed to *documenting* existing practices. I'm opposed to *endorsing* existing practices. Especially where those practices are insecure. There is every reason for the spec to say "A, B, and C are OK if you hold your nose. D, E, and F are right out." But that suggestion is apparently controversial. The reasons given are "existing practices". Which sounds to me like there's a requirement for a "rubber stamp" approval of existing implementations > Let me be clear: if the protocol and existing implementations allow for unauthenticated, insecure, remote access to a root shell... then the spec SHOULD say "OMG that's a terrible idea, don't do that. Yes, I know everyone's done that for 20 years. It's bad. Really, really, bad. Don't do it. Honestly, bad things will happen." That's largely where we are today with TACACS+: a) we document existing practices and implementations, no matter how insecure [1] or b) we describe the protocol, along with recommendations for how best to secure it I choose (b). There is non-trivial support for (a). It's not clear to me why this position is in any way controversial, or misunderstood. Could it be that we misunderstood each other as to what b) pertains to? a) is obviously wrong as we certainly don't have to stop at documenting current practices or even care about current practices if they result in an insecure deployment. For b) I don't find it controversial as long as we can agree that "implementation" means "how clients and servers implement documented protocol" and not "how do operators deploy clients and servers". I.e. "implementation" and "practice" refer to two different things. Then we can comb for ambiguous statements like "server MUST implement CHAP in exclusion to PAP" and reword them to say "operators MUST use servers and clients configured to disallow authentication methods other that CHAP". Andrej. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Action Items on TACACS+ informational draft v 10
Hi, I believe the MUST/SHOULD debate pertains only to the recommendations section, the rest of the documents sticks to description of current status apart from the documented deprecations that no sensible implementation would do today, i.e. a few deletions but no updates. The discussion focusses specifically the MUSTs for implementations. Now there is not much point in making recommendations for the past (i.e. implementations that are actually already in the field), so I think that it is implicit that the recommendations are for new implementations and upgrades. I believe the discussion sums to: if we add a note to make this explicit, then it should be clear for all. What is more, if we mark the deltas then we may actually be providing a useful service for implementers of current products: we can explicitly point out where we believe the implementations which strictly follow previous draft should be enhanced. For example: Deployment Best Practices In view of the observations about the security issues described above, a network administrator MUST NOT rely on the obfuscation of the TACACS+ protocol and TACACS+ MUST be deployed over networks which ensure privacy and integrity of the communication. TACACS+ MUST be used within a secure deployment. Failure to do so may impact overall network security. The recommendations for TACACS+ Server and client implementations below are intended to guide new implementations and upgrades to current implementations. Some of these recommendations are stricter than previous guidance, these will be marked [*] so that implementers of current can see where this WG recommends that improvements should be made to enhance security. … On 10/07/2018, 4:56, "Alan DeKok" wrote: On Jul 9, 2018, at 9:17 PM, Scott O. Bradner wrote: > imo - documenting existing practice is not the same thing as “rubber stamping” Perhaps my messages were unclear. I'm not opposed to *documenting* existing practices. I'm opposed to *endorsing* existing practices. Especially where those practices are insecure. There is every reason for the spec to say "A, B, and C are OK if you hold your nose. D, E, and F are right out." But that suggestion is apparently controversial. The reasons given are "existing practices". Which sounds to me like there's a requirement for a "rubber stamp" approval of existing implementations. Let me be clear: if the protocol and existing implementations allow for unauthenticated, insecure, remote access to a root shell... then the spec SHOULD say "OMG that's a terrible idea, don't do that. Yes, I know everyone's done that for 20 years. It's bad. Really, really, bad. Don't do it. Honestly, bad things will happen." That's largely where we are today with TACACS+: a) we document existing practices and implementations, no matter how insecure [1] or b) we describe the protocol, along with recommendations for how best to secure it I choose (b). There is non-trivial support for (a). It's not clear to me why this position is in any way controversial, or misunderstood. Alan DeKok. [1] Without mentioning pesky issues like "security". I mean, why warn people that bad things can happen? ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Action Items on TACACS+ informational draft v 10
> On Jul 9, 2018, at 9:12 PM, Alan DeKok wrote: > > On Jul 9, 2018, at 5:17 PM, Andrej Ota wrote: >> I think that forbidding some parts with MUST would go against the original >> mandate for this draft which I understood to be documenting what's used and >> specifically not working to do a revision of protocol (which I would love to >> hide behind TLS). > > The IETF is not about rubber-stamping existing implementations or practices. > imo - documenting existing practice is not the same thing as “rubber stamping” Scott ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Action Items on TACACS+ informational draft v 10
On Jul 9, 2018, at 5:17 PM, Andrej Ota wrote: > I think that forbidding some parts with MUST would go against the original > mandate for this draft which I understood to be documenting what's used and > specifically not working to do a revision of protocol (which I would love to > hide behind TLS). The IETF is not about rubber-stamping existing implementations or practices. As a case in point, in 1993, the original RADIUS implementations had provisions for "change user password". That was remove (in *1993*), because it was insecure. I doubt very much that the security requirements have been *relaxed* in the subsequent 25 years. > The problem with the protocol as it's implemented today is that it's "unsafe > at any speed". There is nothing that either servers or clients can do to > change that on a protocol level. The only sensible normative text would be > MUST NOT implement. This in my mind shifts the focus from implementation > constraints to operational requirements. I disagree. There are portions of the protocol which are vaguely "OK", such as insecured names/passwords being sent in the clear over a management network. Ugly, but somewhat acceptable. There are portions of the protocol which *no one* would agree is a good idea today. e.g. sending secrets to a client. That's just... bad. > If we there isn't even one sensible implementation band aid (and I certainly > don't see one), we can only apply deployment band aids. There are many sensible implementation suggestions. > Net sum of both is that the document veered away from normative and into > realm of "here are the facts about insecurity of the protocol, use your best > judgement when deploying". > > We can certainly turn the draft back into more normative but I don't think > that we can do anything to the protocol itself that would salvage it in any > useful form whatsoever. The point (again) is that we should document the protocol, *and* recommended best practices. If you don't think that the protocol is salvageable at all, then please withdraw the draft. If you think we *can* document best practices, then we should do so. If you think documenting best practices isn't productive, then you will get roundly trounced when all of the non-TACACS+ people read it, and go "OMFG you can't *do* this in 2018." Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Action Items on TACACS+ informational draft v 10
> On 9 Jul 2018, at 22:02, Alan DeKok wrote: > > On Jul 9, 2018, at 4:54 PM, Joe Clarke wrote: >> Broadly, given that we want an informational draft that describes the >> protocol as it is implemented today, I feel there should be a balance >> struck with respect to normative language so that we don't make existing >> clients "out of spec." > > It's an informational draft, so from a bureaucratic point of view, it > doesn't really define a standard. > > That being said, the spec should require that implementations be as secure > as possible given the protocol limits. If this means forbidding things that > are widely used... well... that's progress. I think that forbidding some parts with MUST would go against the original mandate for this draft which I understood to be documenting what's used and specifically not working to do a revision of protocol (which I would love to hide behind TLS). Would using SHOULD work or do you think that would make the language too weak ... induce lack of any kind of progress. > If the spec is as strong as possible, then implementors will still be free > to ignore it. Just as they ignore the specs for most other protocols. :( > But users of those implementations can ask pointed questions of "Why are you > shipping me something that is insecure by design?" The problem with the protocol as it's implemented today is that it's "unsafe at any speed". There is nothing that either servers or clients can do to change that on a protocol level. The only sensible normative text would be MUST NOT implement. This in my mind shifts the focus from implementation constraints to operational requirements. If we there isn't even one sensible implementation band aid (and I certainly don't see one), we can only apply deployment band aids. Net sum of both is that the document veered away from normative and into realm of "here are the facts about insecurity of the protocol, use your best judgement when deploying". We can certainly turn the draft back into more normative but I don't think that we can do anything to the protocol itself that would salvage it in any useful form whatsoever. Andrej Ota. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Action Items on TACACS+ informational draft v 10
On Jul 9, 2018, at 4:54 PM, Joe Clarke wrote: > Broadly, given that we want an informational draft that describes the > protocol as it is implemented today, I feel there should be a balance > struck with respect to normative language so that we don't make existing > clients "out of spec." It's an informational draft, so from a bureaucratic point of view, it doesn't really define a standard. That being said, the spec should require that implementations be as secure as possible given the protocol limits. If this means forbidding things that are widely used... well... that's progress. If the spec is as strong as possible, then implementors will still be free to ignore it. Just as they ignore the specs for most other protocols. :( But users of those implementations can ask pointed questions of "Why are you shipping me something that is insecure by design?" Which is a Good Thing. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Action Items on TACACS+ informational draft v 10
On 6/28/18 18:16, Alan DeKok wrote: > >> On Jun 28, 2018, at 3:00 PM, Joe Clarke >> wrote: >> >> I would ask that people like Alan (that have been very vocal) make sure >> that any points have been addressed and if specific changes require more >> thorough explanation. > > I would prefer that the document approach publication quality before doing > significantly more work. > > Despite many, many, reviews and both editorial and technical feedback, the > new text in the document isn't much better than text from 3 years ago. It's > still vague, not prescriptive, doesn't use normative text, etc. > > I've done do a quick check recently, and there are still major issues with > the document. So there isn't much point in doing more detailed reviews. > Having done that lots, I'm disinclined to do it again. Thanks, Alan. I do want it to get closer to publication quality, and now that the authors are engaging more actively, I want the WG to help them get there. Specific to the normative language, I have a few questions here, especially with the security concerns. I'll comment on Douglas' email, and I would appreciate your input on my comments. Broadly, given that we want an informational draft that describes the protocol as it is implemented today, I feel there should be a balance struck with respect to normative language so that we don't make existing clients "out of spec." Joe > ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Action Items on TACACS+ informational draft v 10
> On Jun 28, 2018, at 3:00 PM, Joe Clarke > wrote: > > I would ask that people like Alan (that have been very vocal) make sure > that any points have been addressed and if specific changes require more > thorough explanation. I would prefer that the document approach publication quality before doing significantly more work. Despite many, many, reviews and both editorial and technical feedback, the new text in the document isn't much better than text from 3 years ago. It's still vague, not prescriptive, doesn't use normative text, etc. I've done do a quick check recently, and there are still major issues with the document. So there isn't much point in doing more detailed reviews. Having done that lots, I'm disinclined to do it again. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Action Items on TACACS+ informational draft v 10
On 6/28/18 01:49, Douglas Gash (dcmgash) wrote: > Hi Joe, > > We will update on 1) by end of the week. Thanks. > 2) Was sent previously, any feedback on it welcome. Yes you did! I read through it and had thought I replied at the time. I appreciate the summary effort. Given that this was a look back at changes, trying to thread that into mailing list discussions would be difficult. Some of those discussions were happening before I joined as co-chair. I would ask that people like Alan (that have been very vocal) make sure that any points have been addressed and if specific changes require more thorough explanation. > 3) I will send out initial proposal today to the list. I saw that. I'll read it over. Joe > > Thanks, > > Doug. > > On 27/06/2018, 16:13, "Joe Clarke" wrote: > > On 6/10/18 04:43, Douglas Gash (dcmgash) wrote: > > Dear Opsawg, > > > > A status update on informational T+ Draft: > > > > 1) Current discussion between Andrej and (mainly) Joe Clarke on some > section 9 (Security), ongoing, Andrej/Authors will respond to Joe’s latest > comments shortly. > > 2) Diffs between Version 6 and Version 10 with brief annotations of > each diff sent to Newsgroup > > 3) Authors Recently reviewed section 9 (Security), and reflect that it > includes some redundant and overlapping content in the sections: > > “9.5. TACACS+ Client Implementation Recommendations . . . . . . 39 > > 9.6. TACACS+ Server Implementation Recommendations . . . . . . 39 > > 9.7. TACACS+ Deployment Best Practices . . . . . . . . . . . . 40” > > …consequently, we are planning to propose rationalised single section > to cover Best Practices. We will present a proposal this week for initiating > discussion, the result of which we will look to include in next version. > > Hello, T+ authors. What is the status of this work? It's now been two > weeks since you sent this (and a month between this and the previous > email). > > For this work to progress, we need much more frequent engagement. To > that end, can one of you present the status of the work and your plan to > move towards ratification in Montreal? > > Thanks. > > Joe > > > ___ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Action Items on TACACS+ informational draft v 10
On 6/10/18 04:43, Douglas Gash (dcmgash) wrote: > Dear Opsawg, > > A status update on informational T+ Draft: > > 1) Current discussion between Andrej and (mainly) Joe Clarke on some section > 9 (Security), ongoing, Andrej/Authors will respond to Joe’s latest comments > shortly. > 2) Diffs between Version 6 and Version 10 with brief annotations of each diff > sent to Newsgroup > 3) Authors Recently reviewed section 9 (Security), and reflect that it > includes some redundant and overlapping content in the sections: > “9.5. TACACS+ Client Implementation Recommendations . . . . . . 39 > 9.6. TACACS+ Server Implementation Recommendations . . . . . . 39 > 9.7. TACACS+ Deployment Best Practices . . . . . . . . . . . . 40” > …consequently, we are planning to propose rationalised single section to > cover Best Practices. We will present a proposal this week for initiating > discussion, the result of which we will look to include in next version. Hello, T+ authors. What is the status of this work? It's now been two weeks since you sent this (and a month between this and the previous email). For this work to progress, we need much more frequent engagement. To that end, can one of you present the status of the work and your plan to move towards ratification in Montreal? Thanks. Joe ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Action Items on TACACS+ informational draft v 10
Dear Opsawg, A status update on informational T+ Draft: 1) Current discussion between Andrej and (mainly) Joe Clarke on some section 9 (Security), ongoing, Andrej/Authors will respond to Joe’s latest comments shortly. 2) Diffs between Version 6 and Version 10 with brief annotations of each diff sent to Newsgroup 3) Authors Recently reviewed section 9 (Security), and reflect that it includes some redundant and overlapping content in the sections: “9.5. TACACS+ Client Implementation Recommendations . . . . . . 39 9.6. TACACS+ Server Implementation Recommendations . . . . . . 39 9.7. TACACS+ Deployment Best Practices . . . . . . . . . . . . 40” …consequently, we are planning to propose rationalised single section to cover Best Practices. We will present a proposal this week for initiating discussion, the result of which we will look to include in next version. Thanks, Regards, authors. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
