From kathleen.moriarty@emc.com Thu Feb 2 16:57:11 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7800A21F86B7 for ; Thu, 2 Feb 2012 16:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.825 X-Spam-Level: X-Spam-Status: No, score=-9.825 tagged_above=-999 required=5 tests=[AWL=0.774, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHOCDc-JnHwj for ; Thu, 2 Feb 2012 16:57:10 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8B53821F86B4 for ; Thu, 2 Feb 2012 16:57:10 -0800 (PST) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q130v4JR026355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Feb 2012 19:57:08 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Thu, 2 Feb 2012 19:56:48 -0500 Received: from mxhub27.corp.emc.com (mxhub27.corp.emc.com [10.254.110.183]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q130ul1Y003732; Thu, 2 Feb 2012 19:56:47 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub27.corp.emc.com ([10.254.110.183]) with mapi; Thu, 2 Feb 2012 19:56:47 -0500 From: To: Date: Thu, 2 Feb 2012 19:56:39 -0500 Thread-Topic: review of draft-ietf-nea-pt-eap-00.txt Thread-Index: AcziDrAE1hU3CovTTaa6IG1T1kr34g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Kn4= FmM8 Jbx1 Ju5E KcUO KfvC KpYK MaOO SzJD XcEs X5to Y2aA aJqc aXVW cR3P d2IN; 3; bgBjAGEAbQB3AGkAbgBnAEAAYwBpAHMAYwBvAC4AYwBvAG0AOwBuAGUAYQBAAGkAZQB0AGYALgBvAHIAZwA7AHAAYQB1AGwAXwBzAGEAbgBnAHMAdABlAHIAQABzAHkAbQBhAG4AdABlAGMALgBjAG8AbQA=; Sosha1_v1; 7; {9DB5D341-6BE6-49D8-A7D3-CA5245F098C9}; awBhAHQAaABsAGUAZQBuAC4AbQBvAHIAaQBhAHIAdAB5AEAAZQBtAGMALgBjAG8AbQA=; Fri, 03 Feb 2012 00:56:39 GMT; cgBlAHYAaQBlAHcAIABvAGYAIABkAHIAYQBmAHQALQBpAGUAdABmAC0AbgBlAGEALQBwAHQALQBlAGEAcAAtADAAMAAuAHQAeAB0AA== x-cr-puzzleid: {9DB5D341-6BE6-49D8-A7D3-CA5245F098C9} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [Nea] review of draft-ietf-nea-pt-eap-00.txt X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 00:57:11 -0000 Hello Nancy and Paul, I volunteered to review the draft for the working group. The document look= s very good. A number of my comments are nits and some are areas in which = the document can benefit from additional specificity. Here are my comments= : Section 3.1, could you include a diagram? I think that will help the reade= r to see the flow on first read. The text reads well, but not being famili= ar with the draft, I had to read it twice to make sure I had the background= to continue reading. It would be useful to reference while reading sectio= n 3.2 as well. Section 3.3: Just a suggestion to reword the first paragraph: In most cases, EAP-TNC fragmentation will not be required. However, PB-TNC batches can be very long and EAP message length is sometimes tightly constrained. As a result, EAP-TNC includes a fragmentation mechanism to= be used when a particular PB-TNC batch is too long to fit into a single EAP- TNC message. Section 3.3: It would be helpful to distinguish the differences from the re= ferenced specifications so that a developer knows where this specification = differs. "The fragmentation mechanism used in EAP-TNC is quite similar to the mechanism used by EAP-TLS [17], EAP-TTLS [14], and EAP-FAST [12]. It uses the L flag (length included) and the M flag (more fragments) as well as the Data Length field." In the following paragraphs, including the references to the appropriate sp= ec where there is a match and then pointing out the difference could be use= ful. Section 3.3: Is there a reference that can be included to where one can fin= d the 'variety of reasons' in the last paragraph? "However, a NEA Server or peer still MAY decide to terminate an EAP-TNC exchange at any time for a variety of reasons." Section 3.4: Type, I had the word please in a draft :) and someone recommen= ded pulling it out and just directly making the request. You may want to d= o the same here. Section 3.4 Data Length: Recommend adding a comma in the first sentence and= removing two in the second: Data Length is an optional field, four octets in length. When present, it indicates the total length before fragmentation of a fragmented PB-TNC batch. Section 3.5: Should 'SHOULD' be 'MUST' in the following sentence to protec= t against the attack? If this is not required of the protocol, then I sugg= est using non RFC2119 language, something like the following: To protect against NEA Asokan attacks, it is necessary for the Posture Brok= er on an EMA- equipped endpoint to pass the tls-unique channel binding [18] for PT-EAP's tunnel method to the EMA. I think the following sentence should be broken into two as follows (left i= n the page information so you can find it): This value can then be included Sangster et al. Expires February 30, 2012 [Page 10] Internet-Draft PT-EAP August 2011 in the EMA's attestation and the Posture Validator responsible for communicating with the EMA. The EMA may then confirm that the value mat= ches the tls-unique channel binding for its end of the tunnel. Can you reword the following sentence (next one in this section)? It is a = little tough for me to follow: "If the values match and the integrity of the endpoint is good, the posture sent by the EMA and NEA Client is from the same endpoint as the client side of the TLS connection (since the endpoint knows the tls- unique value) so no man-in-the-middle is forwarding posture." Security Considerations: Could you reference the documents where the securi= ty requirements exist. I like that the introduction to this section clearl= y states that these are recommendations and not the requirements, but want = o be sure the requirements are directly referenced. In section 4.2.1, RFC2119 terms are used, this means they are requirements.= Is that the case? If so, you may want to have a Security Requirements se= ction prior to your Security Considerations Section and include items like = these. It is starting to become a trend in drafts so that security require= ments are not ignored by developers. This particular statement is high-lev= el, so you may want to change it to use language not defined in RFC2119, bu= t clearly point to the specification that provides the details of how the a= uthentication and other security features are provided in the introduction. Section 4.2.2, Consider breaking the last sentence into multiple sentences. Section 4.2.5 also contains an RFC2119 term. This is fine, just point it o= ut as you decide how to handle considerations versus requirements with the = current introductory remarks. Same for 4.3: This includes a set of requirements nested inside a section t= hat says it is not requirements. Section 4.3: I think you need to be more specific and provide references to= the acceptable authentication options to have interoperability between imp= lementations. Section 4.4: I like seeing the reference to TLS, can you also include the r= eferences to EAP-FAST and EAP-TLS here so the reader has links to the RFCs = when the document is published? It could help them figure out things like = the necessary version of TLS to support, etc. I realize this is already re= ferenced higher in the document, so it is just to be helpful to the reader/= developer. Section 4.4: Last paragraph, this goes into authentication, but doesn't pro= vide a reference to the appropriate specs to follow either. Section 4.5: It may only be me, but I had to read the introductory sentenc= e a couple of times to get the context - to make sure I had it right. Can = you add 'for this specification' or something like that to the sentence? Section 6: I think you can make a direct statement requesting registration = of the value. This text will live on in the document after the value is as= signed. Maybe ask IANA, but in the draft make it more direct - Registers v= alue 38... Section 6.1 looks good - I just finished similar IANA requests. I am just in the NEA-digest list, so if you would like me to see it right a= way, you may want to copy me directly. Thank you, Kathleen From latze@angry-red-pla.net Fri Feb 3 08:43:03 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398FB21F849A for ; Fri, 3 Feb 2012 08:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIXpoW8dOp21 for ; Fri, 3 Feb 2012 08:43:02 -0800 (PST) Received: from thuvia.angry-red-pla.net (thuvia.angry-red-pla.net [83.169.33.217]) by ietfa.amsl.com (Postfix) with ESMTP id 2D91421F8497 for ; Fri, 3 Feb 2012 08:43:01 -0800 (PST) Received: from 110-229.194-178.cust.bluewin.ch ([178.194.229.110] helo=[192.168.1.178]) by thuvia.angry-red-pla.net with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RtMDz-0005It-7U for nea@ietf.org; Fri, 03 Feb 2012 17:42:59 +0100 Message-ID: <4F2C0E92.80106@angry-red-pla.net> Date: Fri, 03 Feb 2012 17:42:58 +0100 From: Carolin Latze User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11 MIME-Version: 1.0 To: nea@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Nea] NEA WG Next Steps: Call for Comments on PT-EAP I-D X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 16:43:03 -0000 Hi all, I have a few comments: Section 3.2 - "The NEA Client SHOULD choose the value sent by the NEA Server if the NEA Client supports it. However, the NEA Client MAY set the Version field to a value less than the value sent by the NEA Server" -> does this mean, the client is allowed to choose an older version even he supports the same version like the server. Wouldn't it be better to require the client to use the version the server requested if he supports it and only allow to use older versions if the client does not support the server's version? Section 4.2.1 2n paragraph: "In order to protect again NEA assessment message theft" -> against Section 4.3 5th paragraph: "Whether the communication channel is established with both or one party performing a cryptographic authentication, the resulting channel needs to provide strong integrity and confidentiality protection to its contents. These protections are to be bound to at least the authentication of the NEA Client, so the session is cryptographically bound to a particular authentication event." -> ok this can be my bad English, but I thought it is bound to at least the authentication of the NEA _server_, not the client since most of the tunnel protocols authenticate the server only. Did I just misunderstand this paragraph? Section 4.4 4th paragraph: "Each of these methods employs at least a NEA Server authentication using an X.509 certificates" -> certificate (= only one) Regards Carolin On 01/26/2012 09:56 PM, Susan Thomson wrote: > Hi all > > There has been good feedback on the PT-TLS I-D - thank you! The plan is for > the editors to update the I-D based on comments received and post the > revision to the list within a few weeks. The goal is to do a 2nd WGLC prior > to the next IETF. > > In contrast, we have not received much feedback on the PT-EAP I-D. Please > review the document (http://tools.ietf.org/id/draft-ietf-nea-pt-eap-00.txt) > and send your comments to the mailing list by Friday, February 10, 2012. > This will allow time to revise the document and to issue a WGLC on the > document prior to the next meeting. > > Thanks very much to those who have posted comments on the PT-TLS I-D, and we > look forward to the same level of feedback on the PT-EAP I-D. > > Thanks > Susan > > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea > From jsalowey@cisco.com Thu Feb 9 20:45:11 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB1721F85E0 for ; Thu, 9 Feb 2012 20:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GR935gEHY99 for ; Thu, 9 Feb 2012 20:45:10 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id F35F021F8566 for ; Thu, 9 Feb 2012 20:45:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=12351; q=dns/txt; s=iport; t=1328849110; x=1330058710; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=tCU2D6q+Z9AP3lrA6SX0EBkJkfFVb6942Q3+esVirbc=; b=OF9MyXBTrjWPTtITbHgSKuLUXAmFbggLHWvSfWzvwH7fJGh+mHiibD4U Felah/qyfKAXUSVh7SZIz5zwGgzL5jwZ2SsvZOWSuCWEIatmEuwKtB6np eK48u52xHEUMRE1cZcshBAHagDOEyGlw42l5/UiJ1QsCAsU6cMvzVcwtE g=; X-IronPort-AV: E=Sophos;i="4.73,394,1325462400"; d="scan'208";a="29505666" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 10 Feb 2012 04:45:09 +0000 Received: from [10.33.251.13] ([10.33.251.13]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1A4j5mm003012; Fri, 10 Feb 2012 04:45:06 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: <4F181A8B.6000504@isode.com> Date: Thu, 9 Feb 2012 20:45:35 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4ECCD076.7080003@isode.com> <4F181A8B.6000504@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1084) Cc: nea@ietf.org Subject: Re: [Nea] Review of PT-TLS draft X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 04:45:11 -0000 >=20 >>> I found this text to be unclear. >>>=20 >>> This phase >>> also enables the establishment of the tls-unique shared secret = that >>> can be used in a later phase to bind the posture sent with this = TLS >>> connection. >>>=20 >> [Joe] How About >>=20 >> "This phase also includes the establishment of the tls-unique shared = secret. The tls-unique shared secret can later be used by PA to protect = again some forms of man-in-the-middle attack." > Ok. tls-unique is the channel binding data here, right? [Joe] yes. =20 >>=20 >>> 3.8.2. SASL in PT-TLS Overview >>>=20 >>> Mechanism negotiation is performed using the Request SASL = Mechanisms >>> and SASL Mechanisms TLVs. The PT-TLS Initiator sends a Request = SASL >>> Mechanisms TLV to request a preference-ordered list of SASL >>>=20 >>> I think you should drop "preference-ordered" here: each SASL client = should have >>> its own policy regarding preference order and such policy is likely = to be different from >>> the server's policy. The client shouldn't be trusting server on = this. >>>=20 >> [Joe] The preference-ordered represents the preferences of the = message sender. The PTC may have policy the guides its selection of = mechanism. This section is likely to be re-written based on other = comments >> discussed at the IETF meeting. Is there an issue with the PTS = sending a list of SASL mechanisms ordered in the PTS's preferred order? > It is dangerous on the client side. For example if the server lists = less secure mechanisms first for some reason. >> The PTC is free to select the mechanism it finds acceptable based = on its local policy. Ideally this would result in the PTC using the = first acceptable SASL mechanism proposed by the PTS (but this is a = policy issue). > I think the client should disregard server preferences. If the server = advertises multiple mechanisms, it should be prepared for the client to = use any of them. [Joe] Makes sense to me.=20 >>> mechanisms that the PT-TLS Responder is willing to use for this >>> session. The PT-TLS Initiator selects one SASL mechanism from = the >>> list and sends a SASL Mechanism Selection TLV completing the >>> negotiation. Subsequent challenges and responses are carried = within >>> the SASL Authentication Data TLV carrying the authentication data = for >>> the selected mechanism. The authentication outcome is = communicated >>> in a SASL Result TLV containing a status code. If additional >>> authentications are required, the PT-TLS Responder could trigger = the >>> next authentication by sending another SASL Mechanisms TLV after >>> sending the SASL Result TLV for the current authentication = mechanism. >>>=20 >>>=20 >>> 3.8.4. SASL Authentication Flow >>>=20 >>> If an authentication is required by the PT-TLS Responder and >>> not requested by the PT-TLS Initiator, the PT-TLS Responder >>> (typically the NEA Server) SHOULD initiate the entity >>> authentication exchange by sending a SASL Mechanisms TLV. If >>> the PT-TLS Responder receives a NEA assessment message before >>> the completion of any required entity authentication, the PT- >>> TLS Responder MUST send an Authentication Required PT-TLS Error >>> indicating to the PT-TLS Initiator that an authentication >>> exchange is required prior to entering the PT-TLS Data >>> Transport phase. The SASL Mechanisms TLV includes a >>> preference-ordered list of the SASL mechanisms that the PT-TLS >>>=20 >>> As above: drop "preference-ordered". >>>=20 >>> Responder is willing to use and allows for the selection of one >>> by the PT-TLS Initiator for use with this session. >>>=20 >>>=20 >>>=20 >>> Your SASL profile doesn't seem to support "additional data with = success" >>> feature of SASL (which can save a round trip). I suggest you say so = explicitly. >>> Or alternatively you can update the message reporting outcome of a = SASL >>> authentication exchange to include this information. >>>=20 >> [Joe] Not sure I follow. We do support carrying "Optional Result = Data" along with a successful SASL authentication in the SASL Result = message. > I probably didn't find it because it is named differently. Can you = rename the field (to match SASL terminology) or just clarify that the = field can be used for this purpose? [Joe] Yes >>=20 >>>=20 >>> 3.8.6.3. SASL Security Layer >>>=20 >>> The NEA PT-TLS protocol always runs under the protection of TLS. >>> SASL security layers are not used. >>>=20 >>> Add "and thus MUST be negotiated off during SASL authentication" to >>> the end of this sentence. SASL security layers are negotiated during >>> authentication using SASL mechanisms that support security layers. >>>=20 >> [Joe] OK >>=20 >>> 3.8.6.4. Multiple Authentications >>>=20 >>> Only one SASL mechanism authentication may be in progress at any = one >>> time. Once a SASL mechanism completes (successfully or >>> unsuccessfully) a new authentication may be initiated. >>>=20 >>> I think you need to talk somewhere that this profile of SASL >>> doesn't support reauthentication (i.e. authentication as another = user, >>> after an earlier successful authentication) like LDAP does. >>> Instead PT-TLS is supporting "multiple cumulative authentications" >>> (I needed to invent a new term). >>>=20 >> [Joe] So in LDAP does it specify that a subsequent authentication = replaces the state of the previous one? > Yes. In other protocols this is just disallowed. >> I think with NEA this may be up to server policy. >>=20 [Joe] I'd like to hear more from the working group on this. We could = add text that it is up to the server whether to completely reset the = client state on a new authentication or not. I deserves some thought to = make sure we understand any risks we are introducing. =20 >>> 3.8.10. SASL Authentication Data >>>=20 >>> This TLV carries an opaque (to PT-TLS) blob of octets being = exchanged >>> between the PT-TLS Initiator and the PT-TLS Responder. This TLV >>> facilitates their communications without interpreting any of the >>> bytes. The SASL Authentication Data TLV MUST NOT be sent until a >>> SASL mechanism has been established for a session. The SASL >>> Authentication Data TLV MUST NOT be sent after a SASL Result is = sent >>> with a Successful status. >>>=20 >>> The last MUST NOT seem to prevent multiple authentications, which >>> I don't think is the intent. >>>=20 >> [Joe] In order to start another authentication, one repeats the SASL = mechanism selection messages (doesn't send another SASL Authentication = Data TLV right away). We will make this more clear. >>=20 >>> 3.8.11. SASL Result >>>=20 >>> This TLV is sent by the PT-TLS Responder at the conclusion of the >>> SASL exchange to indicate the authentication result. This TLV = may >>> also be sent by the PT-TLS Initiator to indicate a client side >>> failure. The PT-TLS Initiator MUST NOT send other Result-Code = values >>> besides Failure. Upon reception of a SASL Result TLV indicating = an >>> Abort, the recipient MUST terminate the current authentication >>> conversation. The recipient may retry the authentication in the >>> event of an authentication failure. Similarly, the NEA Server = may >>> request additional SASL authentication(s) be performed after the >>> completion of a SASL mechanism by sending another SASL Mechanisms >>> TLV. >>>=20 >>> Can any such subsequent list include authentication mechanisms = already >>> successfully used earlier in the same session? >>>=20 >> [Joe] Yes if dictated by the NEA Server policy. Is this a problem? > No, but it would be worth spelling this out explicitly. [Joe] OK >>> 3.8.11. SASL Result >>>=20 >>> 1 (Failure) SASL authentication failed. This >>> might be caused by the entity >>> providing an invalid user identity >>> and/or credential pair. Note that >>> this is not a mechanism failure to >>> process the authentication. >>>=20 >>> What is the meaning of the last sentence? >>>=20 >> [Joe] The last sentence separates authentication failures from = mechanism internal logic failures. > Ok. I don't think I've seen protocols doing that, but that is not a = problem in itself. [Joe] OK >>=20 >>> If you meant to say that that is different from 3: >>>=20 >>> 3 (Mechanism Failure) SASL mechanism failure during the >>> processing of the entity's >>> authentication (not related to the >>> user's input). >>>=20 >>> then you should say so above (maybe quote "Mechanism Failure"?) >>>=20 >>>=20 >> [Joe] Agree >>=20 >>> s/user's input/authentication mechanism's input >>> (Not all of it is "user's input") >>>=20 >> [Joe] Will make it more clear that was an example >>=20 >>> Additionally, it is not very clear whether this covers any errors = other >>> than "unsupported SASL mechanism name". >>>=20 >>> And finally, can you just use "error message" (Section 3.9) for = reporting >>> SASL authentication errors instead? >>>=20 >>>=20 >>>=20 >>> 3.9. Error Message >>>=20 >>> 4 (Failed Authentication) The authentication of the identity = of >>> the client failed. This could = occur >>> if the SASL mechanism was unable to >>> authenticate the claimed identity = of >>> the PT-TLS Initiator. This error >>> message does not indicate a fatal >>> error has occurred, so the >>> authentication is allowed to be re- >>> started. >>>=20 >>> I am confused, I thought this condition should have resulted in = "SASL result" >>> with Fail status. >>>=20 >> [Joe] This error specifically was intended to mean the authentication = of the user failed due to the claimed identity and credential not be = acceptable (incorrect pair or unauthorized) which is different from = mechanism >> internal logic failures. We need to review that this value is needed = in light of the other ways to report authentication status and will = remove if it's a duplicate. > Ok. >>> 4.2.5. NEA Asokan Attacks >>>=20 >>> Because lying endpoint attacks are much easier than Asokan = attacks >>> and the only known effective countermeasure against lying = endpoint >>> attacks is the use of an External Measurement Agent (EMA), >>> countermeasures against an Asokan attack are not necessary unless = an >>> EMA is in use. However, PT-TLS implementers may not know whether = an >>> EMA will be used with their implementation. Therefore, PT-TLS >>> implementers SHOULD support the Asokan attack countermeasures by >>> providing the value of the tls-unique channel binding to higher >>> layers in the NEA reference model: Posture Broker Clients, = Posture >>> Broker Servers, Posture Collectors, and Posture Validators. >>>=20 >>> Mention SASL here as well (e.g. use of tls-unique with SASL = mechanisms >>> that support channel bindings)? >>>=20 >> [Joe] I'll work on some text to address this. >>=20 >>> 6.1. Designated Expert Guidelines >>>=20 >>> Instead, designated experts should focus on the following >>> requirements. All values in these IANA registries MUST be >>> documented in a specification that is permanently and publicly >>> available. IETF standard values MUST also be useful, not >>>=20 >>> For clarity I would replace "IETF standard values" with "Values >>> defined in Standards Track RFCs". >> [Joe] OK >>=20 >>> harmful to the Internet, and defined in a manner that is clear >>> and likely to ensure interoperability. >>>=20 >=20 From jsalowey@cisco.com Thu Feb 9 21:00:36 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C169121E8015 for ; Thu, 9 Feb 2012 21:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nq-oArKYBJDk for ; Thu, 9 Feb 2012 21:00:36 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9B621E8010 for ; Thu, 9 Feb 2012 21:00:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=937; q=dns/txt; s=iport; t=1328850036; x=1330059636; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=8J6+MjgQbECzaIkD92qjQeYOO2i4Ny6h/ZrCY73uz5s=; b=bb3z6+syfM8w8ELBwNuHue3noJd9xcoDM+23Hs5W8ci2DSL6u4LKQ3J4 0cdAu22HyYeqaZ4uq+vjVNgWioVAieQZZcsQPayrlXpQ2Q9Z4TtwHMs/Y ThHk+D2bZMncYdIM2RQhWYdlnKcKPWyIxANEGQJllmyPUH3RSOY+zahpg I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsHACqkNE+rRDoI/2dsb2JhbABDgw2sU4EHggsBJ4IyoD+BJwGeeot6BQIEBwIHBwsEAQUUAQMPAwODGAUGPX+COmMEiEiMZ4VajSk X-IronPort-AV: E=Sophos;i="4.73,394,1325462400"; d="scan'208";a="29638773" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 10 Feb 2012 05:00:30 +0000 Received: from [10.33.251.13] ([10.33.251.13]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1A50SYD003793 for ; Fri, 10 Feb 2012 05:00:29 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Feb 2012 21:00:57 -0800 Message-Id: To: nea@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Nea] Comments on running PT-EAP outside the tunnel X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 05:00:36 -0000 At the IETF meeting we had some discussion of whether to allow PT-EAP = outside of the protection of a EAP tunnel method. =20 I think PT-EAP should always be run inside the protection of a Tunnel = method. The method itself is insecure and does not provide = authentication without a tunnel method. This would be a large step = backwards in the security of deployments if it is used without the = protection of a tunnel method. =20 Another reason given for allowing PT-EAP to be used without a tunnel is = to proxy the clear test PT-EAP method through a AAA proxy chain. This = is insecure. Standard AAA proxies do not look into the EAP method = attribute, they just proxy it on to the next hop without additional = protection. This will leave the PT-EAP method in the clear. =20 For these reasons the PT-EAP specification should prohibit the use of = PT-EAP outside an EAP tunnel method.=20 Cheers, Joe= From shanna@juniper.net Fri Feb 10 11:25:29 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C563221F8819 for ; Fri, 10 Feb 2012 11:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oW7C8i4Mj3Zq for ; Fri, 10 Feb 2012 11:25:29 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id C1D7D21F8818 for ; Fri, 10 Feb 2012 11:25:28 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTzVvJ5h2PmWMUVXFbVyj44fkfCcv/KGb@postini.com; Fri, 10 Feb 2012 11:25:28 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 10 Feb 2012 11:23:58 -0800 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe01-hq.jnpr.net (172.24.192.59) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 10 Feb 2012 11:23:58 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 10 Feb 2012 14:23:56 -0500 From: Stephen Hanna To: Joe Salowey , "nea@ietf.org" Date: Fri, 10 Feb 2012 14:23:55 -0500 Thread-Topic: [Nea] Comments on running PT-EAP outside the tunnel Thread-Index: AcznsO/AihwXvbZ8S+mzOF6QDKZWLgARnVOA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 Subject: Re: [Nea] Comments on running PT-EAP outside the tunnel X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 19:25:29 -0000 Joe, Thanks for raising this issue again. We have discussed it in the past but I don't think we have reached WG consensus yet. I hope that we can reach WG consensus on it soon! You and I had a thorough discussion of this topic last August on the nea list under the subject "Protecting L2 PT when proxying". People may wish to review that discussion in our archives at http://www.ietf.org/mail-archive/web/nea/current/msg01169.html (and the rest of the messages in the thread). Some things have changed since August (e.g. the selection of PT-EAP as our L2 PT) but most of the discussion is still relevant. I think the current PT-EAP draft reflects the general WG consensus that PT-EAP should run inside an EAP tunnel method. The only remaining question seems to be whether we should permit PT-EAP to be used outside an EAP tunnel method at any time. The current draft does not include a prohibition on such behavior or an equivalent requirement that PT-EAP MUST be always carried in an EAP tunnel method. I believe that you're arguing that we should add such a prohibition or requirement. Stefan Winter emailed the NEA list in late July with a desire to support a proxying use case where authentication and posture checking would be performed on separate servers. This would argue for permitting PT-EAP outside of an EAP tunnel method (maybe with RADSEC). However, Stefan also wanted a standard way to convey the user's identity to the posture checking server. That's not supported by our current design. And Stefan's use case is not in RFC 5209. So my conclusion is that I'm OK with adding a requirement in PT-EAP that PT-EAP MUST always be carried in an EAP tunnel method.=20 Thanks, Steve > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of > Joe Salowey > Sent: Friday, February 10, 2012 12:01 AM > To: nea@ietf.org > Subject: [Nea] Comments on running PT-EAP outside the tunnel >=20 > At the IETF meeting we had some discussion of whether to allow PT-EAP > outside of the protection of a EAP tunnel method. >=20 > I think PT-EAP should always be run inside the protection of a Tunnel > method. The method itself is insecure and does not provide > authentication without a tunnel method. This would be a large step > backwards in the security of deployments if it is used without the > protection of a tunnel method. >=20 > Another reason given for allowing PT-EAP to be used without a tunnel is > to proxy the clear test PT-EAP method through a AAA proxy chain. This > is insecure. Standard AAA proxies do not look into the EAP method > attribute, they just proxy it on to the next hop without additional > protection. This will leave the PT-EAP method in the clear. >=20 > For these reasons the PT-EAP specification should prohibit the use of > PT-EAP outside an EAP tunnel method. >=20 > Cheers, >=20 > Joe > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From sethomso@cisco.com Fri Feb 10 15:04:00 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8BC21F86C1 for ; Fri, 10 Feb 2012 15:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.599 X-Spam-Level: X-Spam-Status: No, score=-108.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsKLeWkwoFRa for ; Fri, 10 Feb 2012 15:03:59 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D317921F86BE for ; Fri, 10 Feb 2012 15:03:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sethomso@cisco.com; l=486; q=dns/txt; s=iport; t=1328915038; x=1330124638; h=date:subject:from:to:message-id:mime-version: content-transfer-encoding; bh=7dCN7lNQlQ9Smdo5TCGWs8lHmGsGf8XR3F0FN0uMfe0=; b=lwQhZBugLH3fqvSv+30KppgSKIa5BPhYr+i/mq+obX6JIBqS/nQqMw6Y RjWz281lncsMqm4KHiuwepPR57f2Hg+zeX33v7rl/wb5ovqC7lWjZ7049 1PIBxqjQvnYnehYcMAaDAZdCWhT/GOw7dPSfHoqv9fghYp+lOIDyv5+gL U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPahNU+tJV2a/2dsb2JhbABEr2+BB4F0AQQSAScCAU4BgSYBBAoroDWBJwGeVIs/Kg8HATUEEAEKCwECAYQyASuDHQSISYxnkwI X-IronPort-AV: E=Sophos;i="4.73,399,1325462400"; d="scan'208";a="58060570" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 10 Feb 2012 23:03:58 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1AN3wl2008377 for ; Fri, 10 Feb 2012 23:03:58 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Feb 2012 17:03:58 -0600 Received: from 10.116.64.103 ([10.116.64.103]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Fri, 10 Feb 2012 23:03:58 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 10 Feb 2012 18:03:57 -0500 From: Susan Thomson To: Message-ID: Thread-Topic: PT-EAP and fragmentation Thread-Index: AczoSERq0pX/+3AUjUO2C4QHZEArjw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 10 Feb 2012 23:03:58.0325 (UTC) FILETIME=[45345A50:01CCE848] Subject: [Nea] PT-EAP and fragmentation X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 23:04:01 -0000 The current PT-EAP spec includes support for fragmentation. I would argue that fragmentation support is unnecessary, given that the underlying EAP tunnel method for PT-EAP also supports fragmentation, which will allow for message sizes up to approx 64K to be sent. The reason is that EAP is not designed for bulk data transfer, and we have an alternate transport for this purpose: PT-TLS. Also, it simplifies implementation and interoperability testing. Thanks Susan From shanna@juniper.net Fri Feb 10 17:49:29 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA7111E8083 for ; Fri, 10 Feb 2012 17:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCe22GMym0JY for ; Fri, 10 Feb 2012 17:49:28 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 4264011E807F for ; Fri, 10 Feb 2012 17:49:28 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTzXJJ15kp2P6EENpj3N1m5/eEuk9LXmq@postini.com; Fri, 10 Feb 2012 17:49:28 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 10 Feb 2012 17:49:13 -0800 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe01-hq.jnpr.net (172.24.192.59) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 10 Feb 2012 17:49:13 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 10 Feb 2012 20:49:13 -0500 From: Stephen Hanna To: Susan Thomson , "nea@ietf.org" Date: Fri, 10 Feb 2012 20:49:11 -0500 Thread-Topic: PT-EAP and fragmentation Thread-Index: AczoSERq0pX/+3AUjUO2C4QHZEArjwAFbAGQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 Subject: Re: [Nea] PT-EAP and fragmentation X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2012 01:49:29 -0000 Susan Thomson wrote: > The current PT-EAP spec includes support for fragmentation. > I would argue that fragmentation support is unnecessary I'm fine with that. People should use PT-TLS for long messages. Also, let me say that I'm delighted to see so many PT-EAP issues being raised and discussed harmoniously. That's just what we need to get the document revised and into WGLC in time for IETF 83. If you have comments on the current draft, please send them TODAY (as requested by Susan in her January 26 email). And if you have an opinion on the emails sent to the nea list in the last few weeks regarding PT-EAP, please send your opinions ASAP so that we can judge WG consensus and get the draft updated promptly. Thanks, Steve > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of > Susan Thomson > Sent: Friday, February 10, 2012 6:04 PM > To: nea@ietf.org > Subject: [Nea] PT-EAP and fragmentation >=20 >=20 > The current PT-EAP spec includes support for fragmentation. >=20 > I would argue that fragmentation support is unnecessary, given that the > underlying EAP tunnel method for PT-EAP also supports fragmentation, > which > will allow for message sizes up to approx 64K to be sent. >=20 > The reason is that EAP is not designed for bulk data transfer, and we > have > an alternate transport for this purpose: PT-TLS. >=20 > Also, it simplifies implementation and interoperability testing. >=20 > Thanks > Susan >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From stefan.winter@restena.lu Mon Feb 13 05:44:56 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0AE21F857A for ; Mon, 13 Feb 2012 05:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEyUXcUh+mFV for ; Mon, 13 Feb 2012 05:44:55 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDA921F8577 for ; Mon, 13 Feb 2012 05:44:55 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 1581C1057F for ; Mon, 13 Feb 2012 14:44:54 +0100 (CET) Received: from [IPv6:2001:a18:1:8:4d87:f128:af28:b8ec] (unknown [IPv6:2001:a18:1:8:4d87:f128:af28:b8ec]) by smtprelay.restena.lu (Postfix) with ESMTPS id 017441057D for ; Mon, 13 Feb 2012 14:44:53 +0100 (CET) Message-ID: <4F3913D5.8080700@restena.lu> Date: Mon, 13 Feb 2012 14:44:53 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: nea@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV Subject: Re: [Nea] Comments on running PT-EAP outside the tunnel X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 13:44:56 -0000 Hi, > For these reasons the PT-EAP specification should prohibit the use of PT-EAP outside an EAP tunnel method. I agree that sending PT-EAP unprotectedly is a bad idea and should be prohibited. I'm not sure that the protection necessarily has to be with an EAP tunnel method though. We've discussed earlier that there might be a use case in blending identity information with posture assessments and sending that to a policy server. If the data that's transferred on that leg is protected *somehow*, that would already be quite satisfactory to me. E.g. I could imagine that an EAP server terminates the tunnel method, authenticates the user, extracts posture information, *sends that over a TLS link to the policy server*, and decides on user admissability based on the policy server's results. Note how the posture data is protected by TLS just fine; it's just not an EAP tunnel method. I don't think we should preclude that kind of thing from happening. So I'd reformulate your statement above to: "should prohibit the use of PT-EAP outside a cryptographically protected tunnel (e.g. an EAP tunnel method)" Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 From stefan.winter@restena.lu Mon Feb 13 23:24:56 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9F721F86F2 for ; Mon, 13 Feb 2012 23:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ED3txnzhic0 for ; Mon, 13 Feb 2012 23:24:55 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 500C821F86EF for ; Mon, 13 Feb 2012 23:24:54 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 01F211057F for ; Tue, 14 Feb 2012 08:24:54 +0100 (CET) Received: from [IPv6:2001:a18:1:8:95da:6258:fbd1:df07] (unknown [IPv6:2001:a18:1:8:95da:6258:fbd1:df07]) by smtprelay.restena.lu (Postfix) with ESMTPS id EA1AF1057D for ; Tue, 14 Feb 2012 08:24:53 +0100 (CET) Message-ID: <4F3A0C45.5080801@restena.lu> Date: Tue, 14 Feb 2012 08:24:53 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: nea@ietf.org References: <4F3913D5.8080700@restena.lu> In-Reply-To: <4F3913D5.8080700@restena.lu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV Subject: Re: [Nea] Comments on running PT-EAP outside the tunnel X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 07:24:56 -0000 Hi, >> For these reasons the PT-EAP specification should prohibit the use of >> PT-EAP outside an EAP tunnel method. > > I agree that sending PT-EAP unprotectedly is a bad idea and should be > prohibited. > > "should prohibit the use of PT-EAP outside a cryptographically protected > tunnel (e.g. an EAP tunnel method)" following up on myself: I guess I was slightly wrong :-) It is important to send assessment data via a protected channel, that is IMHO still valid. It is not important that this assessment data be encoded in PT-EAP though: the entity that terminates the EAP tunnel decodes assessment data from PT-EAP. If it decides it needs to send the assessment data and/or associated identity data elsewhere, this can be encoded arbitrarily (so long as the communication is encrypted (do we all agree on this?). The communication would have to include the actual assessment data (PA messages) but would otherwise not have anything to do with the PT-EAP transport. With the payload data and the transport being considered differently, it's easy to state how things should be: * Joe's "should prohibit the use of PT-EAP outside an EAP tunnel method." is just fine. * A protocol is needed to transport assessment data (PA) and associated identity information from the EAP server to a policy server. This moves the problem out of the realm of EAP. It does raise the question though: what protocol would that be? I don't think there is a standardised protocol to do exactly that. PT-TLS comes to mind, but it doesn't cope with the identity parts. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 From lnunez@c3isecurity.com Fri Feb 17 09:55:03 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE4D21F85BD; Fri, 17 Feb 2012 09:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljvgEE7IF2wL; Fri, 17 Feb 2012 09:55:03 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id CC3FF21F85BB; Fri, 17 Feb 2012 09:55:02 -0800 (PST) Received: by ggnq2 with SMTP id q2so2223527ggn.31 for ; Fri, 17 Feb 2012 09:55:02 -0800 (PST) Received: by 10.236.175.36 with SMTP id y24mr10721300yhl.64.1329501302166; Fri, 17 Feb 2012 09:55:02 -0800 (PST) Received: from [172.16.1.103] (cpe-066-057-025-190.nc.res.rr.com. [66.57.25.190]) by mx.google.com with ESMTPS id g12sm15901161ana.2.2012.02.17.09.55.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Feb 2012 09:55:00 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Luis Nunez In-Reply-To: Date: Fri, 17 Feb 2012 12:54:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "kathleen.moriarty@emc.com>" , nea@ietf.org X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlOuccvzknyar0zlqU11mrHuv1s53S46XkRYZq2uzqYP32tlfI/cuvV7j9Vyc78nEelwnX2 Cc: scap_interest@ietf.org Subject: Re: [Nea] [scap_interest] Security automation and MILE X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 17:55:03 -0000 Along the lines of what Kathleen is doing. I was wondering what are the = Security Automation (SCAP) connections with NEA? =46rom an endpoint assessment, SCAP is a natural fit. Are there = transport specifications that a SCAP client could leverage to converse = beyond a NEA server?=20 thanks. -ln On Feb 14, 2012, at 9:47 AM, = wrote: > Greetings, >=20 > In support of this effort, I plan to write and submit a draft very = soon to show the relevance of this work to the IETF work in MILE. The = Structured Cybersecurity Information draft that extends IODEF is a very = clear connection. The GRC-Exchange work is another connection point. = Once I have it posted, I will share the link to this mailing list. >=20 > Best regards, > Kathleen >=20 > _______________________________________________ > scap_interest mailing list > scap_interest@ietf.org > https://www.ietf.org/mailman/listinfo/scap_interest From kathleen.moriarty@emc.com Fri Feb 17 09:58:38 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4029321F8764; Fri, 17 Feb 2012 09:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.956 X-Spam-Level: X-Spam-Status: No, score=-9.956 tagged_above=-999 required=5 tests=[AWL=0.643, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ht4gODQCzmDE; Fri, 17 Feb 2012 09:58:37 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 82DB421F8760; Fri, 17 Feb 2012 09:58:37 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1HHwY7F028258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Feb 2012 12:58:34 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Fri, 17 Feb 2012 12:58:23 -0500 Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1HHwMtt026327; Fri, 17 Feb 2012 12:58:23 -0500 Received: from mx06a.corp.emc.com ([169.254.1.82]) by mxhub24.corp.emc.com ([128.222.70.136]) with mapi; Fri, 17 Feb 2012 12:58:22 -0500 From: To: , Date: Fri, 17 Feb 2012 12:58:21 -0500 Thread-Topic: [scap_interest] Security automation and MILE Thread-Index: AcztnVFw7tYitifbQcqLIdKlv4KOiAAAB7Rw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: scap_interest@ietf.org Subject: Re: [Nea] [scap_interest] Security automation and MILE X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 17:58:38 -0000 Hi Luis, We will have an update to the GRC-exchange document that generalizes RID to= cover the exchange of other schemas posted soon. This is part of the MILE= charter. It may hit some of the objectives for transport, although there = could be others that are extensions from NEA that I am also interested to l= earn about. We should try to fit the pieces together as we evolve specific= ations to standards for this ecosystem. Thanks, Kathleen -----Original Message----- From: Luis Nunez [mailto:lnunez@c3isecurity.com]=20 Sent: Friday, February 17, 2012 12:55 PM To: Moriarty, Kathleen; nea@ietf.org Cc: scap_interest@ietf.org Subject: Re: [scap_interest] Security automation and MILE Along the lines of what Kathleen is doing. I was wondering what are the Se= curity Automation (SCAP) connections with NEA? >From an endpoint assessment, SCAP is a natural fit. Are there transport sp= ecifications that a SCAP client could leverage to converse beyond a NEA ser= ver?=20 thanks. -ln On Feb 14, 2012, at 9:47 AM, wrote: > Greetings, >=20 > In support of this effort, I plan to write and submit a draft very soon t= o show the relevance of this work to the IETF work in MILE. The Structured= Cybersecurity Information draft that extends IODEF is a very clear connect= ion. The GRC-Exchange work is another connection point. Once I have it po= sted, I will share the link to this mailing list. >=20 > Best regards, > Kathleen >=20 > _______________________________________________ > scap_interest mailing list > scap_interest@ietf.org > https://www.ietf.org/mailman/listinfo/scap_interest From lnunez@c3isecurity.com Fri Feb 17 10:38:15 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC4821E8071; Fri, 17 Feb 2012 10:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdL8qGGGrC76; Fri, 17 Feb 2012 10:38:14 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 82DD221E8062; Fri, 17 Feb 2012 10:38:14 -0800 (PST) Received: by ghbg16 with SMTP id g16so2251908ghb.31 for ; Fri, 17 Feb 2012 10:38:14 -0800 (PST) Received: by 10.236.185.42 with SMTP id t30mr2318979yhm.105.1329503894083; Fri, 17 Feb 2012 10:38:14 -0800 (PST) Received: from [172.16.1.103] (cpe-066-057-025-190.nc.res.rr.com. [66.57.25.190]) by mx.google.com with ESMTPS id n10sm8220564ani.8.2012.02.17.10.38.12 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Feb 2012 10:38:13 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Luis Nunez In-Reply-To: <80B432C0A0D105468E74A98942733F77181DD5F0@IMCMBX04.MITRE.ORG> Date: Fri, 17 Feb 2012 13:38:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1B1CD04C-711D-44BD-BAE0-638792BFAA17@c3isecurity.com> References: <80B432C0A0D105468E74A98942733F77181DD5F0@IMCMBX04.MITRE.ORG> To: "Schmidt, Charles M." X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlKKL8asvzZj4AwGlQH+u9TuoYeEr+5YVl9nvkq58uIkwEgDPfvbekKvo/8Myxn484h/c4x Cc: "nea@ietf.org" , "kathleen.moriarty@emc.com>" , "scap_interest@ietf.org" Subject: Re: [Nea] [scap_interest] Security automation and MILE X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 18:38:15 -0000 Charles, thanks for info. and glad to see some key people working towards this. = We look forward to putting all this together. -ln On Feb 17, 2012, at 1:12 PM, Schmidt, Charles M. wrote: > Hi Luis, >=20 > In fact, I am working on a TCG specification (along with Paul = Sangster, Kent > Landfield, and Steve Hanna) for exchange of SCAP information within = TCG's > Trusted Network Connect, which is NEA in the IETF. So yes - I = completely > agree that it is a natural fit and we are hoping to have a TCG spec > outlining that fit by the end of the year. :) >=20 > Charles >=20 >> -----Original Message----- >> From: scap_interest-bounces@ietf.org [mailto:scap_interest- >> bounces@ietf.org] On Behalf Of Luis Nunez >> Sent: Friday, February 17, 2012 11:55 AM >> To: kathleen.moriarty@emc.com>; nea@ietf.org >> Cc: scap_interest@ietf.org >> Subject: Re: [scap_interest] Security automation and MILE >>=20 >> Along the lines of what Kathleen is doing. I was wondering what are = the >> Security Automation (SCAP) connections with NEA? >>=20 >> =46rom an endpoint assessment, SCAP is a natural fit. Are there = transport >> specifications that a SCAP client could leverage to converse beyond a = NEA >> server? >>=20 >> thanks. >>=20 >> -ln >>=20 >> On Feb 14, 2012, at 9:47 AM, >> wrote: >>=20 >>> Greetings, >>>=20 >>> In support of this effort, I plan to write and submit a draft very = soon > to show >> the relevance of this work to the IETF work in MILE. The Structured >> Cybersecurity Information draft that extends IODEF is a very clear >> connection. The GRC-Exchange work is another connection point. Once = I >> have it posted, I will share the link to this mailing list. >>>=20 >>> Best regards, >>> Kathleen >>>=20 >>> _______________________________________________ >>> scap_interest mailing list >>> scap_interest@ietf.org >>> https://www.ietf.org/mailman/listinfo/scap_interest >>=20 >> _______________________________________________ >> scap_interest mailing list >> scap_interest@ietf.org >> https://www.ietf.org/mailman/listinfo/scap_interest From cmschmidt@mitre.org Fri Feb 17 10:12:58 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B78E21F8679; Fri, 17 Feb 2012 10:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1gn0xG7B5V5; Fri, 17 Feb 2012 10:12:57 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9593221F865E; Fri, 17 Feb 2012 10:12:57 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 04D8621B1326; Fri, 17 Feb 2012 13:12:57 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id BA3D321B161D; Fri, 17 Feb 2012 13:12:56 -0500 (EST) Received: from IMCMBX04.MITRE.ORG ([169.254.4.153]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.01.0339.001; Fri, 17 Feb 2012 13:12:56 -0500 From: "Schmidt, Charles M." To: Luis Nunez , "kathleen.moriarty@emc.com>" , "nea@ietf.org" Thread-Topic: [scap_interest] Security automation and MILE Thread-Index: AQHM7Z1MhsBinub86E+b26ttgPPGNJZBYusw Date: Fri, 17 Feb 2012 18:12:55 +0000 Message-ID: <80B432C0A0D105468E74A98942733F77181DD5F0@IMCMBX04.MITRE.ORG> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0065_01CCED6D.779C9370" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 17 Feb 2012 11:27:30 -0800 Cc: "scap_interest@ietf.org" Subject: Re: [Nea] [scap_interest] Security automation and MILE X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 18:12:58 -0000 ------=_NextPart_000_0065_01CCED6D.779C9370 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Luis, In fact, I am working on a TCG specification (along with Paul Sangster, Kent Landfield, and Steve Hanna) for exchange of SCAP information within TCG's Trusted Network Connect, which is NEA in the IETF. So yes - I completely agree that it is a natural fit and we are hoping to have a TCG spec outlining that fit by the end of the year. :) Charles >-----Original Message----- >From: scap_interest-bounces@ietf.org [mailto:scap_interest- >bounces@ietf.org] On Behalf Of Luis Nunez >Sent: Friday, February 17, 2012 11:55 AM >To: kathleen.moriarty@emc.com>; nea@ietf.org >Cc: scap_interest@ietf.org >Subject: Re: [scap_interest] Security automation and MILE > >Along the lines of what Kathleen is doing. I was wondering what are the >Security Automation (SCAP) connections with NEA? > >From an endpoint assessment, SCAP is a natural fit. Are there transport >specifications that a SCAP client could leverage to converse beyond a NEA >server? > >thanks. > >-ln > >On Feb 14, 2012, at 9:47 AM, > wrote: > >> Greetings, >> >> In support of this effort, I plan to write and submit a draft very soon to show >the relevance of this work to the IETF work in MILE. The Structured >Cybersecurity Information draft that extends IODEF is a very clear >connection. The GRC-Exchange work is another connection point. Once I >have it posted, I will share the link to this mailing list. >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> scap_interest mailing list >> scap_interest@ietf.org >> https://www.ietf.org/mailman/listinfo/scap_interest > >_______________________________________________ >scap_interest mailing list >scap_interest@ietf.org >https://www.ietf.org/mailman/listinfo/scap_interest ------=_NextPart_000_0065_01CCED6D.779C9370 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYQDCCBS0w ggMVoAMCAQICEEw6UhQhT9OgRBVHf7KQ+1AwDQYJKoZIhvcNAQELBQAwKTEnMCUGA1UEAxMeTUlU UkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMB4XDTExMDQyNjE5NDU0NVoXDTIxMDQyNjE5NDgy MlowKTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMIICIjANBgkqhkiG 9w0BAQEFAAOCAg8AMIICCgKCAgEAtp8hR0hRq3im+Alwfb5ZHGP5k2OSY2TlVHYHIMUDH3MfW7b6 8lB3j3MwAMsxGK1ke/t6O4K0t9wRH4QDgOQ1CthmOGZW7xiN81h0vP1Yf14SNugUa7ZvH9KP3iXs y8QnOHal1bKf0Pa9KXib58qUuwfaZSCTW5P2ekqd8z4TETvfBWvPgDxyxnVsiAO6yL9WaRpMiSVM hYLWy3KRuU/gue0bVEi+qdg+hENh1NSNXpoqseS262nq5cx5wybR/PF0YstQ9NNlYDM5cLECKYHH zD6cXKJozuFXriswlE8rdna7VaxyZrfgC0ueEIY/tsj/65IyUhyPBwO0ZpW+Ls9Cd4Y+ERSu5mR5 Fd8w42eVzuosmk3s3AxrKC+Z4tXYkjaiWUduIegAiST1vJBwkS53vR+zrBX3Ep56l7MFVvW/GcsZ 9wUT2HG65JOeiVc2YzCEqLgQ3ZCBHn09oBag2lnMac+E2sKm9aKL3xzHs6cyD8qCJK9O8QLCqo3C mzASlOwtTFiLYgpPW/MSmgYOt9JrwHAzk97DHFKTFttjrXGMmhMVzadt1EjMn1Wv8t5WLBI0qSoX /MYi2CaeiDsEiWRu9Nmpu3pmi8m7tIR9csdbAVPks2soNMWOopGEpFQSDvU1+m77v2jIKQKYxYmN 2zUOJ4TJFL1osnZ/71MmLCDVd+ECAwEAAaNRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMB Af8wHQYDVR0OBBYEFFuHfZ/+bL4C6fPgKTqKVCUsnzgvMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqG SIb3DQEBCwUAA4ICAQAy78sXsP/eqHH8/uOYyxQ6TBDhkCBxNoy8MF2c9UDns5ADL1qyxPAlpDBs L+2h1Zzt3FvPjg0SoRE/9juyG1qxMzhlv0jdQx12tESdo3uBb61b1uuc4H/VxCJWDI4KZL/B53EI 8HGPjUBdLADgOmG99uffm5uarSkjtIX//Bz3U6QfzTPlVWFi4SmzRI2mp16GQ8RPuJ/WMloaAn8X H6EjS2oLjGZC8Pw8/C46W48NvZ1JZTrZvYZr7GmuvmplYK68SZv/T5Su+FlLRTy9uNXQLHtm6jKv nDH2yB66zTwfaDpnjILnrC2O7ANRVZc0KywiKiW3nB7Joq74/XVuMI1PiSByt2Qu+RIS/WAI5wMi bTmwSiBxQZqvuth+dXoakJyOP2Wg5jvL55v9RLZhDqMtRI5ovnOFvTgNJQqNPSekGtA+m6Ctl/vh kSg65FFCMhaSkn7vY2Il+R8HouWJN8wTaudeexnyHcD+Mlt8QaB5CErpDjeeGZfQ0FcYm+6TtlMz Dw5eFhT/J6QrABCxfgLkVFHurMcQD4JkmXXkq5bP+GNkY0Uy2LMbw/UD94OEV1LpfAqUkT+mu5Yb vxg+elFtsad+Ix8owW372xynIADh9q1bHm+j1OHPJmGALWK9miRpC4t3isfu3ZB0QpI/e2Po6MED 393Jb0YbzrcElFv6ZDCCBhwwggQEoAMCAQICCjXQ+u0AAgAAHHUwDQYJKoZIhvcNAQEFBQAwUDET MBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRS RSBDb3Jwb3JhdGlvbiBQRSBDQS0xMB4XDTEyMDIwODE4MjYzN1oXDTE1MDIwNzE4MjYzN1owTjEL MAkGA1UEBhMCVVMxDjAMBgNVBAoTBU1JVFJFMQ8wDQYDVQQLEwZQZW9wbGUxHjAcBgNVBAMTFVNj aG1pZHQuQ2hhcmxlcy4yNTY1ODCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMrfqe4f m+ZeRZvWO7aYp89KmWSTnFKgZjWprxFQ8zmAlth3LKEVdNn4wZgdUz54uHZvi5uCvcQU0trt2iDw F/hQ6jdn3VZhZsmA7TnRHRocBYIWdhvTEjOXpsKj51kz6uizhseb3lGubSj2DwN6A6C4f5SQt5yw CkpwX0pz9WqaSrT2aGoHgWx9MOBww1+v5DS5VNhHIyCVw0eFoSJ8aZxcWMIRBDdoFOCFR33KKfU9 P+/vYaG7OiNQlko5d0vvCBApYGURyaBKde1Krd0wRTP9FCc5GD+5OYxZx4XAhBMgQuh2Hv7E8EM+ ORpRQ2fW1Pno5dTl/92Sl1RITgxcyvkCAwEAAaOCAfgwggH0MCgGA1UdJQQhMB8GCCsGAQUFBwME BgkrBgEEAXMCAQcGCCsGAQUFBwMCMB0GA1UdDgQWBBTYG13f8BosUG6c5VDRxlP6AJYFezAOBgNV HQ8BAf8EBAMCBsAwHgYDVR0RBBcwFYETY21zY2htaWR0QG1pdHJlLm9yZzAfBgNVHSMEGDAWgBRp ZyAh1EjB0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vcGtpLm1pdHJlLm9y Zy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/BggrBgEFBQcBAQRzMHEwRwYI KwYBBQUHMAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIwQ29ycG9yYXRpb24lMjBQRSUy MENBLTEoMikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5taXRyZS5vcmcvb2NzcDA+Bgkr BgEEAYI3FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsShb6uAYE2g9KXfYeg+0kCAWQC AQcwFgYDVR0gBA8wDTALBgkrBgEEAXMCAQgwNAYJKwYBBAGCNxUKBCcwJTAKBggrBgEFBQcDBDAL BgkrBgEEAXMCAQcwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQEFBQADggIBALqulox86p0q7Ry3fzT8 GOIMzBtv2HfzWXNciUVnvEtYtqfeSL+SmDU6JnVX2Mga7yzUdHnZ5J8+VfSARUpIIxoe56EI0Zc5 DJx1C4Uu5RErFCDf6Ye+YjZQHx6PI9jajX3b0Z1yyHDs5pfaDHZHLR7H5POdhJuna2SCk+d35/0g ciyUfa+yuwSZvpxsUSz6X/RnNe07w4K8631cShm3aAFE2ZQNndk+qqVDQ10MuDM/hLJMQFKCe+KV V2qqtrU879aF4nUh6aoq/i5pjHmV1c2uPx+LVX9uwaOQPOxIgbEuSC8dP6W5FAquGgLNI0bxCn5q eMza1rOXVQcpI5TCVzBtWfqPp0ipzWe/+PCl/T/aFbTeygC/JY/KjSpD+PMzOFjf7lhGjIx/bQUp pgbrcaUU2YX3ueygXDn9MyZZdS58hu49tC1Juq2TmhG8q/HAgD631tqRde6a2fuKfQX6cE0L6T2/ +bU39U+EExPz00bBzc2aMKMgayCFoqU2xH/nl2r8I9FiZbjcBwl02kvumOYcRTftIzesoj59LgGR y6iS728LHv1SJw11FE2yCVYb4Q1xtlKc8d9qp8p5UcCIu+zKFYqFRqSbdPBav7ZI169fR19tZWwy CzmXDYACGX6X38coRpdaTStwYC9Ed/2oB1bsr8iw57EAwD25hKX8RcbdMIIGYjCCBEqgAwIBAgIK FJcW0gAAAAAABDANBgkqhkiG9w0BAQsFADApMScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQ RSBSb290IENBLTEwHhcNMTEwNjE0MTc0NDQ0WhcNMTcwNjE0MTc1NDQ0WjBQMRMwEQYKCZImiZPy LGQBGRYDT1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNVBAMTGU1JVFJFIENvcnBvcmF0 aW9uIFBFIENBLTEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDSxK9RXieqdTz4JWRk RMs/EOuF0P0S9SbspadLJkx/LDDnaAwmAnqfqm1n7/p82oVjy1yCye3SZu4Yp7fmDIAtWbkHvYOf xHkRv1ho/fhaNN0YRkd65oJJz2ngEbNZxdIiCoialQfX/iWU7ApQ+ovKbFV60v5E0p2mPncs20NY RfsaetdhnBZbFD9flDcXwJqSvGGGBfm7ifFCR1LrtEcNKjMwf7YEWZO0Vk3ZyhVq+k7JNLEbKv0O fBz8DU8GiGU+j88QlrgGW8PLkwNk7nsS/DJp8aLudTuVqIE2CA9mqn5QjU/EZYNHGzSfCr+/usUm bojyVSJukhhrAXspRAMz+Cia3yi3q3w8TnAljXWN1dhx1iuUv5GxyzMjfqK1tMuCUU2XzGNNqoVa 1mqolBiyDTCOr9d/IC0YHYMBSpQ+xi0x9zjXKt4FmQmkEAZgF4hsZZqcJYL/iCQiwiz8fEyVPZuv oWvdEXOozFYCpmkT0MZCJwyIux0Z6vJp6VLtN/6rZgc2y54HlTrp3ifazmpsfrk3NdHxlZTZug9k jEI+vEoyp/79nAPyTWQQ1MEP0ErCWav80/HOi0MLx/7lIUfvVOjkOFgFb+iDvR4T3RAQrnEpgTO+ fc7Jyzh9LpFDqm0slwDP4Hj9cC3IzdED5BU43PGAe+HoZ8OD/1ovVgwo/wIDAQABo4IBYzCCAV8w EAYJKwYBBAGCNxUBBAMCAQIwIwYJKwYBBAGCNxUCBBYEFFCiOtgZb+Zdflkw5sC2y01sUQaVMB0G A1UdDgQWBBRpZyAh1EjB0BsGbvMIKOI6gn1BMTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAL BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRbh32f/my+Aunz4Ck6ilQl LJ84LzBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBv cmF0aW9uJTIwUEUlMjBSb290JTIwQ0EtMS5jcmwwWwYIKwYBBQUHAQEETzBNMEsGCCsGAQUFBzAC hj9odHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBSb290JTIw Q0EtMS5jcnQwDQYJKoZIhvcNAQELBQADggIBAHnDPfdYKxqNOtAYXMyyel83Vs8cCDAQZhSuIB0c 6GkGoEdFrmWH9pwi42V96rCp7TvbNNKNJXbVHfJUAp+uqw663DL/sXXff9ZFxPxKOdPnpA8cKM7R BH9e437Nw3d28A7PaGbP6tXmSqhXAhYZ4U12y1U5cOf2G/phUoAAMlnVJdfmXzMazvLo2SIeixAJ yCze6rHQTFQ/N+gAjbVuRJ+Hs8FEKVzMSwqlNoupe2ELqL4dMAKT6P08sAfxm2SrRlQvcWPYvqM/ 1C10bgc2tdu+WGzRuP5Wx9Yr15KO9SW4z7fn2RVEXQgoDDno5vCIcfUPuKB5n+Kt9eBCitsgSD9y YsNUN9LEVIvjAb8MV2LWLfge1bumo6g7QMRa4Fgifw5siGwi7V2EaJQo6UAIVvxKKFC7W4p6CkrY 2ga1d7GIQ0DPiWZOezOakJVAxL5gf+3WdNt0igKc/yLfbdHn6hCd1KPgDqkSKr8zWOZI/jiDBW95 7xAmaO6QdGQDBZrQHWpIVwQGzF5bGrqms2kq49l3t7KmBu0C/9tExqKAmlf4Y5lfQGdCbKQpAq71 2DVQHYuDXmVQEAc2vlJ1C5hS3Iw9DwBWTfJ4vyB48buhBhbIhPiFta5OizXlKcsIi99ikA1yiZx/ DBtjaw4JU6qJzWUFB2ecyGCNPtNbYjURA0A9MIIGhTCCBG2gAwIBAgIKNdD96gACAAAcdjANBgkq hkiG9w0BAQUFADBQMRMwEQYKCZImiZPyLGQBGRYDT1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUx IjAgBgNVBAMTGU1JVFJFIENvcnBvcmF0aW9uIFBFIENBLTEwHhcNMTIwMjA4MTgyNjM4WhcNMTUw MjA3MTgyNjM4WjBOMQswCQYDVQQGEwJVUzEOMAwGA1UEChMFTUlUUkUxDzANBgNVBAsTBlBlb3Bs ZTEeMBwGA1UEAxMVU2NobWlkdC5DaGFybGVzLjI1NjU4MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAorGFoUP/zIAgRw12Ip6aDMZvkFCAOAQaWFer+PdAqnFNTH1v758Y3SaoCVYV8A+l 4FQryRUFLooFo4iGAGIom2pJ+gOO0McZdIZV77mzpaKIGavG2ER4nNcR6Hmo/iN/SxxK8yCskq9/ gUU/M+OjsQlCihw/6eEDZLyMwH9ugtPbtlt64xKSXQMDAarayTWs6mnW52RQdHukS2Z2PknWnug2 fg1oujCHFhr7ozY8+ACo6A5efGv8mbHupUlKmldD0HImJXSPinWG7eNzhIYG1/TArbMIfngiImIf iHpJM+xUSWDd5Uj1d6BphpdKRjaqr45xpTrdA4epQNj2WP8v7QIDAQABo4ICYTCCAl0wEwYDVR0l BAwwCgYIKwYBBQUHAwQwgZQGCSqGSIb3DQEJDwSBhjCBgzAOBggqhkiG9w0DAgICAIAwDgYIKoZI hvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAS0w CwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBGTALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEFMB0GA1Ud DgQWBBQoJcp1KJQWbg6AC0wyjvYg3JaECDAOBgNVHQ8BAf8EBAMCBSAwHgYDVR0RBBcwFYETY21z Y2htaWR0QG1pdHJlLm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB0BsGbvMIKOI6gn1BMTBJBgNVHR8E QjBAMD6gPKA6hjhodHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUl MjBDQS0xLmNybDB/BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUHMAKGO2h0dHA6Ly9wa2kubWl0cmUu b3JnL01JVFJFJTIwQ29ycG9yYXRpb24lMjBQRSUyMENBLTEoMikuY3J0MCYGCCsGAQUFBzABhhpo dHRwOi8vb2NzcC5taXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3FQcEMTAvBicrBgEEAYI3FQiDrqwj ho6WV4GNiT2CpKsShb6uAYE2hquSaISo7EUCAWQCAQ8wFgYDVR0gBA8wDTALBgkrBgEEAXMCAQgw GwYJKwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAgEAHKX0H9OV/dwo Z9iKg2gM3SWDeGQ2fxCS3LW4Bp865NB2wlv8CP74O1xfFXIWqrKtqJZKStZ3D516vwhe6hP9AllS qyoAc6m7gqrpZlcbwyurBXXFhvZ3ZpEyasgyFhVSPqCIn4IOeAeHZSiMIh/rIUspSVW/DsYhpNpd CoiL3R3br1oAfJ+ijTxtTFvo/LLp/xnNONtpObqQylxO0HIU/3boqmFWy+w5P/GooxPwfwczLjks Cdo8RSUh/qZmYOaSRQPlgLMkqIrYwa2TGVWm00K2uIs7V5r3qlulobOccKjM649dORGnJnwCygsd zUbFutDHYSPEpmfY7Bj0oZo2qsJNstpAPqXSX4WvjVroYtV6P2fJ0PsYiTWwQtzBg9gQJfVUSVi6 MvExmrGJLI5kHUtuFGxkyq4arl2nvTGsi6D+75qXktGXaMHC2pPoUa2NXkJ2ogDw/7QPF60DuHJ3 RZ1XYebDKV/JURT6feN5LJvqxxd0KhvEyPZaxPZlkXvbToRWMGUthfYkhaZMvO7TV0nU4+gEjyWG z2AVh9G7nf5D+w/KlQSHrMCxGbwAVgUUIzcQhpD061hCYHisOpsyW/Th0lFgFFcFZeanVsyaLHkq 6cwnCQyPAdBqsKpArS11BP5zt36v7m8M/bm/OYPgNnqNXMU7PqRFVvbXRWV/qlsxggMjMIIDHwIB ATBeMFAxEzARBgoJkiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZFgVNSVRSRTEiMCAGA1UE AxMZTUlUUkUgQ29ycG9yYXRpb24gUEUgQ0EtMQIKNdD67QACAAAcdTAJBgUrDgMCGgUAoIIBmjAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAyMTcxODEyNTBaMCMG CSqGSIb3DQEJBDEWBBQhSMhQvCRqNoQeawuGd393Do8I4jBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDAHBgUrDgMCGjBtBgkrBgEEAYI3EAQxYDBeMFAxEzARBgoJkiaJk/IsZAEZFgNPUkcxFTAT BgoJkiaJk/IsZAEZFgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29ycG9yYXRpb24gUEUgQ0EtMQIK NdD96gACAAAcdjBvBgsqhkiG9w0BCRACCzFgoF4wUDETMBEGCgmSJomT8ixkARkWA09SRzEVMBMG CgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRSRSBDb3Jwb3JhdGlvbiBQRSBDQS0xAgo1 0P3qAAIAABx2MA0GCSqGSIb3DQEBAQUABIIBADzinXuAuOuzal2UMQSlihupAiUkeGea1fsQCrq1 ZKoRiMA+xP8p+U80sRcCgu0J9kVMdqHctTXvfIS4+Li1RlPt2hwmRPTkY6bPNXfZaWq6aYdENre9 Kn1pSGi8kffXDUJSAhRNA0xlvtWsOH5Q8FMmHbS7lx5+W5o8f0xDxRUFEK1T6CnSh82uSh+rTnEj 64M78kesL58f2I8K88VfODJ2IQlTMIO+68s3oiwS4+pYdFtjxw9h5sUvlbm5wNdIHYMKIFJv7vQi v+Gxx/B58Jee3rPt7JwzoPo0AsbAV8FmJ+sk/9du0fgcsPZA7rHkcxwYByhvvhH4qXXBZI/Mg30A AAAAAAA= ------=_NextPart_000_0065_01CCED6D.779C9370--