Re: [OPSAWG] Start of WGLC for TACACS+ document.
"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Thu, 06 October 2016 18:00 UTC
Return-Path: <prvs=90870a1fdb=uri@ll.mit.edu>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F0012973D for <opsawg@ietfa.amsl.com>; Thu, 6 Oct 2016 11:00:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.193
X-Spam-Level:
X-Spam-Status: No, score=-7.193 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8r587hmszGvF for <opsawg@ietfa.amsl.com>; Thu, 6 Oct 2016 11:00:24 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id D744A12967C for <OpsAWG@ietf.org>; Thu, 6 Oct 2016 11:00:23 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u96HtpNp033941; Thu, 6 Oct 2016 13:55:57 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: "Douglas Gash (dcmgash)" <dcmgash@cisco.com>, Alan DeKok <aland@deployingradius.com>, "t.petch" <ietfc@btconnect.com>
Thread-Topic: [OPSAWG] Start of WGLC for TACACS+ document.
Thread-Index: AQHSHbl7hTNUTbboskaNjFefNq8+s6CaTxAAgABN8oCAAJkY1IAAhHQA///lekiAAEbgAIAAEJCA///EBQA=
Date: Thu, 06 Oct 2016 18:00:07 +0000
Message-ID: <9AF97FE8-6D33-4445-B011-FB86FEF9F63C@ll.mit.edu>
References: <CAHw9_iK-1=Epr5CLAtFayd0Bss6oZrsDTfyox6y2SfPJAav78Q@mail.gmail.com> <5019ABA9-BB74-4C69-A455-12C17A2958CE@deployingradius.com> <E6C64895-F0C6-40B8-A687-4DC56590B22E@deployingradius.com> <025401d21fb8$71906e20$4001a8c0@gateway.2wire.net> <2769B0A9-00DE-41F8-9971-9C0AABDC8109@deployingradius.com> <003101d21fed$6978cb80$4001a8c0@gateway.2wire.net> <0124D7D3-98BA-4175-AE57-39C03349009C@deployingradius.com> <D41C42F2.195352%dcmgash@cisco.com>
In-Reply-To: <D41C42F2.195352%dcmgash@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1a.1.160916
x-originating-ip: [172.25.177.81]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha384"; boundary="B_3558607206_402865024"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-06_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610060313
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/iv8iIcYw4qfySFoHhNcaaOJeA0Y>
Cc: "opsawg@ietf.org" <OpsAWG@ietf.org>, "draft-ietf-opsawg-tacacs-05@tools.ietf.org" <draft-ietf-opsawg-tacacs-05@tools.ietf.org>
Subject: Re: [OPSAWG] Start of WGLC for TACACS+ document.
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Oct 2016 18:00:28 -0000
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 vulnerabilities and exploration of the attack vectors would help, especially if you provide ways to defend/mitigate. If you just say “when you deploy X, anybody would be able to do Y and totally screw you up”, somehow I doubt that such a protocol would be warmly welcomed. If you don’t say anything – it simply shows that you did not think of the security angle, and therefore the protocol is not ready even for the draft publication. Why do you think anyone at SAAG would agree/permit to “bless”/publish a protocol that “does not provide security in a modern Environment”? I’d think that everybody realized by now that in today’s environment a protocol that “provides the function, not the security” has no right to live, and ideally should be stamped out – but in any case not rewarded by receiving a “standard” status. So hold the publication until your (3) comes along. In the meanwhile, enjoy the vulnerabilities of your deployed implementations. -- Regards, Uri Blumenthal On 10/6/16, 13:34 , "OPSAWG on behalf of Douglas Gash (dcmgash)" <opsawg-bounces@ietf.org on behalf of dcmgash@cisco.com> wrote: 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 security is to follow, which will not require the mitigations in 2) (actually I suspect it may precede the info document ;-)) We need to make sure there is no ambiguity for 1) for any security review. No soft-peddalling. T+ provides the function, not the security. SoŠ An approach we could employ is to enumerate all the ways in which 1) is true, including an analysis of each of the other components of the rest of the protocol, and their contribution to 1). My question would be: would this dissection of vulnerabilities and exploration of the attack vectors would help anyone from a security perspective, when we have established that the approaches 2) are required? I suspect that we¹d probably miss some, and that may give implementors more comfort than is afforded by the clear and simple statement. Therefore, for security review, I¹d suggest we keep the statement simple, as defined above. However, if this statement is not clear enough/correct in the document, then certainly, it should be clarified. Best Regards, Doug. On 06/10/2016 17:35, "Alan DeKok" <aland@deployingradius.com> wrote: On Oct 6, 2016, at 12:19 PM, t.petch <ietfc@btconnect.com> 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 content to leave it as is for an Informational RFC which documents what is, or perhaps what has been. You used the word 'philosophical' and I agreed. I see the existing draft as not documenting the protocol. That's my main concern. So I would keep changes to the minimum, omissions or contradictions and those required by the publication process (such as splitting References into Informative and Normative). It is, after all, WGLC. This doesn't address my concerns. Again, as an implementor, I have *no idea* what to do for huge swathes of the protocol. On top of that, the current draft is silent on serious security topics. e.g. Length of CHAP challenges is implied from the context. OK, that's fine, but what are the *limits* on CHAP challenge lengths? A: none. CHAP challenges can be omitted entirely! On Security, I would invite the chairs to ask for an early review by the Security Directorate, explaining the context of this document, asking them how much more is needed and how it should be expressed. It might not be very much although my experience is that I never know in advance what they are going to come up with. I've been a member of SAAG for a while now, and have done reviews, and read many more. My prediction is that the current document will give SAAG a heart attack, and they will refuse publication. There is a huge push to get the draft published. That's fine. What's *not* fine is that it seems to me at least... that many people simply don't care what's in the document. They don't care if the protocol is badly specified. Or if it's insecure. In fact, these "features" could be beneficial. Because it means that everyone can claim compliance. And no one has to re-examine their implementation. That may sound harsh, but I just don't see any other explanation. If we are going to document the protocol, then let's document the protocol. If we're going to agree that we don't need to document the protocol then put a huge disclaimer at the top of the draft saying so. Giving lip service to "document the protocol", while opposing attempts to do so is unproductive. Alan DeKok. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
- [OPSAWG] Start of WGLC for TACACS+ document. Warren Kumari
- Re: [OPSAWG] Start of WGLC for TACACS+ document. Alan DeKok
- Re: [OPSAWG] Start of WGLC for TACACS+ document. Alan DeKok
- Re: [OPSAWG] Start of WGLC for TACACS+ document. t.petch
- Re: [OPSAWG] Start of WGLC for TACACS+ document. Alan DeKok
- Re: [OPSAWG] Start of WGLC for TACACS+ document. Douglas Gash (dcmgash)
- Re: [OPSAWG] Start of WGLC for TACACS+ document. t.petch
- Re: [OPSAWG] Start of WGLC for TACACS+ document. Alan DeKok
- Re: [OPSAWG] Start of WGLC for TACACS+ document. Douglas Gash (dcmgash)
- Re: [OPSAWG] Start of WGLC for TACACS+ document. Blumenthal, Uri - 0553 - MITLL
- Re: [OPSAWG] Start of WGLC for TACACS+ document. Douglas Gash (dcmgash)
- Re: [OPSAWG] Start of WGLC for TACACS+ document. Alan DeKok
- Re: [OPSAWG] Start of WGLC for TACACS+ document. Dan Romascanu
- Re: [OPSAWG] Start of WGLC for TACACS+ document. Randy Bush
- Re: [OPSAWG] Start of WGLC for TACACS+ document. Alan DeKok
- Re: [OPSAWG] Start of WGLC for TACACS+ document. Alan DeKok
- Re: [OPSAWG] Start of WGLC for TACACS+ document. Alan DeKok
- Re: [OPSAWG] Start of WGLC for TACACS+ document. Douglas Gash (dcmgash)