From nobody Tue Feb 2 12:14:27 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7032D1B3045 for ; Tue, 2 Feb 2016 12:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 5lUmtU5XYX4j for ; Tue, 2 Feb 2016 12:14:21 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAD51B3042 for ; Tue, 2 Feb 2016 12:14:21 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6E84D433414; Tue, 2 Feb 2016 20:14:20 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 571ED43340D; Tue, 2 Feb 2016 20:14:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1454444060; bh=RzS4mEvalzZ41gno6b5Vw0e+xZaePccev7KEkVtFRcg=; l=4460; h=From:To:Date:From; b=DKPcSezFxYJG7wjxTubrB1MJpL+mVW70RcDIi6ze5Jv6seS4pfWtPfJAS9PHFqeW/ ifIaI8jiknwq2vnaDy4knDPPQEillBOxz46yMBgyQfFN40MxKWSEIBmqweF4d/ZW1W 6gB+YFvTT6lvwwGxEuQMvWbTsvbhkKyk3om70fSk= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 5194E2050; Tue, 2 Feb 2016 20:14:20 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 2 Feb 2016 15:14:19 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1076.000; Tue, 2 Feb 2016 15:14:19 -0500 From: "Salz, Rich" To: "saag@ietf.org" , "cfrg@irtf.org" Thread-Topic: NSA re-org and its impact Thread-Index: AdFd9UEpaCor10ifQm2t0DeUinMJsA== Date: Tue, 2 Feb 2016 20:14:18 +0000 Message-ID: <69adf656430c4230981785b78af76af4@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.193] Content-Type: multipart/alternative; boundary="_000_69adf656430c4230981785b78af76af4usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: [saag] NSA re-org and its impact X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 20:14:23 -0000 --_000_69adf656430c4230981785b78af76af4usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I try to stay out of national crypto politics here, but I think many on the= se lists (both big, please be careful about replying) will care. The NSA is re-organizing to merge its signals intelligence (attack) and inf= ormation assurance (protect) into one unit. The NSA is, by US Law, the off= icial advisor to NIST on cryptography. NIST has a pretty admirable track re= cord of crypto (exceptions being mostly when they were misled by their offi= cial expert). Things may change now. Or not. YMMV. https://www.washingtonpost.com/world/national-security/national-security-ag= ency-plans-major-reorganization/2016/02/02/2a66555e-c960-11e5-a7b2-5a2f824b= 02c9_story.html -- Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz --_000_69adf656430c4230981785b78af76af4usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I try to stay out of national crypto politics here, = but I think many on these lists (both big, please be careful about replying= ) will care.

 

The NSA is re-organizing to merge its signals intell= igence (attack) and information assurance (protect) into one unit.  Th= e NSA is, by US Law, the official advisor to NIST on cryptography. NIST has= a pretty admirable track record of crypto (exceptions being mostly when they were misled by their official expert). = Things may change now.  Or not.  YMMV.

 

https://www.washingtonpost.com/world/national-secur= ity/national-security-agency-plans-major-reorganization/2016/02/02/2a66555e= -c960-11e5-a7b2-5a2f824b02c9_story.html

 

-- 

Senior Architect, Akamai Technologies

IM: richsalz@jabber.at Twitter: RichSalz<= /p>

 

--_000_69adf656430c4230981785b78af76af4usma1exdag1mb1msgcorpak_-- From nobody Tue Feb 2 12:48:37 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFAB61B30E5 for ; Tue, 2 Feb 2016 12:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 c0qxwXmyccC0 for ; Tue, 2 Feb 2016 12:48:34 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D7FC1B2E92 for ; Tue, 2 Feb 2016 12:48:32 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id p63so136334019wmp.1 for ; Tue, 02 Feb 2016 12:48:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=yb4sVazbFemHqJPguY801ANl7yzNVO+cJwdytEoc/eQ=; b=ZxGQ8jWgHIBuQPYOjwSWYQweZ/20hWqZa6lKxtO2ZICvZ7rgwymMpQyiZECP1mavVI GhwEKsuQnecFE8LjLZ1YvrY+dQ5CIXgJWZ5LXCU0UpKn6jy+4pu5L9GGB3Qu5NKBYsIp hmElg0EC054j7uNXNJfj1JG0i2YM8299UnasYgYWOAihfvEiBAn+k0ET28AjdeUbwjZt 6p4oczqnT5Clnx3mXSJRMr9fQHJa7d2qA607+N3a504dbgC+Jwyo/FFn2b529odYo95H QxfIG2eqe94nKpf9Gf0eOqDWAV7J2XI8AnNzJaNmperFHzV2ykmsZWvUvnpqy1LipDBl FTuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=yb4sVazbFemHqJPguY801ANl7yzNVO+cJwdytEoc/eQ=; b=Ou55E0ldAmyXW+Pa8+aDp8ZiTzEE0bZ1ZK1fDJsv0/wcEqfd9b8kVnK7fZicx4cYvc m/QEeM2QeVr2El5QrFtu74aqUgrsF96yc0fCQj1En2HrawkhAbkSgnv/F8tiVFeP6jZf 3xtRrN8nIj5DjEIVp568qj1Dg8gEq8z68g6AlHAvcsgNdOGpXXmBcLmfjqBQxL6VXQyB RxTiQ70MCtrqRg0I4zo0ZipYfVwpkAfmtX3cK69MZbNe1rnuijRDZyxTsxXpXh4XEstz 0Wl5Vxprn35abVJm3slKE17Gt6Dj3oWP+TXaiROUBg5+gCPQzdQnA8+8c6cn9RkW0/OX Xk2g== X-Gm-Message-State: AG10YOQQim7c/Y2VfGG3WbK/V0i7bpTzuSd8SAAvPspQTnSgJyBdO2V7gkoWOSQ0sxOHeQ== X-Received: by 10.194.200.106 with SMTP id jr10mr34509483wjc.100.1454446111140; Tue, 02 Feb 2016 12:48:31 -0800 (PST) Received: from [192.168.1.13] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id l194sm18291125wmb.14.2016.02.02.12.48.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 02 Feb 2016 12:48:29 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_61C25949-A904-40F8-ABB7-3B664F75466B" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: <69adf656430c4230981785b78af76af4@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Tue, 2 Feb 2016 22:48:27 +0200 Message-Id: <29CEA796-1CF8-4CCE-87DA-7FF368E64385@gmail.com> References: <69adf656430c4230981785b78af76af4@usma1ex-dag1mb1.msg.corp.akamai.com> To: Rich Salz X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "cfrg@irtf.org" , Security Area Advisory Group Subject: Re: [saag] [Cfrg] NSA re-org and its impact X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 20:48:36 -0000 --Apple-Mail=_61C25949-A904-40F8-ABB7-3B664F75466B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 2 Feb 2016, at 10:14 PM, Salz, Rich wrote: >=20 > I try to stay out of national crypto politics here, but I think many = on these lists (both big, please be careful about replying) will care. > =20 > The NSA is re-organizing to merge its signals intelligence (attack) = and information assurance (protect) into one unit. The NSA is, by US = Law, the official advisor to NIST on cryptography. NIST has a pretty = admirable track record of crypto (exceptions being mostly when they were = misled by their official expert). Things may change now. Or not. YMMV. > =20 > = https://www.washingtonpost.com/world/national-security/national-security-a= gency-plans-major-reorganization/2016/02/02/2a66555e-c960-11e5-a7b2-5a2f82= 4b02c9_story.html = > =20 IDK. People were complaining before about the attack mission = overshadowing and in fact hurting the protect mission. I don=E2=80=99t = see how this makes it better. Perhaps worse. > =E2=80=9CWhen it comes to cyber in particular, the line between = collection capabilities=20 > and our own vulnerabilities =E2=80=94 between the acquisition of = signals intelligence=20 > and the assurance of our own information =E2=80=94 is virtually = nonexistent,=E2=80=9D said=20 > Rep. Adam B. Schiff (Calif.), the ranking Democrat on the House = Intelligence=20 > Committee. =E2=80=9CWhat is a vulnerability to be patched at home is = often a potential=20 > collection opportunity abroad and vice versa.=E2=80=9D This sounds so... misguided. Yoav --Apple-Mail=_61C25949-A904-40F8-ABB7-3B664F75466B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 2 Feb 2016, at 10:14 PM, Salz, Rich <rsalz@akamai.com> = wrote:

I try to stay out of national crypto = politics here, but I think many on these lists (both big, please be = careful about replying) will care.
 
The NSA is re-organizing to merge its = signals intelligence (attack) and information assurance (protect) into = one unit.  The NSA is, by US Law, the official advisor to NIST on = cryptography. NIST has a pretty admirable track record of crypto = (exceptions being mostly when they were misled by their official = expert). Things may change now.  Or not.  YMMV.
 
https://www.washingtonpost.com/world/national-security/national= -security-agency-plans-major-reorganization/2016/02/02/2a66555e-c960-11e5-= a7b2-5a2f824b02c9_story.html
 

IDK. People were complaining before about the = attack mission overshadowing and in fact hurting the protect mission. I = don=E2=80=99t see how this makes it better. Perhaps worse.

=E2=80=9CWhen it comes to cyber in particular, the line = between collection capabilities 
and our own = vulnerabilities =E2=80=94 between the acquisition of signals = intelligence 
and the assurance of our own information = =E2=80=94 is virtually nonexistent,=E2=80=9D said 
Rep. = Adam B. Schiff (Calif.), the ranking Democrat on the House = Intelligence 
Committee. =E2=80=9CWhat is a vulnerability = to be patched at home is often a potential 
collection = opportunity abroad and vice versa.=E2=80=9D

This sounds so... = misguided.

Yoav


= --Apple-Mail=_61C25949-A904-40F8-ABB7-3B664F75466B-- From nobody Tue Feb 2 14:50:04 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5E21A01E2 for ; Tue, 2 Feb 2016 14:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 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, SPF_PASS=-0.001] autolearn=ham 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 64R01oplVquz for ; Tue, 2 Feb 2016 14:50:01 -0800 (PST) Received: from nk11p14im-asmtp001.me.com (nk11p14im-asmtp001.me.com [17.158.72.160]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4FF1A01A8 for ; Tue, 2 Feb 2016 14:50:00 -0800 (PST) Received: from [192.168.1.89] (host86-177-167-155.range86-177.btcentralplus.com [86.177.167.155]) by nk11p14im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) with ESMTPSA id <0O1X00ITYZF1SU10@nk11p14im-asmtp001.me.com> for saag@ietf.org; Tue, 02 Feb 2016 22:49:52 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-02-02_14:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1602020377 Content-type: multipart/alternative; boundary=Apple-Mail-1582B91E-1ECD-4E09-846E-31A36D365EC5 MIME-version: 1.0 (1.0) From: "David S. Misell" X-Mailer: iPad Mail (13D15) In-reply-to: <29CEA796-1CF8-4CCE-87DA-7FF368E64385@gmail.com> Date: Tue, 02 Feb 2016 22:49:48 +0000 Content-transfer-encoding: 7bit Message-id: References: <69adf656430c4230981785b78af76af4@usma1ex-dag1mb1.msg.corp.akamai.com> <29CEA796-1CF8-4CCE-87DA-7FF368E64385@gmail.com> To: Yoav Nir Archived-At: Cc: "cfrg@irtf.org" , Security Area Advisory Group Subject: Re: [saag] [Cfrg] NSA re-org and its impact X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 22:50:03 -0000 --Apple-Mail-1582B91E-1ECD-4E09-846E-31A36D365EC5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Surely the argument from David Alexander from RSA conference 2015 still hold= s, you need the best people in Offence to advise behind the scenes moving in= to talk freely to those in defence. In the U.K. We have never had the money o= r resources for both, ( according to Tony Sale before he died, when everythi= ng was one big melting pot in ww2 ) After all what has changed since Turing did the assurance analysis of the U.= K./USA telephone link which remained in use, even if his Delilah replacement= weighed 59 tons less and was portable! Best Regards, Dave 'Certain things are done first, then said' > On 2 Feb 2016, at 20:48, Yoav Nir wrote: >=20 >=20 >> On 2 Feb 2016, at 10:14 PM, Salz, Rich wrote: >>=20 >> I try to stay out of national crypto politics here, but I think many on t= hese lists (both big, please be careful about replying) will care. >> =20 >> The NSA is re-organizing to merge its signals intelligence (attack) and i= nformation assurance (protect) into one unit. The NSA is, by US Law, the of= ficial advisor to NIST on cryptography. NIST has a pretty admirable track re= cord of crypto (exceptions being mostly when they were misled by their offic= ial expert). Things may change now. Or not. YMMV. >> =20 >> https://www.washingtonpost.com/world/national-security/national-security-= agency-plans-major-reorganization/2016/02/02/2a66555e-c960-11e5-a7b2-5a2f824= b02c9_story.html >=20 > IDK. People were complaining before about the attack mission overshadowing= and in fact hurting the protect mission. I don=E2=80=99t see how this makes= it better. Perhaps worse. >=20 >> =E2=80=9CWhen it comes to cyber in particular, the line between collectio= n capabilities=20 >> and our own vulnerabilities =E2=80=94 between the acquisition of signals i= ntelligence=20 >> and the assurance of our own information =E2=80=94 is virtually nonexiste= nt,=E2=80=9D said=20 >> Rep. Adam B. Schiff (Calif.), the ranking Democrat on the House Intellige= nce=20 >> Committee. =E2=80=9CWhat is a vulnerability to be patched at home is ofte= n a potential=20 >> collection opportunity abroad and vice versa.=E2=80=9D >=20 > This sounds so... misguided. >=20 > Yoav >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Apple-Mail-1582B91E-1ECD-4E09-846E-31A36D365EC5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Surely the argument from David Alexand= er from RSA conference 2015 still holds, you need the best people in Offence= to advise behind the scenes moving into talk freely to those in defence. In= the U.K. We have never had the money or resources for both, ( according to T= ony Sale before he died, when everything was one big melting pot in ww2 )After all what has changed since Turing did the assurance analysis of the U= .K./USA telephone link which remained in use, even if his Delilah replacemen= t weighed 59 tons less and was portable!
Best Regards,

Dave


'Certain things are done first= , then said'


On 2 Feb 2016, at 20:48, Yoa= v Nir <ynir.ietf@gmail.com>= wrote:


IDK. People were complaining before about the attack missio= n overshadowing and in fact hurting the protect mission. I don=E2=80=99t see= how this makes it better. Perhaps worse.

=E2=80=9CWhen it= comes to cyber in particular, the line between collection capabilities = ;
and our own vulnerabilities =E2=80=94 between the acquisition of= signals intelligence 
and the assurance of our own informati= on =E2=80=94 is virtually nonexistent,=E2=80=9D said 
Rep. Ad= am B. Schiff (Calif.), the ranking Democrat on the House Intelligence <= /div>
Committee. =E2=80=9CWhat is a vulnerability to be patched at home i= s often a potential 
collection opportunity abroad and vice v= ersa.=E2=80=9D

This sounds so... misguided.

Yoav


______________= _________________________________
saag mailing listsaag@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/saag">https://www.ietf.org/m= ailman/listinfo/saag
= --Apple-Mail-1582B91E-1ECD-4E09-846E-31A36D365EC5-- From nobody Tue Feb 2 16:45:57 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EEA1A03FF for ; Tue, 2 Feb 2016 16:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 MrLm5qTGIhZF for ; Tue, 2 Feb 2016 16:45:51 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A27891ACE69 for ; Tue, 2 Feb 2016 16:45:51 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 4C6852009E; Tue, 2 Feb 2016 19:54:40 -0500 (EST) Received: from obiwan.sandelman.ca (ip6-localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7BE7D637A0; Tue, 2 Feb 2016 19:45:50 -0500 (EST) From: Michael Richardson To: "David S. Misell" In-Reply-To: References: <69adf656430c4230981785b78af76af4@usma1ex-dag1mb1.msg.corp.akamai.com> <29CEA796-1CF8-4CCE-87DA-7FF368E64385@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: "cfrg@irtf.org" , Security Area Advisory Group Subject: Re: [saag] [Cfrg] NSA re-org and its impact X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 00:45:54 -0000 --=-=-= Content-Type: text/plain David S. Misell wrote: > Surely the argument from David Alexander from RSA conference 2015 still > holds, you need the best people in Offence to advise behind the scenes moving > into talk freely to those in defence. In the U.K. We have never had the A systematic series of secondments, liasons and exchanges would accomplish this goal without compromising the priorities of the defense organization. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVrFNu4CLcPvd0N1lAQJxBQgAgdE5y8cKrs3ZyB7JspBbFprrOAX+1hU+ 9iG0Zx7yyXlHGDJr3AIOX9sWJ64jBzcJC3JOy9dPrz/5Vg4mbJ5B1Jfv8kTLcS7E C3Hj0CJmNL+jLEmsuj4uBJYAtdz9kbNmwz9E8T4KSULFJzwId6kOCglbWvMu7VvE Q+V8SOSPLA9XCAPWUNopQJzSu1Yck5l0X1izdkmnqUAjRhDt2itjcIqsokyZyGbU 0Z+1fAyfSyu/10qAGxrsCyQ6uEhKmEZNLs702eEQXdO090YEivME9ntPUhuflKs9 qUaZ7BNV2SlQUvenlORx5qmnsunPLwt73vfuhd6348Ha9zycmIoJew== =Y7kK -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Feb 2 20:21:58 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99E51A026A for ; Tue, 2 Feb 2016 20:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 ubNc43Ezgyln for ; Tue, 2 Feb 2016 20:21:54 -0800 (PST) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EBC41A0270 for ; Tue, 2 Feb 2016 20:21:54 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id q190so2922722ywd.3 for ; Tue, 02 Feb 2016 20:21:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a7NGWW4c16WAQzSGKZuB1OHPettE1+F2txWwbuPHD2A=; b=Hun8sXb6zgp+nxPei4/Ljm6VTaRjLJ+9/fOATNnpgxNp48/IpPsAHTAb3Zyb7MERuc fSna5Y4USXs7UbCCE8C5c+hsCM7pgQI+QGhv3MkEi7bTaJEOm7O6T8qhAG3Re7iEXYpq C6LSuj8jFyLs9GwbkikHyj5tJy3Amq30oPaiyOhGg5Sf17W3mSRLdrGiKFj/6XbabsVE FkOXiEq+vJ8FS+hmo2cwf9aNolbCqHcCzQz+uhjKNx3Z4/Y9os6aJ6ovZZme3WT/0Xk/ 4hBYkfjfrA/ZhDA5rq2gO6MBdnx8wQ9sYFXr+vyEIJL5PhsGVsh6kKpXjniefT5uv8AV gC+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=a7NGWW4c16WAQzSGKZuB1OHPettE1+F2txWwbuPHD2A=; b=KUVeOn5N6M2PyOuDTgmdi9FADnCGPWSLOQ+YLs7HxJqMyeS6jrDcnP7onSdOlZFcWZ oZccBDCmF7Vm8ebQQNz6rT2l4pazsiX4Pywxm+VzLguOuG2fTPFfpG05nMH4QrVuhiWs I+StBwbcSBnUd7eukM17tnBYtvs0woJqsg7N7c9cZAk0+ESQeSprp5kwXquo8n6TjLpU zgm0VnT4jNHXrxeCK8LpSXNDSs2yCJbN7fSA2WKjux8AkcNoE9kvZG5J2+ccgscneXyr lHEFMWE4FdAB+9UGYp7LQOO/2gt38iJ/oYOOjLmtlPiMCiTZCSNG1qRYeLGFshNyv9oG 53eA== X-Gm-Message-State: AG10YOQ5y/7B3g8JHRBWkBONRDB6hCxtWWAnsE2j+TOUG5SHELI03fwqtHXFHRNGpDGJ5k4xlVznPRsZ+VN0ow== MIME-Version: 1.0 X-Received: by 10.129.57.135 with SMTP id g129mr12779521ywa.244.1454473313892; Tue, 02 Feb 2016 20:21:53 -0800 (PST) Received: by 10.13.216.138 with HTTP; Tue, 2 Feb 2016 20:21:53 -0800 (PST) Received: by 10.13.216.138 with HTTP; Tue, 2 Feb 2016 20:21:53 -0800 (PST) In-Reply-To: References: <69adf656430c4230981785b78af76af4@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Tue, 2 Feb 2016 20:21:53 -0800 Message-ID: From: Watson Ladd To: Tony Arcieri Content-Type: multipart/alternative; boundary=001a114c78fe35c285052ad5f504 Archived-At: Cc: cfrg@irtf.org, "saag@ietf.org" Subject: Re: [saag] [Cfrg] NSA re-org and its impact X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 04:21:56 -0000 --001a114c78fe35c285052ad5f504 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 2, 2016 at 7:54 PM, Tony Arcieri wrote: > On Tue, Feb 2, 2016 at 12:14 PM, Salz, Rich wrote: >> >> The NSA is re-organizing to merge its signals intelligence (attack) and >> information assurance (protect) into one unit. The NSA is, by US Law, the >> official advisor to NIST on cryptography. NIST has a pretty admirable track >> record of crypto (exceptions being mostly when they were misled by their >> official expert). Things may change now. Or not. YMMV. > > > At a time when NIST needs to restore trust, it would seem rather unwise for > them to accept any unjustified parameters from the NSA like they did with > Dual_EC_DRBG (and hopefully they prefer well-scrutinized, widely trusted > standards such as the CFRG curves) > > Dual_EC_DRBG was a debacle, but short of the NSA making massive advances > over the public sector in cryptography and therefore being able to hide a > backdoor in plain sight it seems like the sort of trick they can only pull > once... Like putting MD5 into widespread deployment after Dobbartin's 1996 paper? Or Dual EC post 2007? Or continuing to widely use TLS 1.0 post Bard's 2004 attack, and Bodo Mueller's cbc-attacks.txt? Or making IKEv2 and IKEv1 sufficiently baroque that the only widely deployable mode was easily decryptable, then ensuring that VPN makers would tell their clients to enable it. We've know about every public NSA attack on crypto years before it happened. The basic fact is people know things about crypto, and will tell you what to do. And you do them, or you suffer the consequences. And to the extent the IETF can't adapt to that, we need to take the letter E out and replace it with B. > > This is clearly a bad development, but hopefully NIST learned its lesson the > last time around. > > -- > Tony Arcieri > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > -- "Man is born free, but everywhere he is in chains". --Rousseau. --001a114c78fe35c285052ad5f504 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 2, 2016 at 7:54 PM, Tony Arcieri <bascule@gmail.com> wrote:
> On Tue, Feb 2, 2016 at 12:14 PM, Salz, Rich <rsalz@akamai.com> wrote:
>>
>> The NSA is re-organizing to merge its signals intelligence (attack= ) and
>> information assurance (protect) into one unit. The NSA is, by US L= aw, the
>> official advisor to NIST on cryptography. NIST has a pretty admira= ble track
>> record of crypto (exceptions being mostly when they were misled by= their
>> official expert). Things may change now. Or not. YMMV.
>
>
> At a time when NIST needs to restore trust, it would seem rather unwis= e for
> them to accept any unjustified parameters from the NSA like they did w= ith
> Dual_EC_DRBG (and hopefully they prefer well-scrutinized, widely trust= ed
> standards such as the CFRG curves)
>
> Dual_EC_DRBG was a debacle, but short of the NSA making massive advanc= es
> over the public sector in cryptography and therefore being able to hid= e a
> backdoor in plain sight it seems like the sort of trick they can only = pull
> once...

Like putting MD5 into widespread deployment after Dobbartin&= #39;s 1996 paper? Or Dual EC post 2007? Or continuing to widely use TLS 1.0= post Bard's 2004 attack, and Bodo Mueller's cbc-attacks.txt? Or ma= king IKEv2 and IKEv1 sufficiently baroque that the only widely deployable m= ode was easily decryptable, then ensuring that VPN makers would tell their = clients to enable it. We've know about every public NSA attack on crypt= o years before it happened.

The basic fact is people know things about crypto, and will = tell you what to do. And you do them, or you suffer the consequences. And t= o the extent the IETF can't adapt to that, we need to take the letter E= out and replace it with B.

>
> This is clearly a bad development, but hopefully NIST learned its less= on the
> last time around.
>
> --
> Tony Arcieri
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irt= f.org/mailman/listinfo/cfrg
>

--
"Man is born free, but everywhere he is in chains".
--Rousseau.

--001a114c78fe35c285052ad5f504-- From nobody Thu Feb 4 08:01:11 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5C11B3330 for ; Tue, 2 Feb 2016 19:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 ZqtFpzqy9AvJ for ; Tue, 2 Feb 2016 19:55:16 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A41C01B3332 for ; Tue, 2 Feb 2016 19:55:16 -0800 (PST) Received: by mail-ig0-x22b.google.com with SMTP id z14so76931299igp.1 for ; Tue, 02 Feb 2016 19:55:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1KYrnYaSCn9GcN/dbvaniw8fU1rJ+5HDDptr7SHNKy8=; b=0O7SA/NGOO7pjeonPyYR0hw0WNegL4T+mr2piiXn4vUulS50zAJQq25QccgV54TAW3 rkZyy/inqBxmvwGzxN2JNr97t6EDhJ0asvKxnG4IaMvmhKfRZW/rCa5eUyrVNvQuX+/g 0WBF/IeAWoEkSfA2UZTBXi4cqyePfzkaPqB/K+f0wY74HeZ/UZ8gS3+8qewGX98e8C7Y 8S4g5nZrIqlO3eIUHI79Q8zW7TAW3fNVPf0PNaA0r3Nv8AXIyfXq5m+oN6RMOhxnGvkZ 4+/ARlfKummsQhesmTTmqQNbMZJGyS/kPjoIAiQBfyRnANRtWTU2elDcZ1CWwmqs43/e J17Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1KYrnYaSCn9GcN/dbvaniw8fU1rJ+5HDDptr7SHNKy8=; b=gNwufMQp7+CYG8WaWQWYPPM0NpqowAbReJsy8DXYEl8RSGLflg4e7hT3YPFU0cTxqU R9javI5LRrU/9gzauEbPS/R+CSWoDCML4xT8HpJyx+nkhx2ZEKtGE4Nmdax/EQkvcPzh Mz9C2EEXRdIq2GJXbsx9rXzBJmQ2JLUPzui/e7UEG0Ii3TCftdCnB8ItNBntqzP+G3i3 Vhvo9tlDzwwN5uZHW6WEHU1842nhfKSCJQfRyq/0O0J72ZNsH/bal5hmFXFSkJycOQ63 qT6MlqYihwfc0LnxZQgiXMesaQq9x9Y3Zcfm7amuQu2z+CBntVtVRyu/qGOIk3dG66Ld pceQ== X-Gm-Message-State: AG10YOR9aCxK/h80b65g817AQ4/JlaXe5TbnQtsUoQNbK9A/P+NjDT1a3TCapQftePxiVP22kL5PS+zSQz9SSQ== X-Received: by 10.50.67.47 with SMTP id k15mr1444940igt.18.1454471716053; Tue, 02 Feb 2016 19:55:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.124.201 with HTTP; Tue, 2 Feb 2016 19:54:56 -0800 (PST) In-Reply-To: <69adf656430c4230981785b78af76af4@usma1ex-dag1mb1.msg.corp.akamai.com> References: <69adf656430c4230981785b78af76af4@usma1ex-dag1mb1.msg.corp.akamai.com> From: Tony Arcieri Date: Tue, 2 Feb 2016 19:54:56 -0800 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=047d7bd756e8f8aee2052ad595d6 Archived-At: X-Mailman-Approved-At: Thu, 04 Feb 2016 08:01:10 -0800 Cc: "cfrg@irtf.org" , "saag@ietf.org" Subject: Re: [saag] [Cfrg] NSA re-org and its impact X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 03:55:20 -0000 --047d7bd756e8f8aee2052ad595d6 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 2, 2016 at 12:14 PM, Salz, Rich wrote: > The NSA is re-organizing to merge its signals intelligence (attack) and > information assurance (protect) into one unit. The NSA is, by US Law, the > official advisor to NIST on cryptography. NIST has a pretty admirable track > record of crypto (exceptions being mostly when they were misled by their > official expert). Things may change now. Or not. YMMV. > At a time when NIST needs to restore trust, it would seem rather unwise for them to accept any unjustified parameters from the NSA like they did with Dual_EC_DRBG (and hopefully they prefer well-scrutinized, widely trusted standards such as the CFRG curves) Dual_EC_DRBG was a debacle, but short of the NSA making massive advances over the public sector in cryptography and therefore being able to hide a backdoor in plain sight it seems like the sort of trick they can only pull once... This is clearly a bad development, but hopefully NIST learned its lesson the last time around. -- Tony Arcieri --047d7bd756e8f8aee2052ad595d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 2, 2016 at 12:14 PM, Salz, Rich <rsalz@akamai.com> wr= ote:

The NSA is re-organizing to merge its signals intell= igence (attack) and information assurance (protect) into one unit.=C2=A0 Th= e NSA is, by US Law, the official advisor to NIST on cryptography. NIST has= a pretty admirable track record of crypto (exceptions being mostly when they were misled by their official expert). = Things may change now.=C2=A0 Or not.=C2=A0 YMMV.


At a time when NIST needs to restore trust, it would = seem rather unwise for them to accept any unjustified parameters from the N= SA like they did with Dual_EC_DRBG (and hopefully they prefer well-scrutini= zed, widely trusted standards such as the CFRG curves)

=
Dual_EC_DRBG was a debacle, but short of the NSA making massive advanc= es over the public sector in cryptography and therefore being able to hide = a backdoor in plain sight it seems like the sort of trick they can only pul= l once...=C2=A0

This is clearly a bad develo= pment, but hopefully NIST learned its lesson the last time around.

--=C2=A0
Tony Arci= eri
--047d7bd756e8f8aee2052ad595d6-- From nobody Thu Feb 4 08:56:05 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B411B32C8 for ; Thu, 4 Feb 2016 08:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 0O5jdI_jaBua for ; Thu, 4 Feb 2016 08:55:59 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8A81B3023 for ; Thu, 4 Feb 2016 08:55:59 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id CC72B206ABF; Thu, 4 Feb 2016 17:55:55 +0100 (CET) From: Fernando Gont To: "saag@ietf.org" References: <20160204162945.16956.31282.idtracker@ietfa.amsl.com> Message-ID: <56B38293.6000800@si6networks.com> Date: Thu, 4 Feb 2016 13:55:47 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160204162945.16956.31282.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: =?UTF-8?Q?Iv=c3=a1n_Arce?= Subject: [saag] Security and Privacy Implications of Numeric Identifiers Employed in Network Protocols (Fwd: New Version Notification for draft-gont-predictable-numeric-ids-00.txt) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 16:56:03 -0000 Folks, We have published a new IETF I-D entitled "Security and Privacy Implications of Numeric Identifiers Employed in Network Protocols". It sheds light on the security and privacy implications of predictable numeric identifiers, which have affected (and still affect) several IETF protocols for ages, and that in some cases (such as IPv6 IIDs) can be leveraged for pervasive monitoring. The I-D is available here: Your feedback will be appreciated. Thanks! Best regards, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-predictable-numeric-ids-00.txt Date: Thu, 04 Feb 2016 08:29:45 -0800 From: internet-drafts@ietf.org To: Ivan Arce , Fernando Gont A new version of I-D, draft-gont-predictable-numeric-ids-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-predictable-numeric-ids Revision: 00 Title: Security and Privacy Implications of Numeric Identifiers Employed in Network Protocols Document date: 2016-02-04 Group: Individual Submission Pages: 32 URL: https://www.ietf.org/internet-drafts/draft-gont-predictable-numeric-ids-00.txt Status: https://datatracker.ietf.org/doc/draft-gont-predictable-numeric-ids/ Htmlized: https://tools.ietf.org/html/draft-gont-predictable-numeric-ids-00 Abstract: This document performs an analysis of the security and privacy implications of different types of "numeric identifiers" used in IETF protocols, and tries to categorize them based on their interoperability requirements and the assoiated failure severity when such requirements are not met. It describes a number of algorithms that have been employed in real implementations to meet such requirements and analyzes their security and privacy properties. Additionally, it provides advice on possible algorithms that could be employed to satisfy the interoperability requirements of each identifier type, while minimizing the security and privacy implications, thus providing guidance to protocol designers and protocol implementers. Finally, it provides recommendations for future protocol specifications regarding the specification of the aforementioned numeric identifiers. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Fri Feb 5 03:58:59 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B572B1B3757 for ; Fri, 5 Feb 2016 03:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 OIiFPe4NYpvt for ; Fri, 5 Feb 2016 03:58:57 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A8FB1B3750 for ; Fri, 5 Feb 2016 03:58:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0053ABE3F for ; Fri, 5 Feb 2016 11:58:55 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1numnMNe2X_y for ; Fri, 5 Feb 2016 11:58:55 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7FFEDBDCC for ; Fri, 5 Feb 2016 11:58:55 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1454673535; bh=E+0HPS461uuf3bjagdlnMBuxeJpa2yRQmeOMtZDMPls=; h=Subject:References:To:From:Date:In-Reply-To:From; b=0S6V1oBaXFLIYqF1rWMDjcjusjuxdhSAIlFYLqjUAtpgk5bwc9FEuVXvdY88j7zei oOcI04o4vvjVMZUaC7298jc1oNZLNFGuaGnUweqO4d4DQGJWmSB1i1NI6Ih9GGKBEk G4U3wGn1HTu0H+gqVCtyNlYBFDIPO8+dD8bNyXa4= References: <56B48DED.5080202@cs.tcd.ie> To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <56B48DED.5080202@cs.tcd.ie> Message-ID: <56B48E7D.30309@cs.tcd.ie> Date: Fri, 5 Feb 2016 11:58:53 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B48DED.5080202@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] Fwd: [pkix] Is it time for a pkix extensions (or similar) wg? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 11:58:58 -0000 FYI, please respond on the pkix list [1] if you've things to say, Thanks, S. [1] https://www.ietf.org/mailman/listinfo/pkix -------- Forwarded Message -------- Subject: [pkix] Is it time for a pkix extensions (or similar) wg? Date: Fri, 5 Feb 2016 11:56:29 +0000 From: Stephen Farrell To: pkix Hiya, We seem to be seeing a number of drafts that folks are writing that define new certificate extensions or that want to update/modify PKIX specs. Do folks think it is now time to form a working group to process those? If no, please say why. If yes, please say what draft(s) and propose any other scoping. If you know of people who are or would implement and deploy, that is very useful information. (It is fine to say "I think we should work on topic " but it is *much* better if you can point at a draft you've written about and say that you or someone is implementing that and that it'll get deployed.) If you think this requires face to face discussion at IETF95 (e.g. to tease out scope) please say that too. We still have a couple of weeks before the BoF deadline and if a short session is needed that can be arranged. Note though that there is no need to have such a BoF session to form a WG, if everything is clear already. FWIW, my impression is that we do seem to have a handful of drafts where folks seem willing to do the work and where the work might be (or has been) implemented. So if there's enough interest, I'd be supportive of forming a (hopefully:-) short-lived, tightly scoped, WG to handle that work. Cheers, S. _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From nobody Fri Feb 5 08:03:03 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819981B3AD1 for ; Fri, 5 Feb 2016 08:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 N6ZM-1H5hPcE for ; Fri, 5 Feb 2016 08:03:00 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ADBE1B3AC8 for ; Fri, 5 Feb 2016 08:03:00 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id j78so60088470lfb.1 for ; Fri, 05 Feb 2016 08:03:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=hAPG3FJJ8KBdYEFyIQemqJXFJxlotvXPlBEsVIkKtPc=; b=z+We9MPyfefKv0/opDoHGdzkdHudbmhjJdK1JoUVn8jzOc/JONEumaqafckl0AePOE jAYhf/8Q70tP3PXn/Uni6tjgAj51q323RrUqIR5M9RWbUAuJcs/UnEUb6D9POaKh5YkW 4I2c0OkEmDpjLQfroFfBtl+LwksLk1I9jv1AR0WocO1TbXtBTX60TDwZ6vlR/PAitwBq 68kqIE3ekGygdAlzFUEL82poM/HNOI4ExZir7lPBm5RTyX9WFObs9jU2mxeuodi0aR82 0EVJF74SloDziaoBSOujdB0m2hY8cTFC6ZF/eC/RP384eXCIhJrUWOderbXoDaa5kGur GFMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=hAPG3FJJ8KBdYEFyIQemqJXFJxlotvXPlBEsVIkKtPc=; b=conquWTArU0CPaG76b1xost+RR2l2Ldsbsbtp07UTkETiCiCqJL/Np1DSPsmrFZOCm SaDf7G1i1k9qQXL6Hbvw5n7izCUBNAF6o/4y3+fmzAkald5OSqg8SmbhCtOVIKwWRp1s mSmojE5rr0a+kndno4vBEWIoiEpKnlYnmKSptGWKujVCfoLU2IAPUKAVHYR7WJ0Xjcy4 kYARtSbOE5w8p0cGggSq2mrK6BO7K2CDALwaU08xMEVLF9pR1VLMuQI+NDBLAKQVGMgP e0Eaqr3LRsKEdqAZnkQVZQs0pnlnmUsHbDx5/pCyKhHKIYX4vcsEzWEaAwDkPGjyYtx7 zP5g== X-Gm-Message-State: AG10YOQ8K1BKo2gacZi86jVvZBjkEEuUObDVIsYwNbRObMZNXMSmgBhA+6gN+Qz3AESm5dCbubNrybNMoXt4Vg== MIME-Version: 1.0 X-Received: by 10.25.168.15 with SMTP id r15mr5313504lfe.166.1454688178337; Fri, 05 Feb 2016 08:02:58 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.49.80 with HTTP; Fri, 5 Feb 2016 08:02:58 -0800 (PST) Date: Fri, 5 Feb 2016 11:02:58 -0500 X-Google-Sender-Auth: 5j_nsMPDrQQhzGXYAhoQ5dh8d80 Message-ID: From: Phillip Hallam-Baker To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [saag] The Mathematical Mesh X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 16:03:02 -0000 Project Website: PrismProof.org The project WebSite has links to the GitHub repository (MIT License), the Internet Drafts and podcasts demonstrating the Mesh in use. As most of you know, for the past couple of years I have been working on a way to do secure email in a completely painless manner. It should be exactly as easy to send secure mail as insecure. When you are starting your car you do not need to remember to press the button marked 'do not explode'. But that is what we demand of users when we require them to click the 'encrypt message' button to do S/MIME or OpenPGP. I did a demo of that scheme 18 months ago. Since then I have been looking at the problem of how to persuade people to change to a new email infrastructure. My conclusion being that secure email isn't going to be enough. The only way we are going to get a billion people using secure Internet applications is if doing so makes using the computer easier. This seemed like an impossible challenge until I realized that: 1) Most users have multiple devices these days 2) Configuring devices is fiddly and complex enough without cryptography 3) We can use strong end-to-end cryptography to make the process of transferring configurations from one device to another very, very easy. 4) Manufacturers make money by selling more devices to existing customers. Anything that makes it easier for a potential customer to part with their cash is going to be interesting to a large number of vendors. The breakthrough came when I realized that instead of just putting a user's S/MIME and OpenPGP keys into a profile, we could put all the configuration data for email into a profile. So when Alice buys a new laptop, she can configure it to use all her email, instant messaging, VOIP, VPN, SSH, etc. etc. accounts in one go. For years, the IETF has had the attitude 'we don't do UI'. Well maybe that is the right approach after all because most times if you are presenting the user with UI, you are doing it wrong. The Mesh allows all the configuration decisions a user has to make to be gathered into one place and administered from there. I can manage my 3 laptops, 4 desktops, 2 phones, 4 tablets and the watch from one machine. There are of course obvious applications of this approach to IoT. The biggest challenge in IoT is how to connect to the user's 'management console' which currently doesn't exist. There are obvious enterprise applications as well. But I think we need to build up experience of using the mesh in standalone mode before going down those paths. I chose secure email because it is the hardest problem to solve. If I can configure a machine to use the S/MIME built into the current release of Windows Live Mail and Outlook without the user having to think about the process, we can support pretty much any application protocol. In particular: * Web password manager, * SSH configuration * OpenPGP * VPN configuration I have 100s of Web site accounts, most of which have the same weak password because I don't actually care about them. Yes, there are many proprietary password managers but I really wouldn't ever use them for anything I relied on because I don't know how they are secured, I can't audit them. SSH is easy to congiure insecurely, thust create one keypair and copy it to every machine. Using SSH with separate keys on each machine is a lot more involved. And it is a hard bootstrap problem because you are trying to configure a machine to do things securely before you have security. Most people I know who do this right and have separate keys on every machine and rotate them regularly do so with custom written scripts. I would much rather trust a reviewed standards based protocol than a script. OpenPGP is of course one of the applications that must be supported. I don't support it right now because configuring closed source applications is actually the harder test. VPN configuration is something that should have been solved long ago but has not. Every corporate VPN I have used has required me to use a proprietary or add-in client for access. Which is really strange when Windows and OSX ship with IPSec built in. Configuring a VPN as a remote user is absolutely no fun at all. It requires multiple emails and phone calls and even then may not work at all. The Mathematical Mesh is an untrusted cloud service that supports two principal functions: 1) A place for users to store encrypted configuration 'profiles' for their accounts and applications. 2) An infrastructure through which they can publish public aspects of that profile to allow others to interact with them. At present we are focusing on applications that only require the first function. But the architecture of the Mesh is mostly designed to meet the requirements of the second. The Mesh does not offer any confidentiality guarantees, in fact it is assumed that all the bits that are published to the Mesh are made public: We distrust governments, corporations and users. We believe in strong cryptography and secret keys. Currently all the data in the Mesh is encrypted under RSA2048 and AES256. That will change to CFRD448 when the spec is fully baked and code is available. As with DNS, it is of course possible to run the Mesh in a completely stand-alone fashion. But if you want to be able to communicate with anyone at all, you want your data to be available to anyone at all. That is the role of the Inter-Mesh. So my email Users access the Inter-Mesh through a portal provider. These providers act as abuse filters for the Mesh. That is important because the Mesh runs as a blockchain: every byte that is added to the Mesh must remain there in perpetuity. There are ways to avoid someone deliberately tainting the Mesh logs with kiddie porn or other prohibited material. But if a user is allowed to to a billion transactions in an hour, there is going to be a few gigs of transaction log that have to be maintained forever. A user can change their portal provider at any time however. There is no 'lock in' effect. Each mesh user has a master profile that can in principle be used their entire life. This profile has a master key that is used to sign updates to the master profile. The master profile then signs an administrative profile which in turn... In short, there is a lot of crypto going on. And each one of those crypto steps is used to meet a very specific user requirement. One of the big mistakes in traditional PKI was to think that some features are for 'experts'. Key escrow for example, you want to be able to get your data back if a machine fails. So key escrow has to be offered as an option. But isn't the novice user at least as likely to blow up their machine config and lose all their data as an 'expert'. In fact using crypto *without* escrow is the thing that should be left to the experts. We could not have done something like the Mesh in 1995. Each user has a personal PKI with four levels. In 2016 that is no burden at all even with RSA2048 and it is even faster with CFRG448. The Mesh provides for recovery of the user's private key. User's are not required to use this feature but it is recommended. I do have material that I would rather lose than have disclosed. But I would rather the vast majority of my data was disclosed than risk losing it. So I use escrow keys knowing that there is some risk of being coerced to disclose. Next Steps I believe that at minimum, the Mesh proves that we can make computers easier to use and give them strong cryptography at the same time. My approach may not be the best one but if people have a better idea, I am more than willing to discuss it. What should we do next? Given the timing, I am thinking that a bar BOF in Buenos Aires is the best approach. And then we can consider whatever we want to do next. From nobody Mon Feb 8 07:34:01 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5871B2D41; Mon, 8 Feb 2016 07:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 fwK1RIRlSCIg; Mon, 8 Feb 2016 07:33:57 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CDE81B2D3E; Mon, 8 Feb 2016 07:33:56 -0800 (PST) X-AuditID: c1b4fb2d-f78fe6d00000163a-ba-56b8b5628d32 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id FB.F4.05690.265B8B65; Mon, 8 Feb 2016 16:33:54 +0100 (CET) Received: from nomadiclab.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.3.248.2; Mon, 8 Feb 2016 16:33:53 +0100 Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 41D774EF83; Mon, 8 Feb 2016 17:36:12 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9A8D74E9B6; Mon, 8 Feb 2016 17:36:11 +0200 (EET) From: Mohit Sethi To: , References: <20160208123035.1562.80507.idtracker@ietfa.amsl.com> Message-ID: <56B8B561.8040300@ericsson.com> Date: Mon, 8 Feb 2016 17:33:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160208123035.1562.80507.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyM2K7vW7S1h1hBm2blS2OrV/LYjGlv5PJ 4s3EjewOzB7HXy9m9Viy5CdTAFMUl01Kak5mWWqRvl0CV8bKe/UF56Uquq52MzcwzhHtYuTk kBAwkfhwdw87hC0mceHeerYuRi4OIYHDjBKzO9exgSSEBLYySjzaqgWRWMso8fJwPwuEM49R YsqBhWDtbAJ6Ep3njjN3MXJwCAu4Ssw/YgsSFhFQluhacp8ZYpCDxP6785lAbGYBKYkXZ9+C LeAV0JY4uH0+WA2LgIrEmalvwEaKCkRIHO7sYoeoEZQ4OfMJC4jNKeAosWD1aqg5FhIz559n hLDlJZq3zmaG+EZN4uq5TVB71SW2dhxgnMAoMgvJqFlI2mchaV/AyLyKUbQ4tbg4N93IWC+1 KDO5uDg/Ty8vtWQTIzACDm75rbuDcfVrx0OMAhyMSjy8BlO2hwmxJpYVV+YeYpTgYFYS4d3R uyNMiDclsbIqtSg/vqg0J7X4EKM0B4uSOO8a5/VhQgLpiSWp2ampBalFMFkmDk6pBsYZLz6X rpyaM8d0QtfpRcu2Hrp46tv6uc676xey22WyHntx+tf5tvuXbpWHBj7iyl/cL7x07s7AgB8t B5eGPd5j32v9LSL+7X0mh3DXy+5X22bIqFSuqEtrqb3s8NTmhkXxZfu1sWK1533LDKyLnD3n BW6Ql0hvfBR9+ZOSZWaNt6PkzfR5Vs1KLMUZiYZazEXFiQDKOkxLfAIAAA== Archived-At: Cc: tuomas.aura@aalto.fi Subject: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 15:33:58 -0000 Dear all We have just submitted a new IETF Draft titled “Nimble out-of-band authentication for EAP (EAP-NOOB)â€. The draft defines an EAP method where the authentication is based on a user-assisted out-of-band (OOB) channel between the server and peer. It is intended as a generic bootstrapping solution for Internet-of-Things devices which have no pre-configured authentication credentials and which are not yet registered on the authentication server. Consider devices you just bought or borrowed. The EAP-NOOB method is more generic than most ad-hoc bootstrapping solutions in that it supports many types of OOB channels. We specify the exact in-band messages but only the OOB message contents and not the OOB channel details. Also, EAP-NOOB supports ubicomp devices with only output (e.g. display) or only input (e.g. camera). Moreover, it makes combined use of both secrecy and integrity of the OOB channel for more robust security than the ad-hoc solutions. We have put a lot of effort into designing a robust security protocol. For one application example, we have used an earlier version of the protocol for bootstrapping security for ubiquitous displays: the user can configure wireless network access, link the device to a cloud service, and register ownership of the device for a specific cloud user – all in one simple step of scanning a QR code with a smart phone. There seemed to more potential to this idea than just using it for our own system, and thus we decided to write a generic EAP method for out-of-band authentication. The draft is available here: https://tools.ietf.org/html/draft-aura-eap-noob-00 Please see if you can make use of it. We look forward to your feedback and comments. Regards /--Mohit -------- Forwarded Message -------- Subject: New Version Notification for draft-aura-eap-noob-00.txt Date: Mon, 08 Feb 2016 04:30:35 -0800 From: internet-drafts@ietf.org To: Tuomas Aura , Mohit Sethi A new version of I-D, draft-aura-eap-noob-00.txt has been successfully submitted by Tuomas Aura and posted to the IETF repository. Name: draft-aura-eap-noob Revision: 00 Title: Nimble out-of-band authentication for EAP (EAP-NOOB) Document date: 2016-02-08 Group: Individual Submission Pages: 35 URL:https://www.ietf.org/internet-drafts/draft-aura-eap-noob-00.txt Status:https://datatracker.ietf.org/doc/draft-aura-eap-noob/ Htmlized:https://tools.ietf.org/html/draft-aura-eap-noob-00 Abstract: Extensible Authentication Protocol (EAP) [RFC3748] provides support for multiple authentication methods. This document defines the EAP- NOOB authentication method for nimble out-of-band (OOB) authentication and key derivation. This EAP method is intended for bootstrapping all kinds of Internet-of-Things (IoT) devices that have a minimal user interface and no pre-configured authentication credentials. The method makes use of a user-assisted one-directional OOB channel between the peer device and authentication server. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Feb 11 12:59:17 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4E51B3A67 for ; Thu, 11 Feb 2016 12:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 DuFSiXIoJMky for ; Thu, 11 Feb 2016 12:59:00 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 269DF1B3A5B for ; Thu, 11 Feb 2016 12:59:00 -0800 (PST) Received: by mail-pa0-x236.google.com with SMTP id ho8so34653335pac.2 for ; Thu, 11 Feb 2016 12:59:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:message-id:subject:mime-version:content-type; bh=KLcRtS0jR6AGotWcu4ksmU/xnCB+W4536ESCfkkW3cA=; b=I3gNpBHRs77XQREO53TF3YMlHMI2UDXU8DtHnTPy+3B+GIOMIamM+mqY7bBRhfpycn qsoged803mTQ0COiMgrOimh6V4/7YPC+x56nCVIZ8vt4C9GQFAejkalWtTswlrnS5ia0 4nYxGQ5lIJ9cudLH3d1LsAZWVrK5dLW+qXN0plBk/NNeRcbFtxKz6RJxdJDoSjZxRV6S U/kETGfOVsj6Ijkl/b1yYeYg7H1tHYHa71OxktFqa/0jOGsgw/ppygeOQB9wd1aRNAd9 hRMmquCQjPUBnVZwX93j6SFrUctGn4LbfCOtc+aKxJhicgr+jo7aS73xpOmPb3t6MUpr zoIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:message-id:subject :mime-version:content-type; bh=KLcRtS0jR6AGotWcu4ksmU/xnCB+W4536ESCfkkW3cA=; b=cpHnKuUNBYE859OopiRk77H67gIGnAQJu+//N8zmB1GhFEvb/H/ylL2x2PM7YQaH+f ZD7kFApXDjKVKuXfrG3YrdnFPk1Rhajsuc7p5LD0qSSwR79M9vUY4jsGoPgVtr4FBXI5 fMRFzrZyVMXO8H+6o5idIJQDCepPDI4aSxdT6C6VLYcmDAOYkHqisj2W9rUetD/VbhGC qsefHDvwMZijhef0+FU0sYZ9eaZrqQkpchpTTrVizMvk+c4st20AHCyakfwl3IYaeBHK o2d4XSWLMLesc4S3A0Pi64XEDBBnLS8ofJOA61UWizpfr1H+KTicmxvFL8EPUhDIU5/r DpzA== X-Gm-Message-State: AG10YORefUd8+YQdfxDP8v8W+H/TivRikdFOvpXfRmrgAUOW4Kj51BK/S4LUfjsjAabf7g== X-Received: by 10.66.65.109 with SMTP id w13mr69057566pas.142.1455224339792; Thu, 11 Feb 2016 12:58:59 -0800 (PST) Received: from mail.outlook.com (ec2-52-24-139-88.us-west-2.compute.amazonaws.com. [52.24.139.88]) by smtp.gmail.com with ESMTPSA id cq4sm14319612pad.28.2016.02.11.12.58.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Feb 2016 12:58:57 -0800 (PST) Sender: Phillip Hallam-Baker Date: Thu, 11 Feb 2016 20:58:55 +0000 (UTC) From: Phillip Hallam-Baker To: Message-ID: <994C5976EA09B556.0243D8F2-BB03-49A4-96A6-34A1025D409A@mail.outlook.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_10550_1149538089.1455224335939" X-Mailer: Outlook for iOS and Android Archived-At: Subject: [saag] Public key based mechanism for SASL X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 20:59:07 -0000 ------=_Part_10550_1149538089.1455224335939 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The Mathematical Mesh makes it really easy to manage public key pairs for end user authentication. Currently I am using it to manage S/MIME and OpenPGP key pairs. However, the authentication to the mail client is still via SASL and right now, none of the mail clients I am aware of do anything other than password auth. And many of them only support broken, insecure mechanisms. Ugh! Given that I can easily generate and associate a unique key pair to each device, the obvious step is to use PKI for authentication. SASL certainly should be able to support this but before I invent something, I thought I would check to see if I was re-inventing the wheel. The constraints I was thinking of were: 1) Based on Diffie Hellman problem (for EC compatibility)2) Use client and server nonces to defeat MITM attacks. Obviously has to be unencumbered. Sent from Outlook Mobile ------=_Part_10550_1149538089.1455224335939 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The Mathematical Mesh makes it really easy to manage public key pairs = for end user authentication. Currently I am using it to manage S/MIME and O= penPGP key pairs.

However, the authentication to t= he mail client is still via SASL and right now, none of the mail clients I = am aware of do anything other than password auth. And many of them only sup= port broken, insecure mechanisms. Ugh!

Given that = I can easily generate and associate a unique key pair to each device, the o= bvious step is to use PKI for authentication. SASL certainly should be able= to support this but before I invent something, I thought I would check to = see if I was re-inventing the wheel.


The constraints I was thinking of were:

1) Based= on Diffie Hellman problem (for EC compatibility)
2) Use client a= nd server nonces to defeat MITM attacks.

Obviously= has to be unencumbered.

------=_Part_10550_1149538089.1455224335939-- From nobody Sun Feb 14 23:31:02 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F111A6F8F; Sun, 14 Feb 2016 23:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 mzxwPR9xvMDc; Sun, 14 Feb 2016 23:30:58 -0800 (PST) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id EAEC81A6F93; Sun, 14 Feb 2016 23:30:55 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DPAQBPfMFW/wQXEqxVCYQMbboZAQ2BZxcBCYVsAhyBQxQBAQEBAQEBgQqEQQEBAQQBAQEgSwkCEAsHBgQDAQIoAwICAiUfCQgGCwgbiA2saQEBAWWOMAEBAQEBAQEBAgEBAQEBAQEBGIRoZ4R3hAkRLgoNghs4E4EnBY0nc4hfgTuEFIliSoN5iFWOPh4BAYQtYgGIdwEBAQ X-IPAS-Result: A2DPAQBPfMFW/wQXEqxVCYQMbboZAQ2BZxcBCYVsAhyBQxQBAQEBAQEBgQqEQQEBAQQBAQEgSwkCEAsHBgQDAQIoAwICAiUfCQgGCwgbiA2saQEBAWWOMAEBAQEBAQEBAgEBAQEBAQEBGIRoZ4R3hAkRLgoNghs4E4EnBY0nc4hfgTuEFIliSoN5iFWOPh4BAYQtYgGIdwEBAQ X-IronPort-AV: E=Sophos;i="5.22,449,1449513000"; d="scan'208";a="52626986" In-Reply-To: <56B8B561.8040300@ericsson.com> References: <20160208123035.1562.80507.idtracker@ietfa.amsl.com> <56B8B561.8040300@ericsson.com> To: Mohit Sethi MIME-Version: 1.0 X-KeepSent: 7E755D92:2E628249-65257F5A:00275705; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 Message-ID: From: Abhijan Bhattacharyya Date: Mon, 15 Feb 2016 13:00:47 +0530 X-MIMETrack: Serialize by Router on INKOLM102/TCS(Release 9.0.1FP4HF528 | October 8, 2015) at 02/15/2016 13:00:48, Serialize complete at 02/15/2016 13:00:48 Content-Type: multipart/alternative; boundary="=_alternative 002945D865257F5A_=" Archived-At: Cc: "'core@ietf.org'" , "'t2trg@irtf.org'" , saag@ietf.org, tuomas.aura@aalto.fi, emu@ietf.org Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 07:31:00 -0000 This is a multipart message in MIME format. --=_alternative 002945D865257F5A_= MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTW9oaXQsDQpJIHdhcyBnb2luZyB0aHJvdWdoIHlvdXIgZHJhZnQuIExvb2tzIHRvIGJlIGEg cHJvbWlzaW5nIHByb3Bvc2l0aW9uLiANCkhvd2V2ZXIsIEkgaGF2ZSBnb3QgYSBmZXcgcXVlc3Rp b25zIGZpcnN0IGhhbmQuDQoNClRoZSBhdXRoZW50aWNhdG9yIGFjdHMgYXMgYSB0cmFuc3BhcmVu dCBub2RlIGFuZCBmb3J3YXJkcyB0aGUgcGFja2V0cyB0byANCnRoZSBzZXJ2ZXIgc29vbiBhZnRl ciB0aGUgZmlyc3QgbWVzc2FnZSBmb3IgRUFQIElkZW50aXR5IHJlcXVlc3QuIEluIGEgDQp0eXBp Y2FsIG5ldHdvcmsgd291bGQgYSBzaW5nbGUgYXV0aGVudGljYXRvciBtYXAgdG8gc2V2ZXJhbCBz ZXJ2ZXJzIG9yIHRoZSANCmFzc3VtcHRpb24gaXMgdGhhdCB0aGVyZSBpcyBhbHdheXMgb25lIHRv IG9uZSBtYXBwaW5nIGJldHdlZW4gc2VydmVyIGFuZCANCmF1dGhlbnRpY2F0b3I/IA0KDQpIb3cg ZG9lcyB0aGUgYXV0aGVudGljYXRvciBhc3NvY2lhdGUgaXRzZWxmIHRvIHRoZSBzZXJ2ZXIgYXQg dGhlIGZpcnN0IA0KcGxhY2U/DQoNCldoYXQgaXMgdGhlIGFzc3VtcHRpb24gcmVnYXJkaW5nIHRo ZSAgdW5kZXJseWluZyBwaHlzaWNhbCBuZXR3b3JrIGFuZCBob3cgDQp0aGUgYXV0aGVudGljYXRv ciBtYXBzIHRvIHRoZSBkaWZmZXJlbnQgbm9kZXMgaW4gdGhlIG5ldHdvcmsgKGUuZy4gYSANCnJv dXRlciBpbiBhIFdpRmkgbGlrZSBzZXR1cCk/DQoNClJlZ2FyZHMNCkFiaGlqYW4gQmhhdHRhY2hh cnl5YQ0KQXNzb2NpYXRlIENvbnN1bHRhbnQNClNjaWVudGlzdCwgSW5ub3ZhdGlvbiBMYWIsIEtv bGthdGEsIEluZGlhDQpUYXRhIENvbnN1bHRhbmN5IFNlcnZpY2VzDQpNYWlsdG86IGFiaGlqYW4u YmhhdHRhY2hhcnl5YUB0Y3MuY29tDQpXZWJzaXRlOiBodHRwOi8vd3d3LnRjcy5jb20NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpFeHBlcmllbmNlIGNlcnRh aW50eS4gICBJVCBTZXJ2aWNlcw0KICAgICAgICAgICAgICAgICAgICAgICAgQnVzaW5lc3MgU29s dXRpb25zDQogICAgICAgICAgICAgICAgICAgICAgICBDb25zdWx0aW5nDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KDQpGcm9tOiAgIE1vaGl0IFNl dGhpIDxtb2hpdC5tLnNldGhpQGVyaWNzc29uLmNvbT4NClRvOiAgICAgPHNhYWdAaWV0Zi5vcmc+ LCA8ZW11QGlldGYub3JnPg0KQ2M6ICAgICB0dW9tYXMuYXVyYUBhYWx0by5maQ0KRGF0ZTogICAw Mi8wOC8yMDE2IDA5OjEwIFBNDQpTdWJqZWN0OiAgICAgICAgW3NhYWddIEZ3ZDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciANCmRyYWZ0LWF1cmEtZWFwLW5vb2ItMDAudHh0DQpTZW50IGJ5 OiAgICAgICAgInNhYWciIDxzYWFnLWJvdW5jZXNAaWV0Zi5vcmc+DQoNCg0KDQpEZWFyIGFsbA0K DQpXZSBoYXZlIGp1c3Qgc3VibWl0dGVkIGEgbmV3IElFVEYgRHJhZnQgdGl0bGVkIOKAnE5pbWJs ZSBvdXQtb2YtYmFuZCANCmF1dGhlbnRpY2F0aW9uIGZvciBFQVAgKEVBUC1OT09CKeKAnS4NCg0K VGhlIGRyYWZ0IGRlZmluZXMgYW4gRUFQIG1ldGhvZCB3aGVyZSB0aGUgYXV0aGVudGljYXRpb24g aXMgYmFzZWQgb24gYSANCnVzZXItYXNzaXN0ZWQgb3V0LW9mLWJhbmQgKE9PQikgY2hhbm5lbCBi ZXR3ZWVuIHRoZSBzZXJ2ZXIgYW5kIHBlZXIuIEl0IA0KaXMgaW50ZW5kZWQgYXMgYSBnZW5lcmlj IGJvb3RzdHJhcHBpbmcgc29sdXRpb24gZm9yIEludGVybmV0LW9mLVRoaW5ncyANCmRldmljZXMg d2hpY2ggaGF2ZSBubyBwcmUtY29uZmlndXJlZCBhdXRoZW50aWNhdGlvbiBjcmVkZW50aWFscyBh bmQgDQp3aGljaCBhcmUgbm90IHlldCByZWdpc3RlcmVkIG9uIHRoZSBhdXRoZW50aWNhdGlvbiBz ZXJ2ZXIuIENvbnNpZGVyIA0KZGV2aWNlcyB5b3UganVzdCBib3VnaHQgb3IgYm9ycm93ZWQuDQoN ClRoZSBFQVAtTk9PQiBtZXRob2QgaXMgbW9yZSBnZW5lcmljIHRoYW4gbW9zdCBhZC1ob2MgYm9v dHN0cmFwcGluZyANCnNvbHV0aW9ucyBpbiB0aGF0IGl0IHN1cHBvcnRzIG1hbnkgdHlwZXMgb2Yg T09CIGNoYW5uZWxzLiBXZSBzcGVjaWZ5IHRoZSANCmV4YWN0IGluLWJhbmQgbWVzc2FnZXMgYnV0 IG9ubHkgdGhlIE9PQiBtZXNzYWdlIGNvbnRlbnRzIGFuZCBub3QgdGhlIE9PQiANCmNoYW5uZWwg ZGV0YWlscy4gQWxzbywgRUFQLU5PT0Igc3VwcG9ydHMgdWJpY29tcCBkZXZpY2VzIHdpdGggb25s eSANCm91dHB1dCAoZS5nLiBkaXNwbGF5KSBvciBvbmx5IGlucHV0IChlLmcuIGNhbWVyYSkuIE1v cmVvdmVyLCBpdCBtYWtlcyANCmNvbWJpbmVkIHVzZSBvZiBib3RoIHNlY3JlY3kgYW5kIGludGVn cml0eSBvZiB0aGUgT09CIGNoYW5uZWwgZm9yIG1vcmUgDQpyb2J1c3Qgc2VjdXJpdHkgdGhhbiB0 aGUgYWQtaG9jIHNvbHV0aW9ucy4gV2UgaGF2ZSBwdXQgYSBsb3Qgb2YgZWZmb3J0IA0KaW50byBk ZXNpZ25pbmcgYSByb2J1c3Qgc2VjdXJpdHkgcHJvdG9jb2wuDQoNCkZvciBvbmUgYXBwbGljYXRp b24gZXhhbXBsZSwgd2UgaGF2ZSB1c2VkIGFuIGVhcmxpZXIgdmVyc2lvbiBvZiB0aGUgDQpwcm90 b2NvbCBmb3IgYm9vdHN0cmFwcGluZyBzZWN1cml0eSBmb3IgdWJpcXVpdG91cyBkaXNwbGF5czog dGhlIHVzZXIgDQpjYW4gY29uZmlndXJlIHdpcmVsZXNzIG5ldHdvcmsgYWNjZXNzLCBsaW5rIHRo ZSBkZXZpY2UgdG8gYSBjbG91ZCANCnNlcnZpY2UsIGFuZCByZWdpc3RlciBvd25lcnNoaXAgb2Yg dGhlIGRldmljZSBmb3IgYSBzcGVjaWZpYyBjbG91ZCB1c2VyIA0K4oCTIGFsbCBpbiBvbmUgc2lt cGxlIHN0ZXAgb2Ygc2Nhbm5pbmcgYSBRUiBjb2RlIHdpdGggYSBzbWFydCBwaG9uZS4gVGhlcmUg DQpzZWVtZWQgdG8gbW9yZSBwb3RlbnRpYWwgdG8gdGhpcyBpZGVhIHRoYW4ganVzdCB1c2luZyBp dCBmb3Igb3VyIG93biANCnN5c3RlbSwgYW5kIHRodXMgd2UgZGVjaWRlZCB0byB3cml0ZSBhIGdl bmVyaWMgRUFQIG1ldGhvZCBmb3IgDQpvdXQtb2YtYmFuZCBhdXRoZW50aWNhdGlvbi4NCg0KVGhl IGRyYWZ0IGlzIGF2YWlsYWJsZSBoZXJlOg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWF1cmEtZWFwLW5vb2ItMDANCg0KUGxlYXNlIHNlZSBpZiB5b3UgY2FuIG1ha2UgdXNlIG9m IGl0LiBXZSBsb29rIGZvcndhcmQgdG8geW91ciBmZWVkYmFjayANCmFuZCBjb21tZW50cy4NCg0K UmVnYXJkcw0KLy0tTW9oaXQNCg0KDQotLS0tLS0tLSBGb3J3YXJkZWQgTWVzc2FnZSAtLS0tLS0t LQ0KU3ViamVjdDogICAgICAgICAgICAgICAgIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig DQpkcmFmdC1hdXJhLWVhcC1ub29iLTAwLnR4dA0KRGF0ZTogICAgICAgICAgICBNb24sIDA4IEZl YiAyMDE2IDA0OjMwOjM1IC0wODAwDQpGcm9tOiAgICAgICAgICAgIGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZw0KVG86ICAgICAgICAgICAgICBUdW9tYXMgQXVyYSA8dHVvbWFzLmF1cmFAYWFsdG8u Zmk+LCBNb2hpdCBTZXRoaSANCjxtb2hpdEBwaXVoYS5uZXQ+DQoNCg0KDQpBIG5ldyB2ZXJzaW9u IG9mIEktRCwgZHJhZnQtYXVyYS1lYXAtbm9vYi0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxs eSBzdWJtaXR0ZWQgYnkgVHVvbWFzIEF1cmEgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3Np dG9yeS4NCg0KTmFtZTogICAgICAgICAgICAgICAgICAgICAgICAgICAgZHJhZnQtYXVyYS1lYXAt bm9vYg0KUmV2aXNpb246ICAgICAgICAgICAgICAgIDAwDQpUaXRsZTogICAgICAgICAgICAgICAg ICAgICAgICAgICBOaW1ibGUgb3V0LW9mLWJhbmQgYXV0aGVudGljYXRpb24gZm9yIEVBUCANCihF QVAtTk9PQikNCkRvY3VtZW50IGRhdGU6ICAgICAgICAgICAyMDE2LTAyLTA4DQpHcm91cDogICAg ICAgICAgICAgICAgICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAg ICAgICAgICAgICAgICAgICAgICAgIDM1DQpVUkw6aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWF1cmEtZWFwLW5vb2ItMDAudHh0DQpTdGF0dXM6aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYXVyYS1lYXAtbm9vYi8NCkh0bWxpemVkOmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hdXJhLWVhcC1ub29iLTAwDQoNCg0KQWJzdHJh Y3Q6DQogICAgRXh0ZW5zaWJsZSBBdXRoZW50aWNhdGlvbiBQcm90b2NvbCAoRUFQKSBbUkZDMzc0 OF0gcHJvdmlkZXMgc3VwcG9ydA0KICAgIGZvciBtdWx0aXBsZSBhdXRoZW50aWNhdGlvbiBtZXRo b2RzLiAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBFQVAtDQogICAgTk9PQiBhdXRoZW50aWNh dGlvbiBtZXRob2QgZm9yIG5pbWJsZSBvdXQtb2YtYmFuZCAoT09CKQ0KICAgIGF1dGhlbnRpY2F0 aW9uIGFuZCBrZXkgZGVyaXZhdGlvbi4gIFRoaXMgRUFQIG1ldGhvZCBpcyBpbnRlbmRlZCBmb3IN CiAgICBib290c3RyYXBwaW5nIGFsbCBraW5kcyBvZiBJbnRlcm5ldC1vZi1UaGluZ3MgKElvVCkg ZGV2aWNlcyB0aGF0IGhhdmUNCiAgICBhIG1pbmltYWwgdXNlciBpbnRlcmZhY2UgYW5kIG5vIHBy ZS1jb25maWd1cmVkIGF1dGhlbnRpY2F0aW9uDQogICAgY3JlZGVudGlhbHMuICBUaGUgbWV0aG9k IG1ha2VzIHVzZSBvZiBhIHVzZXItYXNzaXN0ZWQgb25lLWRpcmVjdGlvbmFsDQogICAgT09CIGNo YW5uZWwgYmV0d2VlbiB0aGUgcGVlciBkZXZpY2UgYW5kIGF1dGhlbnRpY2F0aW9uIHNlcnZlci4N Cg0KICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiANCnN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRG IFNlY3JldGFyaWF0DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0Kc2FhZyBtYWlsaW5nIGxpc3QNCnNhYWdAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FhZw0KDQoNCj09PT09LS0tLS09PT09PS0tLS0t PT09PT0KTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgZS1tYWlsCm1l c3NhZ2UgYW5kL29yIGF0dGFjaG1lbnRzIHRvIGl0IG1heSBjb250YWluIApjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbi4gSWYgeW91IGFyZSAKbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIGFueSBkaXNzZW1pbmF0aW9uLCB1c2UsIApyZXZpZXcsIGRpc3RyaWJ1dGlvbiwg cHJpbnRpbmcgb3IgY29weWluZyBvZiB0aGUgCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlz IGUtbWFpbCBtZXNzYWdlIAphbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgYXJlIHN0cmljdGx5IHBy b2hpYml0ZWQuIElmIAp5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJy b3IsIApwbGVhc2Ugbm90aWZ5IHVzIGJ5IHJlcGx5IGUtbWFpbCBvciB0ZWxlcGhvbmUgYW5kIApp bW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBtZXNzYWdlIAphbmQgYW55IGF0 dGFjaG1lbnRzLiBUaGFuayB5b3UKCgo= --=_alternative 002945D865257F5A_= MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIE1vaGl0LDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSB3YXMgZ29pbmcgdGhyb3VnaCB5b3VyIGRyYWZ0 LiBMb29rcw0KdG8gYmUgYSBwcm9taXNpbmcgcHJvcG9zaXRpb24uIEhvd2V2ZXIsIEkgaGF2ZSBn b3QgYSBmZXcgcXVlc3Rpb25zIGZpcnN0DQpoYW5kLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhlIGF1dGhlbnRpY2F0b3IgYWN0cyBhcyBhIHRyYW5z cGFyZW50DQpub2RlIGFuZCBmb3J3YXJkcyB0aGUgcGFja2V0cyB0byB0aGUgc2VydmVyIHNvb24g YWZ0ZXIgdGhlIGZpcnN0IG1lc3NhZ2UNCmZvciBFQVAgSWRlbnRpdHkgcmVxdWVzdC4gSW4gYSB0 eXBpY2FsIG5ldHdvcmsgd291bGQgYSBzaW5nbGUgYXV0aGVudGljYXRvcg0KbWFwIHRvIHNldmVy YWwgc2VydmVycyBvciB0aGUgYXNzdW1wdGlvbiBpcyB0aGF0IHRoZXJlIGlzIGFsd2F5cyBvbmUg dG8NCm9uZSBtYXBwaW5nIGJldHdlZW4gc2VydmVyIGFuZCBhdXRoZW50aWNhdG9yPyA8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhvdyBkb2VzIHRoZSBh dXRoZW50aWNhdG9yIGFzc29jaWF0ZQ0KaXRzZWxmIHRvIHRoZSBzZXJ2ZXIgYXQgdGhlIGZpcnN0 IHBsYWNlPzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ V2hhdCBpcyB0aGUgYXNzdW1wdGlvbiByZWdhcmRpbmcgdGhlDQombmJzcDt1bmRlcmx5aW5nIHBo eXNpY2FsIG5ldHdvcmsgYW5kIGhvdyB0aGUgYXV0aGVudGljYXRvciBtYXBzIHRvIHRoZQ0KZGlm ZmVyZW50IG5vZGVzIGluIHRoZSBuZXR3b3JrIChlLmcuIGEgcm91dGVyIGluIGEgV2lGaSBsaWtl IHNldHVwKT88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PlJlZ2FyZHM8YnI+DQpBYmhpamFuIEJoYXR0YWNoYXJ5eWE8YnI+DQpBc3NvY2lhdGUgQ29uc3Vs dGFudDxicj4NClNjaWVudGlzdCwgSW5ub3ZhdGlvbiBMYWIsIEtvbGthdGEsIEluZGlhPGJyPg0K VGF0YSBDb25zdWx0YW5jeSBTZXJ2aWNlczxicj4NCk1haWx0bzogYWJoaWphbi5iaGF0dGFjaGFy eXlhQHRjcy5jb208YnI+DQpXZWJzaXRlOiA8L2ZvbnQ+PGEgaHJlZj1odHRwOi8vd3d3LnRjcy5j b20vPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5odHRwOi8vd3d3LnRjcy5jb208L2Zv bnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkV4cGVyaWVuY2UgY2VydGFpbnR5 LiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJVCBTZXJ2aWNlczxicj4NCiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtCdXNpbmVzcyBTb2x1dGlvbnM8YnI+DQogJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Q29uc3VsdGluZzxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPkZyb206ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPk1v aGl0IFNldGhpICZsdDttb2hpdC5tLnNldGhpQGVyaWNzc29uLmNvbSZndDs8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+VG86ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PiZsdDtzYWFnQGlldGYub3JnJmd0OywNCiZsdDtlbXVAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPkNjOiAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij50dW9tYXMuYXVyYUBhYWx0by5maTwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVm NWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5EYXRlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4wMi8wOC8yMDE2IDA5OjEwIFBN PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYi PlN1YmplY3Q6ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPltzYWFnXSBGd2Q6DQpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWF1cmEtZWFwLW5vb2ItMDAudHh0PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBj b2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPlNlbnQgYnk6ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O3Nh YWcmcXVvdDsNCiZsdDtzYWFnLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPGJyPg0KPGhy IG5vc2hhZGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5EZWFyIGFsbDxicj4N Cjxicj4NCldlIGhhdmUganVzdCBzdWJtaXR0ZWQgYSBuZXcgSUVURiBEcmFmdCB0aXRsZWQg4oCc TmltYmxlIG91dC1vZi1iYW5kIDxicj4NCmF1dGhlbnRpY2F0aW9uIGZvciBFQVAgKEVBUC1OT09C KeKAnS48YnI+DQo8YnI+DQpUaGUgZHJhZnQgZGVmaW5lcyBhbiBFQVAgbWV0aG9kIHdoZXJlIHRo ZSBhdXRoZW50aWNhdGlvbiBpcyBiYXNlZCBvbiBhDQo8YnI+DQp1c2VyLWFzc2lzdGVkIG91dC1v Zi1iYW5kIChPT0IpIGNoYW5uZWwgYmV0d2VlbiB0aGUgc2VydmVyIGFuZCBwZWVyLiBJdA0KPGJy Pg0KaXMgaW50ZW5kZWQgYXMgYSBnZW5lcmljIGJvb3RzdHJhcHBpbmcgc29sdXRpb24gZm9yIElu dGVybmV0LW9mLVRoaW5ncw0KPGJyPg0KZGV2aWNlcyB3aGljaCBoYXZlIG5vIHByZS1jb25maWd1 cmVkIGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWxzIGFuZCA8YnI+DQp3aGljaCBhcmUgbm90IHll dCByZWdpc3RlcmVkIG9uIHRoZSBhdXRoZW50aWNhdGlvbiBzZXJ2ZXIuIENvbnNpZGVyIDxicj4N CmRldmljZXMgeW91IGp1c3QgYm91Z2h0IG9yIGJvcnJvd2VkLjxicj4NCjxicj4NClRoZSBFQVAt Tk9PQiBtZXRob2QgaXMgbW9yZSBnZW5lcmljIHRoYW4gbW9zdCBhZC1ob2MgYm9vdHN0cmFwcGlu ZyA8YnI+DQpzb2x1dGlvbnMgaW4gdGhhdCBpdCBzdXBwb3J0cyBtYW55IHR5cGVzIG9mIE9PQiBj aGFubmVscy4gV2Ugc3BlY2lmeSB0aGUNCjxicj4NCmV4YWN0IGluLWJhbmQgbWVzc2FnZXMgYnV0 IG9ubHkgdGhlIE9PQiBtZXNzYWdlIGNvbnRlbnRzIGFuZCBub3QgdGhlIE9PQg0KPGJyPg0KY2hh bm5lbCBkZXRhaWxzLiBBbHNvLCBFQVAtTk9PQiBzdXBwb3J0cyB1Ymljb21wIGRldmljZXMgd2l0 aCBvbmx5IDxicj4NCm91dHB1dCAoZS5nLiBkaXNwbGF5KSBvciBvbmx5IGlucHV0IChlLmcuIGNh bWVyYSkuIE1vcmVvdmVyLCBpdCBtYWtlcyA8YnI+DQpjb21iaW5lZCB1c2Ugb2YgYm90aCBzZWNy ZWN5IGFuZCBpbnRlZ3JpdHkgb2YgdGhlIE9PQiBjaGFubmVsIGZvciBtb3JlDQo8YnI+DQpyb2J1 c3Qgc2VjdXJpdHkgdGhhbiB0aGUgYWQtaG9jIHNvbHV0aW9ucy4gV2UgaGF2ZSBwdXQgYSBsb3Qg b2YgZWZmb3J0DQo8YnI+DQppbnRvIGRlc2lnbmluZyBhIHJvYnVzdCBzZWN1cml0eSBwcm90b2Nv bC48YnI+DQo8YnI+DQpGb3Igb25lIGFwcGxpY2F0aW9uIGV4YW1wbGUsIHdlIGhhdmUgdXNlZCBh biBlYXJsaWVyIHZlcnNpb24gb2YgdGhlIDxicj4NCnByb3RvY29sIGZvciBib290c3RyYXBwaW5n IHNlY3VyaXR5IGZvciB1YmlxdWl0b3VzIGRpc3BsYXlzOiB0aGUgdXNlciA8YnI+DQpjYW4gY29u ZmlndXJlIHdpcmVsZXNzIG5ldHdvcmsgYWNjZXNzLCBsaW5rIHRoZSBkZXZpY2UgdG8gYSBjbG91 ZCA8YnI+DQpzZXJ2aWNlLCBhbmQgcmVnaXN0ZXIgb3duZXJzaGlwIG9mIHRoZSBkZXZpY2UgZm9y IGEgc3BlY2lmaWMgY2xvdWQgdXNlcg0KPGJyPg0K4oCTIGFsbCBpbiBvbmUgc2ltcGxlIHN0ZXAg b2Ygc2Nhbm5pbmcgYSBRUiBjb2RlIHdpdGggYSBzbWFydCBwaG9uZS4gVGhlcmUNCjxicj4NCnNl ZW1lZCB0byBtb3JlIHBvdGVudGlhbCB0byB0aGlzIGlkZWEgdGhhbiBqdXN0IHVzaW5nIGl0IGZv ciBvdXIgb3duIDxicj4NCnN5c3RlbSwgYW5kIHRodXMgd2UgZGVjaWRlZCB0byB3cml0ZSBhIGdl bmVyaWMgRUFQIG1ldGhvZCBmb3IgPGJyPg0Kb3V0LW9mLWJhbmQgYXV0aGVudGljYXRpb24uPGJy Pg0KPGJyPg0KVGhlIGRyYWZ0IGlzIGF2YWlsYWJsZSBoZXJlOjxicj4NCjwvZm9udD48L3R0Pjxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hdXJhLWVhcC1ub29iLTAw Ij48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hdXJh LWVhcC1ub29iLTAwPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KPGJyPg0K UGxlYXNlIHNlZSBpZiB5b3UgY2FuIG1ha2UgdXNlIG9mIGl0LiBXZSBsb29rIGZvcndhcmQgdG8g eW91ciBmZWVkYmFjaw0KPGJyPg0KYW5kIGNvbW1lbnRzLjxicj4NCjxicj4NClJlZ2FyZHM8YnI+ DQovLS1Nb2hpdDxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0t LS0tLS0tPGJyPg0KU3ViamVjdDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1hdXJhLWVhcC1ub29iLTAwLnR4dDxicj4NCkRhdGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TW9uLA0KMDggRmViIDIw MTYgMDQ6MzA6MzUgLTA4MDA8YnI+DQpGcm9tOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2ludGVybmV0LWRyYWZ0c0BpZXRmLm9y Zzxicj4NClRvOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO1R1b21hcw0KQXVyYSAmbHQ7dHVvbWFzLmF1cmFAYWFsdG8uZmkmZ3Q7 LCBNb2hpdCBTZXRoaSAmbHQ7bW9oaXRAcGl1aGEubmV0Jmd0Ozxicj4NCjxicj4NCjxicj4NCjxi cj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1hdXJhLWVhcC1ub29iLTAwLnR4dDxicj4N CmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVHVvbWFzIEF1cmEgYW5kIHBvc3Rl ZCB0byB0aGU8YnI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFtZTogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFm dC1hdXJhLWVhcC1ub29iPGJyPg0KUmV2aXNpb246ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCjAwPGJyPg0KVGl0bGU6ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TmltYmxl DQpvdXQtb2YtYmFuZCBhdXRoZW50aWNhdGlvbiBmb3IgRUFQIChFQVAtTk9PQik8YnI+DQpEb2N1 bWVudCBkYXRlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAyMDE2LTAyLTA4PGJyPg0KR3JvdXA6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SW5kaXZpZHVhbA0KU3VibWlz c2lvbjxicj4NClBhZ2VzOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOzM1PGJyPg0KVVJMOjwvZm9udD48L3R0PjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1hdXJhLWVhcC1ub29iLTAw LnR4dCI+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtYXVyYS1lYXAtbm9vYi0wMC50eHQ8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNp emU9Mj48YnI+DQpTdGF0dXM6PC9mb250PjwvdHQ+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtYXVyYS1lYXAtbm9vYi8iPjx0dD48Zm9udCBzaXplPTI+aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYXVyYS1lYXAtbm9vYi88L2ZvbnQ+ PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQpIdG1saXplZDo8L2ZvbnQ+PC90dD48YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYXVyYS1lYXAtbm9vYi0wMCI+ PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYXVyYS1l YXAtbm9vYi0wMDwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjxicj4NCjxi cj4NCkFic3RyYWN0Ojxicj4NCiAmbmJzcDsgJm5ic3A7RXh0ZW5zaWJsZSBBdXRoZW50aWNhdGlv biBQcm90b2NvbCAoRUFQKSBbUkZDMzc0OF0gcHJvdmlkZXMNCnN1cHBvcnQ8YnI+DQogJm5ic3A7 ICZuYnNwO2ZvciBtdWx0aXBsZSBhdXRoZW50aWNhdGlvbiBtZXRob2RzLiAmbmJzcDtUaGlzIGRv Y3VtZW50DQpkZWZpbmVzIHRoZSBFQVAtPGJyPg0KICZuYnNwOyAmbmJzcDtOT09CIGF1dGhlbnRp Y2F0aW9uIG1ldGhvZCBmb3IgbmltYmxlIG91dC1vZi1iYW5kIChPT0IpPGJyPg0KICZuYnNwOyAm bmJzcDthdXRoZW50aWNhdGlvbiBhbmQga2V5IGRlcml2YXRpb24uICZuYnNwO1RoaXMgRUFQIG1l dGhvZA0KaXMgaW50ZW5kZWQgZm9yPGJyPg0KICZuYnNwOyAmbmJzcDtib290c3RyYXBwaW5nIGFs bCBraW5kcyBvZiBJbnRlcm5ldC1vZi1UaGluZ3MgKElvVCkgZGV2aWNlcw0KdGhhdCBoYXZlPGJy Pg0KICZuYnNwOyAmbmJzcDthIG1pbmltYWwgdXNlciBpbnRlcmZhY2UgYW5kIG5vIHByZS1jb25m aWd1cmVkIGF1dGhlbnRpY2F0aW9uPGJyPg0KICZuYnNwOyAmbmJzcDtjcmVkZW50aWFscy4gJm5i c3A7VGhlIG1ldGhvZCBtYWtlcyB1c2Ugb2YgYSB1c2VyLWFzc2lzdGVkDQpvbmUtZGlyZWN0aW9u YWw8YnI+DQogJm5ic3A7ICZuYnNwO09PQiBjaGFubmVsIGJldHdlZW4gdGhlIHBlZXIgZGV2aWNl IGFuZCBhdXRoZW50aWNhdGlvbiBzZXJ2ZXIuPGJyPg0KPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGJyPg0KPGJyPg0K PGJyPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxicj4NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPGJyPg0KPGJyPg0KVGhl IElFVEYgU2VjcmV0YXJpYXQ8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNhYWcgbWFpbGluZyBsaXN0PGJy Pg0Kc2FhZ0BpZXRmLm9yZzxicj4NCjwvZm9udD48L3R0PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWFnPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWFnPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBz aXplPTI+PGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo8cD49PT09PS0tLS0tPT09PT0tLS0tLT09 PT09PGJyPgpOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWw8 YnI+Cm1lc3NhZ2UgYW5kL29yIGF0dGFjaG1lbnRzIHRvIGl0IG1heSBjb250YWluIDxicj4KY29u ZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24uIElmIHlvdSBhcmUgPGJyPgpub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc3NlbWluYXRpb24sIHVzZSwgPGJyPgpyZXZp ZXcsIGRpc3RyaWJ1dGlvbiwgcHJpbnRpbmcgb3IgY29weWluZyBvZiB0aGUgPGJyPgppbmZvcm1h dGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwgbWVzc2FnZSA8YnI+CmFuZC9vciBhdHRhY2ht ZW50cyB0byBpdCBhcmUgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgPGJyPgp5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIDxicj4KcGxlYXNlIG5vdGlmeSB1cyBi eSByZXBseSBlLW1haWwgb3IgdGVsZXBob25lIGFuZCA8YnI+CmltbWVkaWF0ZWx5IGFuZCBwZXJt YW5lbnRseSBkZWxldGUgdGhlIG1lc3NhZ2UgPGJyPgphbmQgYW55IGF0dGFjaG1lbnRzLiBUaGFu ayB5b3U8L3A+Cgo8cD48L3A+ --=_alternative 002945D865257F5A_=-- From nobody Thu Feb 18 08:27:40 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32FF1B2CE9; Thu, 18 Feb 2016 08:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.205 X-Spam-Level: X-Spam-Status: No, score=-4.205 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=unavailable 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 QmvViX06hDui; Thu, 18 Feb 2016 08:27:32 -0800 (PST) Received: from smtp-out-02.aalto.fi (smtp-out-02.aalto.fi [130.233.228.121]) by ietfa.amsl.com (Postfix) with ESMTP id 430AD1AD059; Thu, 18 Feb 2016 08:27:30 -0800 (PST) Received: from smtp-out-02.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 41AE82710CD_6C5F0F1B; Thu, 18 Feb 2016 16:27:29 +0000 (GMT) Received: from EXHUB02.org.aalto.fi (exhub02.org.aalto.fi [130.233.222.119]) by smtp-out-02.aalto.fi (Sophos Email Appliance) with ESMTP id B52A22710AA_6C5F0F0F; Thu, 18 Feb 2016 16:27:28 +0000 (GMT) Received: from EXMDB01.org.aalto.fi ([169.254.2.222]) by EXHUB02.org.aalto.fi ([130.233.222.119]) with mapi id 14.03.0224.002; Thu, 18 Feb 2016 18:27:28 +0200 From: Aura Tuomas To: Abhijan Bhattacharyya , Mohit Sethi Thread-Topic: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt Thread-Index: AQHRYmyDaEz8z8wkLU+ZyRerPC0UrZ8iJdqAgAp5WICAAFk8kA== Date: Thu, 18 Feb 2016 16:27:28 +0000 Message-ID: <7F9C975440487E49BBD35F4FB088ED74CFCDBBAD@EXMDB01.org.aalto.fi> References: <20160208123035.1562.80507.idtracker@ietfa.amsl.com> <56B8B561.8040300@ericsson.com> In-Reply-To: Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [85.76.33.105] Content-Type: multipart/alternative; boundary="_000_7F9C975440487E49BBD35F4FB088ED74CFCDBBADEXMDB01orgaalto_" MIME-Version: 1.0 Archived-At: Cc: "'t2trg@irtf.org'" , "saag@ietf.org" , "'core@ietf.org'" , "emu@ietf.org" Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 16:27:35 -0000 --_000_7F9C975440487E49BBD35F4FB088ED74CFCDBBADEXMDB01orgaalto_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWJoaWphbiwNCg0KVGhhbmsgeW91IGZvciB0aGUgcXVlc3Rpb25zLg0KDQpUaGVyZSBpcyBh IG9uZS10by1vbmUgbWFwcGluZyBiZXR3ZWVuIHRoZSBFQVAgc2VydmVyIGFuZCBhdXRoZW50aWNh dG9yLiBUaGUgRUFQIHNlcnZlciBpcyBkZXRlcm1pbmVkIGJ5IGhvdyB0aGUgYXV0aGVudGljYXRv ciBvciBsb2NhbCBBQUEgc2VydmVyIGlzIGNvbmZpZ3VyZWQuIFRoYXQgaXMsIHRoZSBsb2NhbCBu ZXR3b3JrIGFkbWluaXN0cmF0b3JzIGNhbiByb3V0ZSBhY2Nlc3MgcmVxdWVzdHMgZm9yIOKAnEBl YXAtbm9vYi5vcmfigJ0gdG8gYW55IHNlcnZlciB0aGV5IGNob29zZS4NCg0KSW4gb3VyIG93biBz ZXR1cCwgd2UgaGF2ZSBjb25maWd1cmVkIHRoZSBSQURJVVMgc2VydmVyIGF0IG91ciBsb2NhbCB3 aXJlbGVzcyBuZXR3b3JrIHRvIHRydXN0IGFub3RoZXIsIHJlbW90ZSBSQURJVVMgc2VydmVyIGZv ciBOQUlzIHRoYXQgZW5kIOKAnEBlYXAtbm9vYi5vcmfigJ0uIFRoYXQgcmVtb3RlIHNlcnZlciBo YW5kbGVzIEVBUC1OT09CIGZvciBhbGwgdGhlIHN0YXRpb25zIGluIG91ciB3aXJlbGVzcyBuZXR3 b3JrLg0KDQpUdW9tYXMNCg0KUC5TLiBTb3JyeSBhYm91dCB0aGUgY3Jvc3MtcG9zdGluZy4gTGV0 4oCZcyBzZW5kIHRoZSBmb2xsb3ctdXBzIG9ubHkgdG8gc2FhZ0BpZXRmLm9yZzxtYWlsdG86c2Fh Z0BpZXRmLm9yZz4uDQoNCg0KDQpGcm9tOiBBYmhpamFuIEJoYXR0YWNoYXJ5eWEgW21haWx0bzph YmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbV0NClNlbnQ6IE1vbmRheSwgMTUgRmVicnVhcnks IDIwMTYgMDk6MzENClRvOiBNb2hpdCBTZXRoaSA8bW9oaXQubS5zZXRoaUBlcmljc3Nvbi5jb20+ DQpDYzogc2FhZ0BpZXRmLm9yZzsgZW11QGlldGYub3JnOyBBdXJhIFR1b21hcyA8dHVvbWFzLmF1 cmFAYWFsdG8uZmk+OyAnY29yZUBpZXRmLm9yZycgPGNvcmVAaWV0Zi5vcmc+OyAndDJ0cmdAaXJ0 Zi5vcmcnIDx0MnRyZ0BpcnRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2FhZ10gRndkOiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWF1cmEtZWFwLW5vb2ItMDAudHh0DQoNCkhpIE1v aGl0LA0KSSB3YXMgZ29pbmcgdGhyb3VnaCB5b3VyIGRyYWZ0LiBMb29rcyB0byBiZSBhIHByb21p c2luZyBwcm9wb3NpdGlvbi4gSG93ZXZlciwgSSBoYXZlIGdvdCBhIGZldyBxdWVzdGlvbnMgZmly c3QgaGFuZC4NCg0KVGhlIGF1dGhlbnRpY2F0b3IgYWN0cyBhcyBhIHRyYW5zcGFyZW50IG5vZGUg YW5kIGZvcndhcmRzIHRoZSBwYWNrZXRzIHRvIHRoZSBzZXJ2ZXIgc29vbiBhZnRlciB0aGUgZmly c3QgbWVzc2FnZSBmb3IgRUFQIElkZW50aXR5IHJlcXVlc3QuIEluIGEgdHlwaWNhbCBuZXR3b3Jr IHdvdWxkIGEgc2luZ2xlIGF1dGhlbnRpY2F0b3IgbWFwIHRvIHNldmVyYWwgc2VydmVycyBvciB0 aGUgYXNzdW1wdGlvbiBpcyB0aGF0IHRoZXJlIGlzIGFsd2F5cyBvbmUgdG8gb25lIG1hcHBpbmcg YmV0d2VlbiBzZXJ2ZXIgYW5kIGF1dGhlbnRpY2F0b3I/DQoNCkhvdyBkb2VzIHRoZSBhdXRoZW50 aWNhdG9yIGFzc29jaWF0ZSBpdHNlbGYgdG8gdGhlIHNlcnZlciBhdCB0aGUgZmlyc3QgcGxhY2U/ DQoNCldoYXQgaXMgdGhlIGFzc3VtcHRpb24gcmVnYXJkaW5nIHRoZSAgdW5kZXJseWluZyBwaHlz aWNhbCBuZXR3b3JrIGFuZCBob3cgdGhlIGF1dGhlbnRpY2F0b3IgbWFwcyB0byB0aGUgZGlmZmVy ZW50IG5vZGVzIGluIHRoZSBuZXR3b3JrIChlLmcuIGEgcm91dGVyIGluIGEgV2lGaSBsaWtlIHNl dHVwKT8NCg0KUmVnYXJkcw0KQWJoaWphbiBCaGF0dGFjaGFyeXlhDQpBc3NvY2lhdGUgQ29uc3Vs dGFudA0KU2NpZW50aXN0LCBJbm5vdmF0aW9uIExhYiwgS29sa2F0YSwgSW5kaWENClRhdGEgQ29u c3VsdGFuY3kgU2VydmljZXMNCk1haWx0bzogYWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb208 bWFpbHRvOmFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tPg0KV2Vic2l0ZTogaHR0cDovL3d3 dy50Y3MuY29tPGh0dHA6Ly93d3cudGNzLmNvbS8+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KRXhwZXJpZW5jZSBjZXJ0YWludHkuICAgICAgICBJVCBTZXJ2 aWNlcw0KICAgICAgICAgICAgICAgICAgICAgICBCdXNpbmVzcyBTb2x1dGlvbnMNCiAgICAgICAg ICAgICAgICAgICAgICAgQ29uc3VsdGluZw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KDQoNCg0KRnJvbTogICAgICAgIE1vaGl0IFNldGhpIDxtb2hpdC5t LnNldGhpQGVyaWNzc29uLmNvbTxtYWlsdG86bW9oaXQubS5zZXRoaUBlcmljc3Nvbi5jb20+Pg0K VG86ICAgICAgICA8c2FhZ0BpZXRmLm9yZzxtYWlsdG86c2FhZ0BpZXRmLm9yZz4+LCA8ZW11QGll dGYub3JnPG1haWx0bzplbXVAaWV0Zi5vcmc+Pg0KQ2M6ICAgICAgICB0dW9tYXMuYXVyYUBhYWx0 by5maTxtYWlsdG86dHVvbWFzLmF1cmFAYWFsdG8uZmk+DQpEYXRlOiAgICAgICAgMDIvMDgvMjAx NiAwOToxMCBQTQ0KU3ViamVjdDogICAgICAgIFtzYWFnXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtYXVyYS1lYXAtbm9vYi0wMC50eHQNClNlbnQgYnk6ICAgICAgICAi c2FhZyIgPHNhYWctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2FhZy1ib3VuY2VzQGlldGYub3Jn Pj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpEZWFyIGFsbA0KDQpX ZSBoYXZlIGp1c3Qgc3VibWl0dGVkIGEgbmV3IElFVEYgRHJhZnQgdGl0bGVkIOKAnE5pbWJsZSBv dXQtb2YtYmFuZA0KYXV0aGVudGljYXRpb24gZm9yIEVBUCAoRUFQLU5PT0Ip4oCdLg0KDQpUaGUg ZHJhZnQgZGVmaW5lcyBhbiBFQVAgbWV0aG9kIHdoZXJlIHRoZSBhdXRoZW50aWNhdGlvbiBpcyBi YXNlZCBvbiBhDQp1c2VyLWFzc2lzdGVkIG91dC1vZi1iYW5kIChPT0IpIGNoYW5uZWwgYmV0d2Vl biB0aGUgc2VydmVyIGFuZCBwZWVyLiBJdA0KaXMgaW50ZW5kZWQgYXMgYSBnZW5lcmljIGJvb3Rz dHJhcHBpbmcgc29sdXRpb24gZm9yIEludGVybmV0LW9mLVRoaW5ncw0KZGV2aWNlcyB3aGljaCBo YXZlIG5vIHByZS1jb25maWd1cmVkIGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWxzIGFuZA0Kd2hp Y2ggYXJlIG5vdCB5ZXQgcmVnaXN0ZXJlZCBvbiB0aGUgYXV0aGVudGljYXRpb24gc2VydmVyLiBD b25zaWRlcg0KZGV2aWNlcyB5b3UganVzdCBib3VnaHQgb3IgYm9ycm93ZWQuDQoNClRoZSBFQVAt Tk9PQiBtZXRob2QgaXMgbW9yZSBnZW5lcmljIHRoYW4gbW9zdCBhZC1ob2MgYm9vdHN0cmFwcGlu Zw0Kc29sdXRpb25zIGluIHRoYXQgaXQgc3VwcG9ydHMgbWFueSB0eXBlcyBvZiBPT0IgY2hhbm5l bHMuIFdlIHNwZWNpZnkgdGhlDQpleGFjdCBpbi1iYW5kIG1lc3NhZ2VzIGJ1dCBvbmx5IHRoZSBP T0IgbWVzc2FnZSBjb250ZW50cyBhbmQgbm90IHRoZSBPT0INCmNoYW5uZWwgZGV0YWlscy4gQWxz bywgRUFQLU5PT0Igc3VwcG9ydHMgdWJpY29tcCBkZXZpY2VzIHdpdGggb25seQ0Kb3V0cHV0IChl LmcuIGRpc3BsYXkpIG9yIG9ubHkgaW5wdXQgKGUuZy4gY2FtZXJhKS4gTW9yZW92ZXIsIGl0IG1h a2VzDQpjb21iaW5lZCB1c2Ugb2YgYm90aCBzZWNyZWN5IGFuZCBpbnRlZ3JpdHkgb2YgdGhlIE9P QiBjaGFubmVsIGZvciBtb3JlDQpyb2J1c3Qgc2VjdXJpdHkgdGhhbiB0aGUgYWQtaG9jIHNvbHV0 aW9ucy4gV2UgaGF2ZSBwdXQgYSBsb3Qgb2YgZWZmb3J0DQppbnRvIGRlc2lnbmluZyBhIHJvYnVz dCBzZWN1cml0eSBwcm90b2NvbC4NCg0KRm9yIG9uZSBhcHBsaWNhdGlvbiBleGFtcGxlLCB3ZSBo YXZlIHVzZWQgYW4gZWFybGllciB2ZXJzaW9uIG9mIHRoZQ0KcHJvdG9jb2wgZm9yIGJvb3RzdHJh cHBpbmcgc2VjdXJpdHkgZm9yIHViaXF1aXRvdXMgZGlzcGxheXM6IHRoZSB1c2VyDQpjYW4gY29u ZmlndXJlIHdpcmVsZXNzIG5ldHdvcmsgYWNjZXNzLCBsaW5rIHRoZSBkZXZpY2UgdG8gYSBjbG91 ZA0Kc2VydmljZSwgYW5kIHJlZ2lzdGVyIG93bmVyc2hpcCBvZiB0aGUgZGV2aWNlIGZvciBhIHNw ZWNpZmljIGNsb3VkIHVzZXINCuKAkyBhbGwgaW4gb25lIHNpbXBsZSBzdGVwIG9mIHNjYW5uaW5n IGEgUVIgY29kZSB3aXRoIGEgc21hcnQgcGhvbmUuIFRoZXJlDQpzZWVtZWQgdG8gbW9yZSBwb3Rl bnRpYWwgdG8gdGhpcyBpZGVhIHRoYW4ganVzdCB1c2luZyBpdCBmb3Igb3VyIG93bg0Kc3lzdGVt LCBhbmQgdGh1cyB3ZSBkZWNpZGVkIHRvIHdyaXRlIGEgZ2VuZXJpYyBFQVAgbWV0aG9kIGZvcg0K b3V0LW9mLWJhbmQgYXV0aGVudGljYXRpb24uDQoNClRoZSBkcmFmdCBpcyBhdmFpbGFibGUgaGVy ZToNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hdXJhLWVhcC1ub29iLTAwDQoN ClBsZWFzZSBzZWUgaWYgeW91IGNhbiBtYWtlIHVzZSBvZiBpdC4gV2UgbG9vayBmb3J3YXJkIHRv IHlvdXIgZmVlZGJhY2sNCmFuZCBjb21tZW50cy4NCg0KUmVnYXJkcw0KLy0tTW9oaXQNCg0KDQot LS0tLS0tLSBGb3J3YXJkZWQgTWVzc2FnZSAtLS0tLS0tLQ0KU3ViamVjdDogICAgICAgICAgICAg ICAgICBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWF1cmEtZWFwLW5vb2ItMDAu dHh0DQpEYXRlOiAgICAgICAgICAgICAgICAgIE1vbiwgMDggRmViIDIwMTYgMDQ6MzA6MzUgLTA4 MDANCkZyb206ICAgICAgICAgICAgICAgICAgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQpUbzogICAgICAgICAgICAgICAgICBUdW9tYXMg QXVyYSA8dHVvbWFzLmF1cmFAYWFsdG8uZmk8bWFpbHRvOnR1b21hcy5hdXJhQGFhbHRvLmZpPj4s IE1vaGl0IFNldGhpIDxtb2hpdEBwaXVoYS5uZXQ8bWFpbHRvOm1vaGl0QHBpdWhhLm5ldD4+DQoN Cg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYXVyYS1lYXAtbm9vYi0wMC50eHQNCmhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVHVvbWFzIEF1cmEgYW5kIHBvc3RlZCB0 byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgZHJhZnQtYXVyYS1lYXAtbm9vYg0KUmV2aXNpb246ICAgICAgICAgICAgICAgICAw MA0KVGl0bGU6ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5pbWJsZSBvdXQtb2Yt YmFuZCBhdXRoZW50aWNhdGlvbiBmb3IgRUFQIChFQVAtTk9PQikNCkRvY3VtZW50IGRhdGU6ICAg ICAgICAgICAgICAgICAyMDE2LTAyLTA4DQpHcm91cDogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgMzUNClVSTDpodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtYXVyYS1lYXAtbm9vYi0wMC50eHQNClN0YXR1czpodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1hdXJhLWVhcC1ub29iLw0KSHRtbGl6ZWQ6aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWF1cmEtZWFwLW5vb2ItMDANCg0KDQpBYnN0cmFjdDoNCiAg IEV4dGVuc2libGUgQXV0aGVudGljYXRpb24gUHJvdG9jb2wgKEVBUCkgW1JGQzM3NDhdIHByb3Zp ZGVzIHN1cHBvcnQNCiAgIGZvciBtdWx0aXBsZSBhdXRoZW50aWNhdGlvbiBtZXRob2RzLiAgVGhp cyBkb2N1bWVudCBkZWZpbmVzIHRoZSBFQVAtDQogICBOT09CIGF1dGhlbnRpY2F0aW9uIG1ldGhv ZCBmb3IgbmltYmxlIG91dC1vZi1iYW5kIChPT0IpDQogICBhdXRoZW50aWNhdGlvbiBhbmQga2V5 IGRlcml2YXRpb24uICBUaGlzIEVBUCBtZXRob2QgaXMgaW50ZW5kZWQgZm9yDQogICBib290c3Ry YXBwaW5nIGFsbCBraW5kcyBvZiBJbnRlcm5ldC1vZi1UaGluZ3MgKElvVCkgZGV2aWNlcyB0aGF0 IGhhdmUNCiAgIGEgbWluaW1hbCB1c2VyIGludGVyZmFjZSBhbmQgbm8gcHJlLWNvbmZpZ3VyZWQg YXV0aGVudGljYXRpb24NCiAgIGNyZWRlbnRpYWxzLiAgVGhlIG1ldGhvZCBtYWtlcyB1c2Ugb2Yg YSB1c2VyLWFzc2lzdGVkIG9uZS1kaXJlY3Rpb25hbA0KICAgT09CIGNoYW5uZWwgYmV0d2VlbiB0 aGUgcGVlciBkZXZpY2UgYW5kIGF1dGhlbnRpY2F0aW9uIHNlcnZlci4NCg0KDQoNCg0KUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2 YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzYWFnIG1h aWxpbmcgbGlzdA0Kc2FhZ0BpZXRmLm9yZzxtYWlsdG86c2FhZ0BpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FhZw0KDQo9PT09PS0tLS0tPT09PT0tLS0t LT09PT09DQpOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwN Cm1lc3NhZ2UgYW5kL29yIGF0dGFjaG1lbnRzIHRvIGl0IG1heSBjb250YWluDQpjb25maWRlbnRp YWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbi4gSWYgeW91IGFyZQ0Kbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIGFueSBkaXNzZW1pbmF0aW9uLCB1c2UsDQpyZXZpZXcsIGRpc3RyaWJ1dGlv biwgcHJpbnRpbmcgb3IgY29weWluZyBvZiB0aGUNCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIGUtbWFpbCBtZXNzYWdlDQphbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgYXJlIHN0cmljdGx5 IHByb2hpYml0ZWQuIElmDQp5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4g ZXJyb3IsDQpwbGVhc2Ugbm90aWZ5IHVzIGJ5IHJlcGx5IGUtbWFpbCBvciB0ZWxlcGhvbmUgYW5k DQppbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBtZXNzYWdlDQphbmQgYW55 IGF0dGFjaG1lbnRzLiBUaGFuayB5b3UNCg== --_000_7F9C975440487E49BBD35F4FB088ED74CFCDBBADEXMDB01orgaalto_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQp0dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUy MA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkg QWJoaWphbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5r IHlvdSBmb3IgdGhlIHF1ZXN0aW9ucy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+VGhlcmUgaXMgYSBvbmUtdG8tb25lIG1hcHBpbmcgYmV0d2VlbiB0aGUgRUFQ IHNlcnZlciBhbmQgYXV0aGVudGljYXRvci4gVGhlIEVBUCBzZXJ2ZXIgaXMgZGV0ZXJtaW5lZCBi eSBob3cgdGhlIGF1dGhlbnRpY2F0b3Igb3IgbG9jYWwgQUFBIHNlcnZlciBpcyBjb25maWd1cmVk Lg0KIFRoYXQgaXMsIHRoZSBsb2NhbCBuZXR3b3JrIGFkbWluaXN0cmF0b3JzIGNhbiByb3V0ZSBh Y2Nlc3MgcmVxdWVzdHMgZm9yIOKAnEBlYXAtbm9vYi5vcmfigJ0gdG8gYW55IHNlcnZlciB0aGV5 IGNob29zZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SW4g b3VyIG93biBzZXR1cCwgd2UgaGF2ZSBjb25maWd1cmVkIHRoZSBSQURJVVMgc2VydmVyIGF0IG91 ciBsb2NhbCB3aXJlbGVzcyBuZXR3b3JrIHRvIHRydXN0IGFub3RoZXIsIHJlbW90ZSBSQURJVVMg c2VydmVyIGZvciBOQUlzIHRoYXQgZW5kIOKAnEBlYXAtbm9vYi5vcmfigJ0uDQogVGhhdCByZW1v dGUgc2VydmVyIGhhbmRsZXMgRUFQLU5PT0IgZm9yIGFsbCB0aGUgc3RhdGlvbnMgaW4gb3VyIHdp cmVsZXNzIG5ldHdvcmsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5UdW9tYXMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UC5T LiBTb3JyeSBhYm91dCB0aGUgY3Jvc3MtcG9zdGluZy4gTGV04oCZcyBzZW5kIHRoZSBmb2xsb3ct dXBzIG9ubHkgdG8NCjxhIGhyZWY9Im1haWx0bzpzYWFnQGlldGYub3JnIj5zYWFnQGlldGYub3Jn PC9hPi4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFp bEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQWJoaWphbiBCaGF0dGFjaGFy eXlhIFttYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb21dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gTW9uZGF5LCAxNSBGZWJydWFyeSwgMjAxNiAwOTozMTxicj4NCjxiPlRvOjwvYj4gTW9o aXQgU2V0aGkgJmx0O21vaGl0Lm0uc2V0aGlAZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxiPkNjOjwv Yj4gc2FhZ0BpZXRmLm9yZzsgZW11QGlldGYub3JnOyBBdXJhIFR1b21hcyAmbHQ7dHVvbWFzLmF1 cmFAYWFsdG8uZmkmZ3Q7OyAnY29yZUBpZXRmLm9yZycgJmx0O2NvcmVAaWV0Zi5vcmcmZ3Q7OyAn dDJ0cmdAaXJ0Zi5vcmcnICZsdDt0MnRyZ0BpcnRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtzYWFnXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYXVy YS1lYXAtbm9vYi0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPkhpIE1vaGl0LDwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkkgd2FzIGdvaW5n IHRocm91Z2ggeW91ciBkcmFmdC4gTG9va3MgdG8gYmUgYSBwcm9taXNpbmcgcHJvcG9zaXRpb24u IEhvd2V2ZXIsIEkgaGF2ZSBnb3QgYSBmZXcgcXVlc3Rpb25zIGZpcnN0IGhhbmQuPC9zcGFuPg0K PGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VGhlIGF1dGhlbnRpY2F0b3IgYWN0cyBhcyBhIHRy YW5zcGFyZW50IG5vZGUgYW5kIGZvcndhcmRzIHRoZSBwYWNrZXRzIHRvIHRoZSBzZXJ2ZXIgc29v biBhZnRlciB0aGUgZmlyc3QgbWVzc2FnZSBmb3IgRUFQIElkZW50aXR5IHJlcXVlc3QuIEluIGEg dHlwaWNhbCBuZXR3b3JrIHdvdWxkIGEgc2luZ2xlIGF1dGhlbnRpY2F0b3IgbWFwIHRvDQogc2V2 ZXJhbCBzZXJ2ZXJzIG9yIHRoZSBhc3N1bXB0aW9uIGlzIHRoYXQgdGhlcmUgaXMgYWx3YXlzIG9u ZSB0byBvbmUgbWFwcGluZyBiZXR3ZWVuIHNlcnZlciBhbmQgYXV0aGVudGljYXRvcj8NCjwvc3Bh bj48YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Ib3cgZG9lcyB0aGUgYXV0aGVudGljYXRvciBh c3NvY2lhdGUgaXRzZWxmIHRvIHRoZSBzZXJ2ZXIgYXQgdGhlIGZpcnN0IHBsYWNlPzwvc3Bhbj4N Cjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPldoYXQgaXMgdGhlIGFzc3VtcHRpb24gcmVnYXJk aW5nIHRoZSAmbmJzcDt1bmRlcmx5aW5nIHBoeXNpY2FsIG5ldHdvcmsgYW5kIGhvdyB0aGUgYXV0 aGVudGljYXRvciBtYXBzIHRvIHRoZSBkaWZmZXJlbnQgbm9kZXMgaW4gdGhlIG5ldHdvcmsgKGUu Zy4gYSByb3V0ZXIgaW4gYSBXaUZpIGxpa2Ugc2V0dXApPzwvc3Bhbj4NCjxicj4NCjxicj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPlJlZ2FyZHM8YnI+DQpBYmhpamFuIEJoYXR0YWNoYXJ5eWE8YnI+DQpBc3Nv Y2lhdGUgQ29uc3VsdGFudDxicj4NClNjaWVudGlzdCwgSW5ub3ZhdGlvbiBMYWIsIEtvbGthdGEs IEluZGlhPGJyPg0KVGF0YSBDb25zdWx0YW5jeSBTZXJ2aWNlczxicj4NCk1haWx0bzogPC9zcGFu PjxhIGhyZWY9Im1haWx0bzphYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPjxicj4NCldlYnNpdGU6IDwvc3Bhbj48YSBocmVmPSJodHRwOi8vd3d3LnRjcy5jb20vIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj5odHRwOi8vd3d3LnRjcy5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi Pjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K RXhwZXJpZW5jZSBjZXJ0YWludHkuICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0lUIFNlcnZp Y2VzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtCdXNpbmVzcyBTb2x1dGlvbnM8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0NvbnN1bHRpbmc8YnI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjwvc3Bhbj48YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzVGNUY1RiI+RnJvbTogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+TW9oaXQgU2V0aGkgJmx0Ozwvc3Bh bj48YSBocmVmPSJtYWlsdG86bW9oaXQubS5zZXRoaUBlcmljc3Nvbi5jb20iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+bW9oaXQubS5zZXRoaUBlcmljc3Nvbi5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jmd0 Ozwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNUY1RjVGIj5UbzogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jmx0Ozwvc3Bhbj48YSBocmVm PSJtYWlsdG86c2FhZ0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5zYWFnQGlldGYub3JnPC9zcGFu PjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPiZndDssDQogJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZW11 QGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPmVtdUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj4mZ3Q7PC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1RjVGNUYiPkNjOiAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnR1b21hcy5h dXJhQGFhbHRvLmZpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPnR1b21hcy5hdXJhQGFhbHRvLmZpPC9zcGFuPjwv YT4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNUY1RjVGIj5EYXRlOiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4wMi8wOC8yMDE2IDA5OjEwIFBNPC9z cGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1RjVGNUYiPlN1YmplY3Q6ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPltzYWFnXSBGd2Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYXVyYS1lYXAtbm9vYi0wMC50eHQ8L3NwYW4+ DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzVGNUY1RiI+U2VudCBieTogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+JnF1b3Q7c2FhZyZxdW90OyAmbHQ7 PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzYWFnLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+c2FhZy1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3Nw YW4+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRl ciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSI0IiB3aWR0aD0iMTAwJSIg bm9zaGFkZT0iIiBzdHlsZT0iY29sb3I6I0EwQTBBMCIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0K PGJyPg0KPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5EZWFyIGFsbDwv c3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8YnI+DQo8dHQ+V2UgaGF2ZSBqdXN0IHN1Ym1pdHRl ZCBhIG5ldyBJRVRGIERyYWZ0IHRpdGxlZCDigJxOaW1ibGUgb3V0LW9mLWJhbmQgPC90dD48YnI+ DQo8dHQ+YXV0aGVudGljYXRpb24gZm9yIEVBUCAoRUFQLU5PT0Ip4oCdLjwvdHQ+PGJyPg0KPGJy Pg0KPHR0PlRoZSBkcmFmdCBkZWZpbmVzIGFuIEVBUCBtZXRob2Qgd2hlcmUgdGhlIGF1dGhlbnRp Y2F0aW9uIGlzIGJhc2VkIG9uIGEgPC90dD48YnI+DQo8dHQ+dXNlci1hc3Npc3RlZCBvdXQtb2Yt YmFuZCAoT09CKSBjaGFubmVsIGJldHdlZW4gdGhlIHNlcnZlciBhbmQgcGVlci4gSXQgPC90dD4N Cjxicj4NCjx0dD5pcyBpbnRlbmRlZCBhcyBhIGdlbmVyaWMgYm9vdHN0cmFwcGluZyBzb2x1dGlv biBmb3IgSW50ZXJuZXQtb2YtVGhpbmdzIDwvdHQ+PGJyPg0KPHR0PmRldmljZXMgd2hpY2ggaGF2 ZSBubyBwcmUtY29uZmlndXJlZCBhdXRoZW50aWNhdGlvbiBjcmVkZW50aWFscyBhbmQgPC90dD48 YnI+DQo8dHQ+d2hpY2ggYXJlIG5vdCB5ZXQgcmVnaXN0ZXJlZCBvbiB0aGUgYXV0aGVudGljYXRp b24gc2VydmVyLiBDb25zaWRlciA8L3R0Pjxicj4NCjx0dD5kZXZpY2VzIHlvdSBqdXN0IGJvdWdo dCBvciBib3Jyb3dlZC48L3R0Pjxicj4NCjxicj4NCjx0dD5UaGUgRUFQLU5PT0IgbWV0aG9kIGlz IG1vcmUgZ2VuZXJpYyB0aGFuIG1vc3QgYWQtaG9jIGJvb3RzdHJhcHBpbmcgPC90dD48YnI+DQo8 dHQ+c29sdXRpb25zIGluIHRoYXQgaXQgc3VwcG9ydHMgbWFueSB0eXBlcyBvZiBPT0IgY2hhbm5l bHMuIFdlIHNwZWNpZnkgdGhlIDwvdHQ+DQo8YnI+DQo8dHQ+ZXhhY3QgaW4tYmFuZCBtZXNzYWdl cyBidXQgb25seSB0aGUgT09CIG1lc3NhZ2UgY29udGVudHMgYW5kIG5vdCB0aGUgT09CIDwvdHQ+ DQo8YnI+DQo8dHQ+Y2hhbm5lbCBkZXRhaWxzLiBBbHNvLCBFQVAtTk9PQiBzdXBwb3J0cyB1Ymlj b21wIGRldmljZXMgd2l0aCBvbmx5IDwvdHQ+PGJyPg0KPHR0Pm91dHB1dCAoZS5nLiBkaXNwbGF5 KSBvciBvbmx5IGlucHV0IChlLmcuIGNhbWVyYSkuIE1vcmVvdmVyLCBpdCBtYWtlcyA8L3R0Pjxi cj4NCjx0dD5jb21iaW5lZCB1c2Ugb2YgYm90aCBzZWNyZWN5IGFuZCBpbnRlZ3JpdHkgb2YgdGhl IE9PQiBjaGFubmVsIGZvciBtb3JlIDwvdHQ+PGJyPg0KPHR0PnJvYnVzdCBzZWN1cml0eSB0aGFu IHRoZSBhZC1ob2Mgc29sdXRpb25zLiBXZSBoYXZlIHB1dCBhIGxvdCBvZiBlZmZvcnQgPC90dD48 YnI+DQo8dHQ+aW50byBkZXNpZ25pbmcgYSByb2J1c3Qgc2VjdXJpdHkgcHJvdG9jb2wuPC90dD48 YnI+DQo8YnI+DQo8dHQ+Rm9yIG9uZSBhcHBsaWNhdGlvbiBleGFtcGxlLCB3ZSBoYXZlIHVzZWQg YW4gZWFybGllciB2ZXJzaW9uIG9mIHRoZSA8L3R0Pjxicj4NCjx0dD5wcm90b2NvbCBmb3IgYm9v dHN0cmFwcGluZyBzZWN1cml0eSBmb3IgdWJpcXVpdG91cyBkaXNwbGF5czogdGhlIHVzZXIgPC90 dD48YnI+DQo8dHQ+Y2FuIGNvbmZpZ3VyZSB3aXJlbGVzcyBuZXR3b3JrIGFjY2VzcywgbGluayB0 aGUgZGV2aWNlIHRvIGEgY2xvdWQgPC90dD48YnI+DQo8dHQ+c2VydmljZSwgYW5kIHJlZ2lzdGVy IG93bmVyc2hpcCBvZiB0aGUgZGV2aWNlIGZvciBhIHNwZWNpZmljIGNsb3VkIHVzZXIgPC90dD4N Cjxicj4NCjx0dD7igJMgYWxsIGluIG9uZSBzaW1wbGUgc3RlcCBvZiBzY2FubmluZyBhIFFSIGNv ZGUgd2l0aCBhIHNtYXJ0IHBob25lLiBUaGVyZSA8L3R0Pg0KPGJyPg0KPHR0PnNlZW1lZCB0byBt b3JlIHBvdGVudGlhbCB0byB0aGlzIGlkZWEgdGhhbiBqdXN0IHVzaW5nIGl0IGZvciBvdXIgb3du IDwvdHQ+PGJyPg0KPHR0PnN5c3RlbSwgYW5kIHRodXMgd2UgZGVjaWRlZCB0byB3cml0ZSBhIGdl bmVyaWMgRUFQIG1ldGhvZCBmb3IgPC90dD48YnI+DQo8dHQ+b3V0LW9mLWJhbmQgYXV0aGVudGlj YXRpb24uPC90dD48YnI+DQo8YnI+DQo8dHQ+VGhlIGRyYWZ0IGlzIGF2YWlsYWJsZSBoZXJlOjwv dHQ+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1hdXJhLWVhcC1ub29iLTAwIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hdXJhLWVhcC1ub29iLTAwPC9zcGFuPjwv dHQ+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8YnI+DQo8dHQ+UGxlYXNlIHNlZSBpZiB5b3UgY2FuIG1h a2UgdXNlIG9mIGl0LiBXZSBsb29rIGZvcndhcmQgdG8geW91ciBmZWVkYmFjayA8L3R0Pjxicj4N Cjx0dD5hbmQgY29tbWVudHMuPC90dD48YnI+DQo8YnI+DQo8dHQ+UmVnYXJkczwvdHQ+PGJyPg0K PHR0Pi8tLU1vaGl0PC90dD48YnI+DQo8YnI+DQo8YnI+DQo8dHQ+LS0tLS0tLS0gRm9yd2FyZGVk IE1lc3NhZ2UgLS0tLS0tLS08L3R0Pjxicj4NCjx0dD5TdWJqZWN0OiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO05ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYXVyYS1lYXAtbm9vYi0wMC50eHQ8L3R0Pjxicj4NCjx0 dD5EYXRlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO01vbiwgMDggRmViIDIwMTYgMDQ6MzA6MzUgLTA4MDA8L3R0Pjxicj4NCjx0 dD5Gcm9tOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzwvdHQ+PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij48YnI+DQo8dHQ+VG86ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VHVvbWFzIEF1cmEgJmx0OzwvdHQ+PC9zcGFuPjxh IGhyZWY9Im1haWx0bzp0dW9tYXMuYXVyYUBhYWx0by5maSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnR1b21hcy5hdXJh QGFhbHRvLmZpPC9zcGFuPjwvYT48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZn dDssIE1vaGl0IFNldGhpICZsdDs8L3NwYW4+PC90dD48YSBocmVmPSJtYWlsdG86bW9oaXRAcGl1 aGEubmV0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+bW9oaXRAcGl1aGEubmV0PC9zcGFuPjwvYT48dHQ+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDs8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPHR0PkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1hdXJhLWVhcC1u b29iLTAwLnR4dDwvdHQ+PGJyPg0KPHR0PmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgVHVvbWFzIEF1cmEgYW5kIHBvc3RlZCB0byB0aGU8L3R0Pjxicj4NCjx0dD5JRVRGIHJlcG9z aXRvcnkuPC90dD48YnI+DQo8YnI+DQo8dHQ+TmFtZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LWF1cmEtZWFwLW5vb2I8 L3R0Pjxicj4NCjx0dD5SZXZpc2lvbjogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAwMDwvdHQ+PGJyPg0KPHR0PlRpdGxlOiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TmltYmxl IG91dC1vZi1iYW5kIGF1dGhlbnRpY2F0aW9uIGZvciBFQVAgKEVBUC1OT09CKTwvdHQ+PGJyPg0K PHR0PkRvY3VtZW50IGRhdGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgMjAxNi0wMi0wODwvdHQ+PGJyPg0KPHR0Pkdyb3VwOiAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SW5k aXZpZHVhbCBTdWJtaXNzaW9uPC90dD48YnI+DQo8dHQ+UGFnZXM6ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDszNTwvdHQ+PGJyPg0K PHR0PlVSTDo8L3R0Pjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtYXVyYS1lYXAtbm9vYi0wMC50eHQiPjx0dD48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWF1cmEtZWFwLW5vb2ItMDAudHh0PC9zcGFuPjwvdHQ+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+ U3RhdHVzOjwvdHQ+PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWF1cmEtZWFwLW5vb2IvIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWF1cmEtZWFwLW5vb2Iv PC9zcGFuPjwvdHQ+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+SHRtbGl6ZWQ6PC90dD48L3NwYW4+ PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWF1cmEtZWFwLW5vb2It MDAiPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWF1cmEtZWFwLW5vb2ItMDA8L3NwYW4+PC90dD48L2E+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi Pjxicj4NCjxicj4NCjxicj4NCjx0dD5BYnN0cmFjdDo8L3R0Pjxicj4NCjx0dD4mbmJzcDsgJm5i c3A7RXh0ZW5zaWJsZSBBdXRoZW50aWNhdGlvbiBQcm90b2NvbCAoRUFQKSBbUkZDMzc0OF0gcHJv dmlkZXMgc3VwcG9ydDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyAmbmJzcDtmb3IgbXVsdGlwbGUgYXV0 aGVudGljYXRpb24gbWV0aG9kcy4gJm5ic3A7VGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBFQVAt PC90dD48YnI+DQo8dHQ+Jm5ic3A7ICZuYnNwO05PT0IgYXV0aGVudGljYXRpb24gbWV0aG9kIGZv ciBuaW1ibGUgb3V0LW9mLWJhbmQgKE9PQik8L3R0Pjxicj4NCjx0dD4mbmJzcDsgJm5ic3A7YXV0 aGVudGljYXRpb24gYW5kIGtleSBkZXJpdmF0aW9uLiAmbmJzcDtUaGlzIEVBUCBtZXRob2QgaXMg aW50ZW5kZWQgZm9yPC90dD48YnI+DQo8dHQ+Jm5ic3A7ICZuYnNwO2Jvb3RzdHJhcHBpbmcgYWxs IGtpbmRzIG9mIEludGVybmV0LW9mLVRoaW5ncyAoSW9UKSBkZXZpY2VzIHRoYXQgaGF2ZTwvdHQ+ PGJyPg0KPHR0PiZuYnNwOyAmbmJzcDthIG1pbmltYWwgdXNlciBpbnRlcmZhY2UgYW5kIG5vIHBy ZS1jb25maWd1cmVkIGF1dGhlbnRpY2F0aW9uPC90dD48YnI+DQo8dHQ+Jm5ic3A7ICZuYnNwO2Ny ZWRlbnRpYWxzLiAmbmJzcDtUaGUgbWV0aG9kIG1ha2VzIHVzZSBvZiBhIHVzZXItYXNzaXN0ZWQg b25lLWRpcmVjdGlvbmFsPC90dD48YnI+DQo8dHQ+Jm5ic3A7ICZuYnNwO09PQiBjaGFubmVsIGJl dHdlZW4gdGhlIHBlZXIgZGV2aWNlIGFuZCBhdXRoZW50aWNhdGlvbiBzZXJ2ZXIuPC90dD48YnI+ DQo8YnI+DQo8dHQ+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KPC90dD48YnI+DQo8YnI+DQo8YnI+DQo8dHQ+UGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbjwvdHQ+PGJyPg0KPHR0PnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFy ZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPC90dD48YnI+DQo8YnI+DQo8dHQ+VGhlIElF VEYgU2VjcmV0YXJpYXQ8L3R0Pjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0dD5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvdHQ+PGJyPg0KPHR0PnNhYWcg bWFpbGluZyBsaXN0PC90dD48YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNhYWdAaWV0Zi5v cmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij5zYWFnQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPC9z cGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FhZyI+ PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NhYWc8L3NwYW4+PC90dD48L2E+PG86cD48L286cD48L3A+DQo8cD49 PT09PS0tLS0tPT09PT0tLS0tLT09PT09PGJyPg0KTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgZS1tYWlsPGJyPg0KbWVzc2FnZSBhbmQvb3IgYXR0YWNobWVudHMgdG8g aXQgbWF5IGNvbnRhaW4gPGJyPg0KY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRp b24uIElmIHlvdSBhcmUgPGJyPg0Kbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNz ZW1pbmF0aW9uLCB1c2UsIDxicj4NCnJldmlldywgZGlzdHJpYnV0aW9uLCBwcmludGluZyBvciBj b3B5aW5nIG9mIHRoZSA8YnI+DQppbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwg bWVzc2FnZSA8YnI+DQphbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgYXJlIHN0cmljdGx5IHByb2hp Yml0ZWQuIElmIDxicj4NCnlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBl cnJvciwgPGJyPg0KcGxlYXNlIG5vdGlmeSB1cyBieSByZXBseSBlLW1haWwgb3IgdGVsZXBob25l IGFuZCA8YnI+DQppbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBtZXNzYWdl IDxicj4NCmFuZCBhbnkgYXR0YWNobWVudHMuIFRoYW5rIHlvdTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7F9C975440487E49BBD35F4FB088ED74CFCDBBADEXMDB01orgaalto_-- From nobody Thu Feb 18 09:27:48 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F6A1ACE66 for ; Thu, 18 Feb 2016 09:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham 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 0FlCKhzpluKI for ; Thu, 18 Feb 2016 09:27:42 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03E5C1A1BF4 for ; Thu, 18 Feb 2016 09:27:41 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0019.outbound.protection.outlook.com [213.199.154.19]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-2-YBnAQ7-gSPiPQUevYBfAXw-1; Thu, 18 Feb 2016 17:27:33 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TLrxCJNd41ffxMquL5k1XCV9NpjoPJHEaKs4PzLM8hY=; b=cO49aG+XZeff3d5005BOFNn+2wKzJVCf9/M+gb6WU31guuBE+li7PhCR9vVL6Pglpr/7mXcvpbu6Tw417LwJZPvJBj6vjK8jqgTMaarVc0HXYR/OE16oIvsFqsloUnJSpzaT6Iy//puR5cTC/rcXreSwCelIKVjymtOPtkwqhmY= Received: from VI1PR07MB1581.eurprd07.prod.outlook.com (10.165.239.15) by VI1PR07MB1584.eurprd07.prod.outlook.com (10.165.239.18) with Microsoft SMTP Server (TLS) id 15.1.409.15; Thu, 18 Feb 2016 17:27:32 +0000 Received: from VI1PR07MB1581.eurprd07.prod.outlook.com ([10.165.239.15]) by VI1PR07MB1581.eurprd07.prod.outlook.com ([10.165.239.15]) with mapi id 15.01.0409.017; Thu, 18 Feb 2016 17:27:32 +0000 From: Josh Howlett To: Mohit Sethi , "saag@ietf.org" , "emu@ietf.org" Thread-Topic: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt Thread-Index: AQHRYoZDK9zX977Aak+i2I4nCLSSvZ8yG4LA Date: Thu, 18 Feb 2016 17:27:32 +0000 Message-ID: References: <20160208123035.1562.80507.idtracker@ietfa.amsl.com> <56B8B561.8040300@ericsson.com> In-Reply-To: <56B8B561.8040300@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [46.233.116.237] x-microsoft-exchange-diagnostics: 1; VI1PR07MB1584; 5:By+EScKw3u5vfREHxdx49NFwRoK4gEBUXCwX/EMtXr7+O3husbmN3IN52YgY3wv96hFFHTIWbjlCUqW8zsctle+dfz+hS9gUutivSE4t6e8+LOcFQQFEFDI0JlLIYIdHy0BBCPGHkbR2HYZ8LPHVmw==; 24:2cqHvbdICBBLYUtTJMRB9cY6LeHUtm3OionnuJSLx1p/Xg96dmyW8/MccBi6NOarabsyH2SWNuMGX/AHzpaWT6Q56EkxDC2sB9NEldrj+60=; 20:5QskwbTpn6NFLdckstdUX19RiHU5t7LyzfkiIEYtgU5XJGnLMAudk64jzKdJuB4hY16febfM0O4+DW+v57XD3nJENxyzr1wsaoxk9lrcMWK7JWvu2b+1mrr+T5FW12aRhuq+UV4BEGl0d0VHp7Xe0ixdizaeAVUIo719Ua0IG/c= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1584; x-ms-office365-filtering-correlation-id: bb78f94f-fcc7-4f97-0280-08d33888c8d4 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:VI1PR07MB1584; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1584; x-forefront-prvs: 085634EFF4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(2473001)(13464003)(377424004)(586003)(1220700001)(76576001)(102836003)(10400500002)(77096005)(15650500001)(54356999)(2900100001)(19580405001)(2950100001)(19580395003)(5002640100001)(1096002)(6116002)(50986999)(5001770100001)(5008740100001)(5001960100002)(76176999)(3846002)(74482002)(15975445007)(92566002)(5003600100002)(3660700001)(11100500001)(189998001)(106116001)(40100003)(2906002)(4326007)(122556002)(87936001)(74316001)(66066001)(86362001)(5004730100002)(3280700002)(230783001)(2501003)(33656002)(2201001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB1584; H:VI1PR07MB1581.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2016 17:27:32.4323 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1584 X-MC-Unique: YBnAQ7-gSPiPQUevYBfAXw-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 17:27:46 -0000 SGkgTW9oaXQsDQoNClRoaXMgaXMgYW4gaW50ZXJlc3RpbmcgZHJhZnQsIGJ1dCBJJ20gc3RydWdn bGluZyB0byB1bmRlcnN0YW5kIGhvdyB0aGlzIHdvdWxkIGJlIGRlcGxveWVkIGluIHRoZSBjb25z dW1lciBzZXR0aW5ncyB0aGF0IHRoZSBkb2N1bWVudCBhbGx1ZGVzIHRvLiBGb3IgZXhhbXBsZSwg d2hvIGRvIHlvdSBhbnRpY2lwYXRlIHdpbGwgYmUgb3BlcmF0aW5nIHRoZSBOQVMgKHRoZSBjb25z dW1lcj8pLCBBQUEgc2VydmVyICh0aGUgdmVuZG9yPyksIGFuZCB0aGUgQUFBIGZhYnJpYyBiZXR3 ZWVuIHRoZXNlIGFjdG9ycz8NCg0KSm9zaC4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBzYWFnIFttYWlsdG86c2FhZy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgTW9oaXQgU2V0aGkNCj4gU2VudDogMDggRmVicnVhcnkgMjAxNiAxNTozNA0KPiBUbzogc2Fh Z0BpZXRmLm9yZzsgZW11QGlldGYub3JnDQo+IENjOiB0dW9tYXMuYXVyYUBhYWx0by5maQ0KPiBT dWJqZWN0OiBbc2FhZ10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWF1 cmEtZWFwLW5vb2ItMDAudHh0DQo+IA0KPiBEZWFyIGFsbA0KPiANCj4gV2UgaGF2ZSBqdXN0IHN1 Ym1pdHRlZCBhIG5ldyBJRVRGIERyYWZ0IHRpdGxlZCDigJxOaW1ibGUgb3V0LW9mLWJhbmQNCj4g YXV0aGVudGljYXRpb24gZm9yIEVBUCAoRUFQLU5PT0Ip4oCdLg0KPiANCj4gVGhlIGRyYWZ0IGRl ZmluZXMgYW4gRUFQIG1ldGhvZCB3aGVyZSB0aGUgYXV0aGVudGljYXRpb24gaXMgYmFzZWQgb24g YQ0KPiB1c2VyLWFzc2lzdGVkIG91dC1vZi1iYW5kIChPT0IpIGNoYW5uZWwgYmV0d2VlbiB0aGUg c2VydmVyIGFuZCBwZWVyLiBJdCBpcw0KPiBpbnRlbmRlZCBhcyBhIGdlbmVyaWMgYm9vdHN0cmFw cGluZyBzb2x1dGlvbiBmb3IgSW50ZXJuZXQtb2YtVGhpbmdzIGRldmljZXMNCj4gd2hpY2ggaGF2 ZSBubyBwcmUtY29uZmlndXJlZCBhdXRoZW50aWNhdGlvbiBjcmVkZW50aWFscyBhbmQgd2hpY2gg YXJlIG5vdA0KPiB5ZXQgcmVnaXN0ZXJlZCBvbiB0aGUgYXV0aGVudGljYXRpb24gc2VydmVyLiBD b25zaWRlciBkZXZpY2VzIHlvdSBqdXN0IGJvdWdodA0KPiBvciBib3Jyb3dlZC4NCj4gDQo+IFRo ZSBFQVAtTk9PQiBtZXRob2QgaXMgbW9yZSBnZW5lcmljIHRoYW4gbW9zdCBhZC1ob2MgYm9vdHN0 cmFwcGluZw0KPiBzb2x1dGlvbnMgaW4gdGhhdCBpdCBzdXBwb3J0cyBtYW55IHR5cGVzIG9mIE9P QiBjaGFubmVscy4gV2Ugc3BlY2lmeSB0aGUNCj4gZXhhY3QgaW4tYmFuZCBtZXNzYWdlcyBidXQg b25seSB0aGUgT09CIG1lc3NhZ2UgY29udGVudHMgYW5kIG5vdCB0aGUgT09CDQo+IGNoYW5uZWwg ZGV0YWlscy4gQWxzbywgRUFQLU5PT0Igc3VwcG9ydHMgdWJpY29tcCBkZXZpY2VzIHdpdGggb25s eSBvdXRwdXQNCj4gKGUuZy4gZGlzcGxheSkgb3Igb25seSBpbnB1dCAoZS5nLiBjYW1lcmEpLiBN b3Jlb3ZlciwgaXQgbWFrZXMgY29tYmluZWQgdXNlDQo+IG9mIGJvdGggc2VjcmVjeSBhbmQgaW50 ZWdyaXR5IG9mIHRoZSBPT0IgY2hhbm5lbCBmb3IgbW9yZSByb2J1c3Qgc2VjdXJpdHkNCj4gdGhh biB0aGUgYWQtaG9jIHNvbHV0aW9ucy4gV2UgaGF2ZSBwdXQgYSBsb3Qgb2YgZWZmb3J0IGludG8g ZGVzaWduaW5nIGEgcm9idXN0DQo+IHNlY3VyaXR5IHByb3RvY29sLg0KPiANCj4gRm9yIG9uZSBh cHBsaWNhdGlvbiBleGFtcGxlLCB3ZSBoYXZlIHVzZWQgYW4gZWFybGllciB2ZXJzaW9uIG9mIHRo ZSBwcm90b2NvbA0KPiBmb3IgYm9vdHN0cmFwcGluZyBzZWN1cml0eSBmb3IgdWJpcXVpdG91cyBk aXNwbGF5czogdGhlIHVzZXIgY2FuIGNvbmZpZ3VyZQ0KPiB3aXJlbGVzcyBuZXR3b3JrIGFjY2Vz cywgbGluayB0aGUgZGV2aWNlIHRvIGEgY2xvdWQgc2VydmljZSwgYW5kIHJlZ2lzdGVyDQo+IG93 bmVyc2hpcCBvZiB0aGUgZGV2aWNlIGZvciBhIHNwZWNpZmljIGNsb3VkIHVzZXIg4oCTIGFsbCBp biBvbmUgc2ltcGxlIHN0ZXAgb2YNCj4gc2Nhbm5pbmcgYSBRUiBjb2RlIHdpdGggYSBzbWFydCBw aG9uZS4gVGhlcmUgc2VlbWVkIHRvIG1vcmUgcG90ZW50aWFsIHRvDQo+IHRoaXMgaWRlYSB0aGFu IGp1c3QgdXNpbmcgaXQgZm9yIG91ciBvd24gc3lzdGVtLCBhbmQgdGh1cyB3ZSBkZWNpZGVkIHRv IHdyaXRlDQo+IGEgZ2VuZXJpYyBFQVAgbWV0aG9kIGZvciBvdXQtb2YtYmFuZCBhdXRoZW50aWNh dGlvbi4NCj4gDQo+IFRoZSBkcmFmdCBpcyBhdmFpbGFibGUgaGVyZToNCj4gaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWF1cmEtZWFwLW5vb2ItMDANCj4gDQo+IFBsZWFzZSBzZWUg aWYgeW91IGNhbiBtYWtlIHVzZSBvZiBpdC4gV2UgbG9vayBmb3J3YXJkIHRvIHlvdXIgZmVlZGJh Y2sgYW5kDQo+IGNvbW1lbnRzLg0KPiANCj4gUmVnYXJkcw0KPiAvLS1Nb2hpdA0KPiANCj4gDQo+ IC0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tDQo+IFN1YmplY3Q6IAlOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWF1cmEtZWFwLW5vb2ItMDAudHh0DQo+IERhdGU6 IAlNb24sIDA4IEZlYiAyMDE2IDA0OjMwOjM1IC0wODAwDQo+IEZyb206IAlpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmcNCj4gVG86IAlUdW9tYXMgQXVyYSA8dHVvbWFzLmF1cmFAYWFsdG8uZmk+LCBN b2hpdCBTZXRoaQ0KPiA8bW9oaXRAcGl1aGEubmV0Pg0KPiANCj4gDQo+IA0KPiBBIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQtYXVyYS1lYXAtbm9vYi0wMC50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5DQo+IHN1Ym1pdHRlZCBieSBUdW9tYXMgQXVyYSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJl cG9zaXRvcnkuDQo+IA0KPiBOYW1lOgkJZHJhZnQtYXVyYS1lYXAtbm9vYg0KPiBSZXZpc2lvbjoJ MDANCj4gVGl0bGU6CQlOaW1ibGUgb3V0LW9mLWJhbmQgYXV0aGVudGljYXRpb24gZm9yIEVBUCAo RUFQLU5PT0IpDQo+IERvY3VtZW50IGRhdGU6CTIwMTYtMDItMDgNCj4gR3JvdXA6CQlJbmRpdmlk dWFsIFN1Ym1pc3Npb24NCj4gUGFnZXM6CQkzNQ0KPiBVUkw6aHR0cHM6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWF1cmEtZWFwLW5vb2ItMDAudHh0DQo+IFN0YXR1czpodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1hdXJhLWVhcC1ub29iLw0KPiBIdG1s aXplZDpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYXVyYS1lYXAtbm9vYi0wMA0K PiANCj4gDQo+IEFic3RyYWN0Og0KPiAgICAgRXh0ZW5zaWJsZSBBdXRoZW50aWNhdGlvbiBQcm90 b2NvbCAoRUFQKSBbUkZDMzc0OF0gcHJvdmlkZXMgc3VwcG9ydA0KPiAgICAgZm9yIG11bHRpcGxl IGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMuICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIEVBUC0N Cj4gICAgIE5PT0IgYXV0aGVudGljYXRpb24gbWV0aG9kIGZvciBuaW1ibGUgb3V0LW9mLWJhbmQg KE9PQikNCj4gICAgIGF1dGhlbnRpY2F0aW9uIGFuZCBrZXkgZGVyaXZhdGlvbi4gIFRoaXMgRUFQ IG1ldGhvZCBpcyBpbnRlbmRlZCBmb3INCj4gICAgIGJvb3RzdHJhcHBpbmcgYWxsIGtpbmRzIG9m IEludGVybmV0LW9mLVRoaW5ncyAoSW9UKSBkZXZpY2VzIHRoYXQgaGF2ZQ0KPiAgICAgYSBtaW5p bWFsIHVzZXIgaW50ZXJmYWNlIGFuZCBubyBwcmUtY29uZmlndXJlZCBhdXRoZW50aWNhdGlvbg0K PiAgICAgY3JlZGVudGlhbHMuICBUaGUgbWV0aG9kIG1ha2VzIHVzZSBvZiBhIHVzZXItYXNzaXN0 ZWQgb25lLWRpcmVjdGlvbmFsDQo+ICAgICBPT0IgY2hhbm5lbCBiZXR3ZWVuIHRoZSBwZWVyIGRl dmljZSBhbmQgYXV0aGVudGljYXRpb24gc2VydmVyLg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQN Cj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gc2FhZyBtYWlsaW5nIGxpc3QNCj4gc2FhZ0BpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhYWcNCg0KSmlzYyBpcyBhIHJlZ2lzdGVyZWQg Y2hhcml0eSAobnVtYmVyIDExNDk3NDApIGFuZCBhIGNvbXBhbnkgbGltaXRlZCBieSBndWFyYW50 ZWUgd2hpY2ggaXMgcmVnaXN0ZXJlZCBpbiBFbmdsYW5kIHVuZGVyIENvbXBhbnkgTm8uIDU3NDcz MzksIFZBVCBOby4gR0IgMTk3IDA2MzIgODYuIEppc2PigJlzIHJlZ2lzdGVyZWQgb2ZmaWNlIGlz OiBPbmUgQ2FzdGxlcGFyaywgVG93ZXIgSGlsbCwgQnJpc3RvbCwgQlMyIDBKQS4gVCAwMjAzIDY5 NyA1ODAwLg0KDQpKaXNjIFNlcnZpY2VzIExpbWl0ZWQgaXMgYSB3aG9sbHkgb3duZWQgSmlzYyBz dWJzaWRpYXJ5IGFuZCBhIGNvbXBhbnkgbGltaXRlZCBieSBndWFyYW50ZWUgd2hpY2ggaXMgcmVn aXN0ZXJlZCBpbiBFbmdsYW5kIHVuZGVyIGNvbXBhbnkgbnVtYmVyIDI4ODEwMjQsIFZBVCBudW1i ZXIgR0IgMTk3IDA2MzIgODYuIFRoZSByZWdpc3RlcmVkIG9mZmljZSBpczogT25lIENhc3RsZSBQ YXJrLCBUb3dlciBIaWxsLCBCcmlzdG9sIEJTMiAwSkEuIFQgMDIwMyA2OTcgNTgwMC4gIA0K From nobody Thu Feb 18 10:08:00 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F15B1B2CDA; Thu, 18 Feb 2016 10:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 G-KgEr7AhidU; Thu, 18 Feb 2016 10:07:47 -0800 (PST) Received: from smtp-out-01.aalto.fi (smtp-out-01.aalto.fi [130.233.228.120]) by ietfa.amsl.com (Postfix) with ESMTP id A4F981ACE42; Thu, 18 Feb 2016 10:07:46 -0800 (PST) Received: from smtp-out-01.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 47D0A11530D_6C60871B; Thu, 18 Feb 2016 18:07:45 +0000 (GMT) Received: from EXHUB02.org.aalto.fi (exhub02.org.aalto.fi [130.233.222.119]) by smtp-out-01.aalto.fi (Sophos Email Appliance) with ESMTP id F2BED1152C9_6C60870F; Thu, 18 Feb 2016 18:07:44 +0000 (GMT) Received: from EXMDB01.org.aalto.fi ([169.254.2.222]) by EXHUB02.org.aalto.fi ([130.233.222.119]) with mapi id 14.03.0224.002; Thu, 18 Feb 2016 20:07:44 +0200 From: Aura Tuomas To: Josh Howlett , Mohit Sethi , "saag@ietf.org" , "emu@ietf.org" Thread-Topic: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt Thread-Index: AQHRYmyDaEz8z8wkLU+ZyRerPC0UrZ8iJdqAgA/XEQCAACY7gA== Date: Thu, 18 Feb 2016 18:07:44 +0000 Message-ID: <7F9C975440487E49BBD35F4FB088ED74CFCDBF14@EXMDB01.org.aalto.fi> References: <20160208123035.1562.80507.idtracker@ietfa.amsl.com> <56B8B561.8040300@ericsson.com> In-Reply-To: Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [85.76.161.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 18:07:50 -0000 SGkgSm9zaCwNCg0KR29vZCBvYnNlcnZhdGlvbjsgd2UgbWF5IG5lZWQgdG8gYmUgY2xlYXJlciBh Ym91dCB0aGUgaW50ZW5kZWQgdXNhZ2Ugc2NlbmFyaW9zIGZvciBFQVAtTk9PQi4NCg0KSW4gdGhl IGhvbWUgc2V0dGluZywgdGhlIEFBQSBzZXJ2ZXIgd291bGQgdHlwaWNhbGx5IGJlIGEgY2xvdWQt YmFzZWQgc2VydmljZSwgd2hlcmUgdGhlIGNvbnN1bWVyIGNhbiByZWdpc3RlciBhIHVzZXIgYWNj b3VudC4gVGhpcyBkb2VzIHJlcXVpcmUgdGhlIDgwMi4xWCBhdXRoZW50aWNhdGlvbiAoaS5lLiBX UEEyLUVudGVycHJpc2UpIHRvIGJlIGNvbmZpZ3VyZWQgYXQgdGhlIGhvbWUgTkFTLCBzbyB0aGF0 IGF1dGhlbnRpY2F0aW9uIGZvciAiQGVhcC1ub29iLm5ldCIgaXMgZm9yd2FyZGVkIHRvIHRoZSBj bG91ZC1iYXNlZCBBQUEgc2VydmVyLiBZb3Ugb25seSBuZWVkIHRvIGNvbmZpZ3VyZSB0aGUgTkFT IG9uY2UsIGFuZCBhbGwgZnV0dXJlIGRldmljZXMgY2FuIGJlIGNvbm5lY3RlZCB3aXRob3V0IHRv dWNoaW5nIHRoZSBOQVMuDQoNClRoaXMgaXMgYSBjaGFuZ2UgZnJvbSB0aGUgd2F5IGhvbWUgd2ly ZWxlc3Mgcm91dGVycyBhcmUgY29uZmlndXJlZCB0b2RheS4gV2UgdGhpbmsgdGhhdCwgYXMgdGhl IG51bWJlciBvZiBJb1QgZGV2aWNlcyBncm93cywgY29uZmlndXJpbmcgdGhlbSB3aXRoIGEgc2hh cmVkIHBhc3NwaHJhc2Ugd2lsbCBiZSB0b28gaW5jb252ZW5pZW50LiBPYnZpb3VzbHksIHRoZSBz aGFyZWQgcGFzc3BocmFzZSBpcyBhbHNvIHZ1bG5lcmFibGUgdG8gYSBzaW5nbGUgdW50cnVzdGVk IElvVCBkZXZpY2UgdGhhdCBtYXkgbGVhayB0aGUgcGFzc3BocmFzZSwgYW5kIHVzaW5nIEVBUCBo ZWxwcyB0byBpc29sYXRlIHRoZSBkZXZpY2VzLiANCg0KT2YgY291cnNlLCB0aGUgYmVuZWZpdHMg b2YgRUFQLU5PT0Igd2lsbCBiZSBncmVhdGVyIGluIG9yZ2FuaXphdGlvbnMgd2hpY2ggYWxyZWFk eSB1c2UgODAyLjFYIGF1dGhlbnRpY2F0aW9uIGFuZCB3aGljaCBoYXZlIGxhcmdlciBudW1iZXJz IG9mIElvVCBkZXZpY2VzIHRoYW4gYSBzaW5nbGUgaG9tZS4gDQoNCkFueXRoaW5nIGVsc2UgdGhh dCB3ZSBuZWVkIHRvIGFkZHJlc3M/DQoNClR1b21hcw0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IEpvc2ggSG93bGV0dCBbbWFpbHRvOkpvc2guSG93bGV0dEBqaXNjLmFj LnVrXSANClNlbnQ6IFRodXJzZGF5LCAxOCBGZWJydWFyeSwgMjAxNiAxOToyOA0KVG86IE1vaGl0 IFNldGhpIDxtb2hpdC5tLnNldGhpQGVyaWNzc29uLmNvbT47IHNhYWdAaWV0Zi5vcmc7IGVtdUBp ZXRmLm9yZw0KQ2M6IEF1cmEgVHVvbWFzIDx0dW9tYXMuYXVyYUBhYWx0by5maT4NClN1YmplY3Q6 IFJFOiBbc2FhZ10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWF1cmEt ZWFwLW5vb2ItMDAudHh0DQoNCkhpIE1vaGl0LA0KDQpUaGlzIGlzIGFuIGludGVyZXN0aW5nIGRy YWZ0LCBidXQgSSdtIHN0cnVnZ2xpbmcgdG8gdW5kZXJzdGFuZCBob3cgdGhpcyB3b3VsZCBiZSBk ZXBsb3llZCBpbiB0aGUgY29uc3VtZXIgc2V0dGluZ3MgdGhhdCB0aGUgZG9jdW1lbnQgYWxsdWRl cyB0by4gRm9yIGV4YW1wbGUsIHdobyBkbyB5b3UgYW50aWNpcGF0ZSB3aWxsIGJlIG9wZXJhdGlu ZyB0aGUgTkFTICh0aGUgY29uc3VtZXI/KSwgQUFBIHNlcnZlciAodGhlIHZlbmRvcj8pLCBhbmQg dGhlIEFBQSBmYWJyaWMgYmV0d2VlbiB0aGVzZSBhY3RvcnM/DQoNCkpvc2guDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc2FhZyBbbWFpbHRvOnNhYWctYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1vaGl0IFNldGhpDQo+IFNlbnQ6IDA4IEZlYnJ1YXJ5IDIw MTYgMTU6MzQNCj4gVG86IHNhYWdAaWV0Zi5vcmc7IGVtdUBpZXRmLm9yZw0KPiBDYzogdHVvbWFz LmF1cmFAYWFsdG8uZmkNCj4gU3ViamVjdDogW3NhYWddIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciANCj4gZHJhZnQtYXVyYS1lYXAtbm9vYi0wMC50eHQNCj4gDQo+IERlYXIgYWxs DQo+IA0KPiBXZSBoYXZlIGp1c3Qgc3VibWl0dGVkIGEgbmV3IElFVEYgRHJhZnQgdGl0bGVkIOKA nE5pbWJsZSBvdXQtb2YtYmFuZCANCj4gYXV0aGVudGljYXRpb24gZm9yIEVBUCAoRUFQLU5PT0Ip 4oCdLg0KPiANCj4gVGhlIGRyYWZ0IGRlZmluZXMgYW4gRUFQIG1ldGhvZCB3aGVyZSB0aGUgYXV0 aGVudGljYXRpb24gaXMgYmFzZWQgb24gYSANCj4gdXNlci1hc3Npc3RlZCBvdXQtb2YtYmFuZCAo T09CKSBjaGFubmVsIGJldHdlZW4gdGhlIHNlcnZlciBhbmQgcGVlci4gDQo+IEl0IGlzIGludGVu ZGVkIGFzIGEgZ2VuZXJpYyBib290c3RyYXBwaW5nIHNvbHV0aW9uIGZvciANCj4gSW50ZXJuZXQt b2YtVGhpbmdzIGRldmljZXMgd2hpY2ggaGF2ZSBubyBwcmUtY29uZmlndXJlZCBhdXRoZW50aWNh dGlvbiANCj4gY3JlZGVudGlhbHMgYW5kIHdoaWNoIGFyZSBub3QgeWV0IHJlZ2lzdGVyZWQgb24g dGhlIGF1dGhlbnRpY2F0aW9uIA0KPiBzZXJ2ZXIuIENvbnNpZGVyIGRldmljZXMgeW91IGp1c3Qg Ym91Z2h0IG9yIGJvcnJvd2VkLg0KPiANCj4gVGhlIEVBUC1OT09CIG1ldGhvZCBpcyBtb3JlIGdl bmVyaWMgdGhhbiBtb3N0IGFkLWhvYyBib290c3RyYXBwaW5nIA0KPiBzb2x1dGlvbnMgaW4gdGhh dCBpdCBzdXBwb3J0cyBtYW55IHR5cGVzIG9mIE9PQiBjaGFubmVscy4gV2Ugc3BlY2lmeSANCj4g dGhlIGV4YWN0IGluLWJhbmQgbWVzc2FnZXMgYnV0IG9ubHkgdGhlIE9PQiBtZXNzYWdlIGNvbnRl bnRzIGFuZCBub3QgDQo+IHRoZSBPT0IgY2hhbm5lbCBkZXRhaWxzLiBBbHNvLCBFQVAtTk9PQiBz dXBwb3J0cyB1Ymljb21wIGRldmljZXMgd2l0aCANCj4gb25seSBvdXRwdXQgKGUuZy4gZGlzcGxh eSkgb3Igb25seSBpbnB1dCAoZS5nLiBjYW1lcmEpLiBNb3Jlb3ZlciwgaXQgDQo+IG1ha2VzIGNv bWJpbmVkIHVzZSBvZiBib3RoIHNlY3JlY3kgYW5kIGludGVncml0eSBvZiB0aGUgT09CIGNoYW5u ZWwgDQo+IGZvciBtb3JlIHJvYnVzdCBzZWN1cml0eSB0aGFuIHRoZSBhZC1ob2Mgc29sdXRpb25z LiBXZSBoYXZlIHB1dCBhIGxvdCANCj4gb2YgZWZmb3J0IGludG8gZGVzaWduaW5nIGEgcm9idXN0 IHNlY3VyaXR5IHByb3RvY29sLg0KPiANCj4gRm9yIG9uZSBhcHBsaWNhdGlvbiBleGFtcGxlLCB3 ZSBoYXZlIHVzZWQgYW4gZWFybGllciB2ZXJzaW9uIG9mIHRoZSANCj4gcHJvdG9jb2wgZm9yIGJv b3RzdHJhcHBpbmcgc2VjdXJpdHkgZm9yIHViaXF1aXRvdXMgZGlzcGxheXM6IHRoZSB1c2VyIA0K PiBjYW4gY29uZmlndXJlIHdpcmVsZXNzIG5ldHdvcmsgYWNjZXNzLCBsaW5rIHRoZSBkZXZpY2Ug dG8gYSBjbG91ZCANCj4gc2VydmljZSwgYW5kIHJlZ2lzdGVyIG93bmVyc2hpcCBvZiB0aGUgZGV2 aWNlIGZvciBhIHNwZWNpZmljIGNsb3VkIA0KPiB1c2VyIOKAkyBhbGwgaW4gb25lIHNpbXBsZSBz dGVwIG9mIHNjYW5uaW5nIGEgUVIgY29kZSB3aXRoIGEgc21hcnQgDQo+IHBob25lLiBUaGVyZSBz ZWVtZWQgdG8gbW9yZSBwb3RlbnRpYWwgdG8gdGhpcyBpZGVhIHRoYW4ganVzdCB1c2luZyBpdCAN Cj4gZm9yIG91ciBvd24gc3lzdGVtLCBhbmQgdGh1cyB3ZSBkZWNpZGVkIHRvIHdyaXRlIGEgZ2Vu ZXJpYyBFQVAgbWV0aG9kIGZvciBvdXQtb2YtYmFuZCBhdXRoZW50aWNhdGlvbi4NCj4gDQo+IFRo ZSBkcmFmdCBpcyBhdmFpbGFibGUgaGVyZToNCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWF1cmEtZWFwLW5vb2ItMDANCj4gDQo+IFBsZWFzZSBzZWUgaWYgeW91IGNhbiBtYWtl IHVzZSBvZiBpdC4gV2UgbG9vayBmb3J3YXJkIHRvIHlvdXIgZmVlZGJhY2sgDQo+IGFuZCBjb21t ZW50cy4NCj4gDQo+IFJlZ2FyZHMNCj4gLy0tTW9oaXQNCj4gDQo+IA0KPiAtLS0tLS0tLSBGb3J3 YXJkZWQgTWVzc2FnZSAtLS0tLS0tLQ0KPiBTdWJqZWN0OiAJTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1hdXJhLWVhcC1ub29iLTAwLnR4dA0KPiBEYXRlOiAJTW9uLCAwOCBGZWIg MjAxNiAwNDozMDozNSAtMDgwMA0KPiBGcm9tOiAJaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+ IFRvOiAJVHVvbWFzIEF1cmEgPHR1b21hcy5hdXJhQGFhbHRvLmZpPiwgTW9oaXQgU2V0aGkNCj4g PG1vaGl0QHBpdWhhLm5ldD4NCj4gDQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LWF1cmEtZWFwLW5vb2ItMDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSANCj4gc3VibWl0 dGVkIGJ5IFR1b21hcyBBdXJhIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4g DQo+IE5hbWU6CQlkcmFmdC1hdXJhLWVhcC1ub29iDQo+IFJldmlzaW9uOgkwMA0KPiBUaXRsZToJ CU5pbWJsZSBvdXQtb2YtYmFuZCBhdXRoZW50aWNhdGlvbiBmb3IgRUFQIChFQVAtTk9PQikNCj4g RG9jdW1lbnQgZGF0ZToJMjAxNi0wMi0wOA0KPiBHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lv bg0KPiBQYWdlczoJCTM1DQo+IFVSTDpodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtYXVyYS1lYXAtbm9vYi0wMC50eHQNCj4gU3RhdHVzOmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWF1cmEtZWFwLW5vb2IvDQo+IEh0bWxpemVkOmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hdXJhLWVhcC1ub29iLTAwDQo+IA0KPiANCj4gQWJz dHJhY3Q6DQo+ICAgICBFeHRlbnNpYmxlIEF1dGhlbnRpY2F0aW9uIFByb3RvY29sIChFQVApIFtS RkMzNzQ4XSBwcm92aWRlcyBzdXBwb3J0DQo+ICAgICBmb3IgbXVsdGlwbGUgYXV0aGVudGljYXRp b24gbWV0aG9kcy4gIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgRUFQLQ0KPiAgICAgTk9PQiBh dXRoZW50aWNhdGlvbiBtZXRob2QgZm9yIG5pbWJsZSBvdXQtb2YtYmFuZCAoT09CKQ0KPiAgICAg YXV0aGVudGljYXRpb24gYW5kIGtleSBkZXJpdmF0aW9uLiAgVGhpcyBFQVAgbWV0aG9kIGlzIGlu dGVuZGVkIGZvcg0KPiAgICAgYm9vdHN0cmFwcGluZyBhbGwga2luZHMgb2YgSW50ZXJuZXQtb2Yt VGhpbmdzIChJb1QpIGRldmljZXMgdGhhdCBoYXZlDQo+ICAgICBhIG1pbmltYWwgdXNlciBpbnRl cmZhY2UgYW5kIG5vIHByZS1jb25maWd1cmVkIGF1dGhlbnRpY2F0aW9uDQo+ICAgICBjcmVkZW50 aWFscy4gIFRoZSBtZXRob2QgbWFrZXMgdXNlIG9mIGEgdXNlci1hc3Npc3RlZCBvbmUtZGlyZWN0 aW9uYWwNCj4gICAgIE9PQiBjaGFubmVsIGJldHdlZW4gdGhlIHBlZXIgZGV2aWNlIGFuZCBhdXRo ZW50aWNhdGlvbiBzZXJ2ZXIuDQo+IA0KPiANCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiANCj4gc3VibWlz c2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gDQo+IA0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2Fh ZyBtYWlsaW5nIGxpc3QNCj4gc2FhZ0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NhYWcNCg0KSmlzYyBpcyBhIHJlZ2lzdGVyZWQgY2hhcml0eSAobnVt YmVyIDExNDk3NDApIGFuZCBhIGNvbXBhbnkgbGltaXRlZCBieSBndWFyYW50ZWUgd2hpY2ggaXMg cmVnaXN0ZXJlZCBpbiBFbmdsYW5kIHVuZGVyIENvbXBhbnkgTm8uIDU3NDczMzksIFZBVCBOby4g R0IgMTk3IDA2MzIgODYuIEppc2PigJlzIHJlZ2lzdGVyZWQgb2ZmaWNlIGlzOiBPbmUgQ2FzdGxl cGFyaywgVG93ZXIgSGlsbCwgQnJpc3RvbCwgQlMyIDBKQS4gVCAwMjAzIDY5NyA1ODAwLg0KDQpK aXNjIFNlcnZpY2VzIExpbWl0ZWQgaXMgYSB3aG9sbHkgb3duZWQgSmlzYyBzdWJzaWRpYXJ5IGFu ZCBhIGNvbXBhbnkgbGltaXRlZCBieSBndWFyYW50ZWUgd2hpY2ggaXMgcmVnaXN0ZXJlZCBpbiBF bmdsYW5kIHVuZGVyIGNvbXBhbnkgbnVtYmVyIDI4ODEwMjQsIFZBVCBudW1iZXIgR0IgMTk3IDA2 MzIgODYuIFRoZSByZWdpc3RlcmVkIG9mZmljZSBpczogT25lIENhc3RsZSBQYXJrLCBUb3dlciBI aWxsLCBCcmlzdG9sIEJTMiAwSkEuIFQgMDIwMyA2OTcgNTgwMC4gIA0K From nobody Thu Feb 18 10:47:00 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432491A1EFF for ; Thu, 18 Feb 2016 10:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham 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 8dZvR-pZYpFf for ; Thu, 18 Feb 2016 10:46:52 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A373A1A6EFB for ; Thu, 18 Feb 2016 10:46:51 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0080.outbound.protection.outlook.com [213.199.154.80]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-6-1WK9iURtTFKrR39ML9ZyOw-1; Thu, 18 Feb 2016 18:46:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hvqNX6XJKBMtXZAU5QCjfCD9fd+zhHYOWkCHxBzPmVw=; b=Um5sKQ54VfInTZvyiMkDtOztll4k549aziyP8IdzCxYdzGFOJNtEMDJi7BHsDe9bF7V92M9o2MMeSe2stYJfYimQGo5M8bAvfOl0FsM1ewXJRSb4Lt9UsgxzoYsl496vHw+rf4ZrIeYaUh9d4hZFT4pkdkngSUmbQ36kM2qeRi8= Received: from VI1PR07MB1581.eurprd07.prod.outlook.com (10.165.239.15) by VI1PR07MB1582.eurprd07.prod.outlook.com (10.165.239.16) with Microsoft SMTP Server (TLS) id 15.1.409.15; Thu, 18 Feb 2016 18:46:43 +0000 Received: from VI1PR07MB1581.eurprd07.prod.outlook.com ([10.165.239.15]) by VI1PR07MB1581.eurprd07.prod.outlook.com ([10.165.239.15]) with mapi id 15.01.0409.017; Thu, 18 Feb 2016 18:46:43 +0000 From: Josh Howlett To: Aura Tuomas , Mohit Sethi , "saag@ietf.org" , "emu@ietf.org" Thread-Topic: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt Thread-Index: AQHRYoZDK9zX977Aak+i2I4nCLSSvZ8yG4LAgAAN+ACAAArkqw== Date: Thu, 18 Feb 2016 18:46:42 +0000 Message-ID: References: <20160208123035.1562.80507.idtracker@ietfa.amsl.com> <56B8B561.8040300@ericsson.com> , <7F9C975440487E49BBD35F4FB088ED74CFCDBF14@EXMDB01.org.aalto.fi> In-Reply-To: <7F9C975440487E49BBD35F4FB088ED74CFCDBF14@EXMDB01.org.aalto.fi> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.129.140.11] x-microsoft-exchange-diagnostics: 1; VI1PR07MB1582; 5:SJnhJucGFcBv7y9/RpTci99BqzfIXUKSvxHBrpUMquYLOomitk/6z9yehHJbxkMxbWuZM7kBlLTftfMswviaaua6xkcvtWB86moT7E1/4fUNT2G+e+Cc8uNvecO23kWsYK1xvsVOLOvOl1oa73f+hg==; 24:Eyb5/Q+C6awxASDUbMT2NyJbiTBHawmHEEmZRkbrd/GPemAA3gRsr7of7YHTGw+Vs+dQsU1V88qaAThkxYFuIQFABSwPmwCvS0lnflC8opU=; 20:jw6qXjxig6Ky1VmDXc5StGJK3Bkk72d6aPdJIbvzdNmJAA2yoDLzJhmNxjlIxCbhnK2sHJ5xJ87qQgenVCKPqWnolciIfwV1NWHw+Hryur8pfW4a0ndENZ5TMHhA7HhE+1XNYrcNj+bI5UhNJfN/xvpdOzL+TlwROsU5U0F2BO0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1582; x-ms-office365-filtering-correlation-id: f31c9fef-171e-493d-4e88-08d33893d854 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR07MB1582; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1582; x-forefront-prvs: 085634EFF4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(13464003)(3905003)(377424004)(2473001)(586003)(10400500002)(40100003)(1096002)(5001770100001)(122556002)(93886004)(5003600100002)(3846002)(19617315012)(74482002)(77096005)(1220700001)(33656002)(102836003)(11100500001)(15650500001)(76576001)(6116002)(106116001)(50986999)(3660700001)(2501003)(107886002)(5002640100001)(5008740100001)(16236675004)(3900700001)(3280700002)(87936001)(74316001)(92566002)(189998001)(76176999)(2950100001)(2906002)(230783001)(15975445007)(66066001)(5004730100002)(2900100001)(86362001)(19580395003)(54356999)(19625215002)(2201001)(19580405001)(5001960100002)(19627235001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB1582; H:VI1PR07MB1581.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2016 18:46:42.8092 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1582 X-MC-Unique: 1WK9iURtTFKrR39ML9ZyOw-1 Content-Type: multipart/alternative; boundary="_000_VI1PR07MB1581DF9BB31E2F22BE7E1383BCAF0VI1PR07MB1581eurp_" Archived-At: Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 18:46:57 -0000 --_000_VI1PR07MB1581DF9BB31E2F22BE7E1383BCAF0VI1PR07MB1581eurp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi Aura, A couple of other questions on the deployment theme: 1. How would requests towards the single special people realm get dis= ambiguated among the multiple AAA servers? 2. In fact, what=92s the need for this special purpose realm at all = =96 why not let the vendor burn one into the firmware, and use an intermedi= ate AAA routing fabric do the AAA server discovery? 3. Why this and not WPS (or something similar?) Josh. Sent from Outlook Mail fo= r Windows 10 phone From: Aura Tuomas Sent: 18 February 2016 18:07 To: Josh Howlett; Mohit Sethi; saag@ietf.org; emu@ietf.org Subject: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-0= 0.txt Hi Josh, Good observation; we may need to be clearer about the intended usage scenar= ios for EAP-NOOB. In the home setting, the AAA server would typically be a cloud-based servic= e, where the consumer can register a user account. This does require the 80= 2.1X authentication (i.e. WPA2-Enterprise) to be configured at the home NAS= , so that authentication for "@eap-noob.net" is forwarded to the cloud-base= d AAA server. You only need to configure the NAS once, and all future devic= es can be connected without touching the NAS. This is a change from the way home wireless routers are configured today. W= e think that, as the number of IoT devices grows, configuring them with a s= hared passphrase will be too inconvenient. Obviously, the shared passphrase= is also vulnerable to a single untrusted IoT device that may leak the pass= phrase, and using EAP helps to isolate the devices. Of course, the benefits of EAP-NOOB will be greater in organizations which = already use 802.1X authentication and which have larger numbers of IoT devi= ces than a single home. Anything else that we need to address? Tuomas -----Original Message----- From: Josh Howlett [mailto:Josh.Howlett@jisc.ac.uk] Sent: Thursday, 18 February, 2016 19:28 To: Mohit Sethi ; saag@ietf.org; emu@ietf.org Cc: Aura Tuomas Subject: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-0= 0.txt Hi Mohit, This is an interesting draft, but I'm struggling to understand how this wou= ld be deployed in the consumer settings that the document alludes to. For e= xample, who do you anticipate will be operating the NAS (the consumer?), AA= A server (the vendor?), and the AAA fabric between these actors? Josh. > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Mohit Sethi > Sent: 08 February 2016 15:34 > To: saag@ietf.org; emu@ietf.org > Cc: tuomas.aura@aalto.fi > Subject: [saag] Fwd: New Version Notification for > draft-aura-eap-noob-00.txt > > Dear all > > We have just submitted a new IETF Draft titled =93Nimble out-of-band > authentication for EAP (EAP-NOOB)=94. > > The draft defines an EAP method where the authentication is based on a > user-assisted out-of-band (OOB) channel between the server and peer. > It is intended as a generic bootstrapping solution for > Internet-of-Things devices which have no pre-configured authentication > credentials and which are not yet registered on the authentication > server. Consider devices you just bought or borrowed. > > The EAP-NOOB method is more generic than most ad-hoc bootstrapping > solutions in that it supports many types of OOB channels. We specify > the exact in-band messages but only the OOB message contents and not > the OOB channel details. Also, EAP-NOOB supports ubicomp devices with > only output (e.g. display) or only input (e.g. camera). Moreover, it > makes combined use of both secrecy and integrity of the OOB channel > for more robust security than the ad-hoc solutions. We have put a lot > of effort into designing a robust security protocol. > > For one application example, we have used an earlier version of the > protocol for bootstrapping security for ubiquitous displays: the user > can configure wireless network access, link the device to a cloud > service, and register ownership of the device for a specific cloud > user =96 all in one simple step of scanning a QR code with a smart > phone. There seemed to more potential to this idea than just using it > for our own system, and thus we decided to write a generic EAP method for= out-of-band authentication. > > The draft is available here: > https://tools.ietf.org/html/draft-aura-eap-noob-00 > > Please see if you can make use of it. We look forward to your feedback > and comments. > > Regards > /--Mohit > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-aura-eap-noob-00.txt > Date: Mon, 08 Feb 2016 04:30:35 -0800 > From: internet-drafts@ietf.org > To: Tuomas Aura , Mohit Sethi > > > > > A new version of I-D, draft-aura-eap-noob-00.txt has been successfully > submitted by Tuomas Aura and posted to the IETF repository. > > Name: draft-aura-eap-noob > Revision: 00 > Title: Nimble out-of-band authentication for EAP (EAP-NOOB= ) > Document date: 2016-02-08 > Group: Individual Submission > Pages: 35 > URL:https://www.ietf.org/internet-drafts/draft-aura-eap-noob-00.txt > Status:https://datatracker.ietf.org/doc/draft-aura-eap-noob/ > Htmlized:https://tools.ietf.org/html/draft-aura-eap-noob-00 > > > Abstract: > Extensible Authentication Protocol (EAP) [RFC3748] provides support > for multiple authentication methods. This document defines the EAP- > NOOB authentication method for nimble out-of-band (OOB) > authentication and key derivation. This EAP method is intended for > bootstrapping all kinds of Internet-of-Things (IoT) devices that have > a minimal user interface and no pre-configured authentication > credentials. The method makes use of a user-assisted one-directional > OOB channel between the peer device and authentication server. > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.iet= f.org. > > The IETF Secretariat > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag Jisc is a registered charity (number 1149740) and a company limited by guar= antee which is registered in England under Company No. 5747339, VAT No. GB = 197 0632 86. Jisc=92s registered office is: One Castlepark, Tower Hill, Bri= stol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limit= ed by guarantee which is registered in England under company number 2881024= , VAT number GB 197 0632 86. The registered office is: One Castle Park, Tow= er Hill, Bristol BS2 0JA. T 0203 697 5800. --_000_VI1PR07MB1581DF9BB31E2F22BE7E1383BCAF0VI1PR07MB1581eurp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
Hi Josh,

Good observation; we may need to be clearer about the intended usage scenar= ios for EAP-NOOB.

In the home setting, the AAA server would typically be a cloud-based servic= e, where the consumer can register a user account. This does require the 80= 2.1X authentication (i.e. WPA2-Enterprise) to be configured at the home NAS= , so that authentication for "@eap-noob.net" is forwarded to the cloud-based AAA server. You only need to configure the= NAS once, and all future devices can be connected without touching the NAS= .

This is a change from the way home wireless routers are configured today. W= e think that, as the number of IoT devices grows, configuring them with a s= hared passphrase will be too inconvenient. Obviously, the shared passphrase= is also vulnerable to a single untrusted IoT device that may leak the passphrase, and using EAP helps to = isolate the devices.

Of course, the benefits of EAP-NOOB will be greater in organizations which = already use 802.1X authentication and which have larger numbers of IoT devi= ces than a single home.

Anything else that we need to address?

Tuomas



-----Original Message-----
From: Josh Howlett [mailto:Josh.= Howlett@jisc.ac.uk]
Sent: Thursday, 18 February, 2016 19:28
To: Mohit Sethi <mohit.m.sethi@ericsson.com>; saag@ietf.org; emu@ietf= .org
Cc: Aura Tuomas <tuomas.aura@aalto.fi>
Subject: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-0= 0.txt

Hi Mohit,

This is an interesting draft, but I'm struggling to understand how this wou= ld be deployed in the consumer settings that the document alludes to. For e= xample, who do you anticipate will be operating the NAS (the consumer?), AA= A server (the vendor?), and the AAA fabric between these actors?

Josh.

> -----Original Message-----
> From: saag [mailto:saag-bounc= es@ietf.org] On Behalf Of Mohit Sethi
> Sent: 08 February 2016 15:34
> To: saag@ietf.org; emu@ietf.org
> Cc: tuomas.aura@aalto.fi
> Subject: [saag] Fwd: New Version Notification for
> draft-aura-eap-noob-00.txt
>
> Dear all
>
> We have just submitted a new IETF Draft titled =93Nimble out-of-band <= br> > authentication for EAP (EAP-NOOB)=94.
>
> The draft defines an EAP method where the authentication is based on a=
> user-assisted out-of-band (OOB) channel between the server and peer. <= br> > It is intended as a generic bootstrapping solution for
> Internet-of-Things devices which have no pre-configured authentication=
> credentials and which are not yet registered on the authentication > server. Consider devices you just bought or borrowed.
>
> The EAP-NOOB method is more generic than most ad-hoc bootstrapping > solutions in that it supports many types of OOB channels. We specify <= br> > the exact in-band messages but only the OOB message contents and not <= br> > the OOB channel details. Also, EAP-NOOB supports ubicomp devices with =
> only output (e.g. display) or only input (e.g. camera). Moreover, it <= br> > makes combined use of both secrecy and integrity of the OOB channel > for more robust security than the ad-hoc solutions. We have put a lot =
> of effort into designing a robust security protocol.
>
> For one application example, we have used an earlier version of the > protocol for bootstrapping security for ubiquitous displays: the user =
> can configure wireless network access, link the device to a cloud
> service, and register ownership of the device for a specific cloud > user =96 all in one simple step of scanning a QR code with a smart > phone. There seemed to more potential to this idea than just using it =
> for our own system, and thus we decided to write a generic EAP method = for out-of-band authentication.
>
> The draft is available here:
> https:/= /tools.ietf.org/html/draft-aura-eap-noob-00
>
> Please see if you can make use of it. We look forward to your feedback=
> and comments.
>
> Regards
> /--Mohit
>
>
> -------- Forwarded Message --------
> Subject:       New Version Notification = for draft-aura-eap-noob-00.txt
> Date:  Mon, 08 Feb 2016 04:30:35 -0800
> From:  internet-drafts@ietf.org
> To:    Tuomas Aura <tuomas.aura@aalto.fi>, Mohit = Sethi
> <mohit@piuha.net>
>
>
>
> A new version of I-D, draft-aura-eap-noob-00.txt has been successfully=
> submitted by Tuomas Aura and posted to the IETF repository.
>
> Name:         draft-aura-eap-n= oob
> Revision:     00
> Title:          &nbs= p;     Nimble out-of-band authentication for EAP (EAP-N= OOB)
> Document date:        2016-02-08 > Group:          &nbs= p;     Individual Submission
> Pages:          &nbs= p;     35
> URL:https://www.ietf.org/internet-drafts/draft-aura-eap-noob-00.txt > Status:https://datatracker.ietf.org/doc/draft-aura-eap-noob/
> Htmlized:https://tools.ietf.org/html/draft-aura-eap-noob-00
>
>
> Abstract:
>     Extensible Authentication Protocol (EAP) [RFC3= 748] provides support
>     for multiple authentication methods.  Thi= s document defines the EAP-
>     NOOB authentication method for nimble out-of-b= and (OOB)
>     authentication and key derivation.  This = EAP method is intended for
>     bootstrapping all kinds of Internet-of-Things = (IoT) devices that have
>     a minimal user interface and no pre-configured= authentication
>     credentials.  The method makes use of a u= ser-assisted one-directional
>     OOB channel between the peer device and authen= tication server.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at tools.= ietf.org.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.iet= f.org/mailman/listinfo/saag

Jisc is a registered charity (number 1149740) and a company limited by guar= antee which is registered in England under Company No. 5747339, VAT No. GB = 197 0632 86. Jisc=92s registered office is: One Castlepark, Tower Hill, Bri= stol, BS2 0JA. T 0203 697 5800.

Jisc Services Limited is a wholly owned Jisc subsidiary and a company limit= ed by guarantee which is registered in England under company number 2881024= , VAT number GB 197 0632 86. The registered office is: One Castle Park, Tow= er Hill, Bristol BS2 0JA. T 0203 697 5800. 
--_000_VI1PR07MB1581DF9BB31E2F22BE7E1383BCAF0VI1PR07MB1581eurp_-- From nobody Thu Feb 18 11:06:01 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C3B1B305D for ; Thu, 18 Feb 2016 11:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham 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 qs2PUJH9xL3I for ; Thu, 18 Feb 2016 11:05:56 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0C211ACEA6 for ; Thu, 18 Feb 2016 11:05:55 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0076.outbound.protection.outlook.com [213.199.154.76]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-36-0-9X5F6uRWmm-giyLIIpjQ-1; Thu, 18 Feb 2016 19:05:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yUNtL6tt7ufmRGWvp5jllioig+k33vwcvhZQkzQGoCI=; b=jfFtWFU/oy54ZcvJ3dyImBxGnmgIzc92hwjGDuHZmdWLImQgdhEAst4TgdlTkZYLoC7bfXOVhWkItgpVSDRWNFc6ioGrf/C+Z1JWe+djfzh7RbHe+5M476B3R9HNfbxKFFN615Bs6Viosuly3hY0ll5pPIbnDNuyX2i4WZObsY8= Received: from VI1PR07MB1581.eurprd07.prod.outlook.com (10.165.239.15) by VI1PR07MB1581.eurprd07.prod.outlook.com (10.165.239.15) with Microsoft SMTP Server (TLS) id 15.1.409.15; Thu, 18 Feb 2016 19:05:47 +0000 Received: from VI1PR07MB1581.eurprd07.prod.outlook.com ([10.165.239.15]) by VI1PR07MB1581.eurprd07.prod.outlook.com ([10.165.239.15]) with mapi id 15.01.0409.017; Thu, 18 Feb 2016 19:05:47 +0000 From: Josh Howlett To: Aura Tuomas , Mohit Sethi , "saag@ietf.org" , "emu@ietf.org" Thread-Topic: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt Thread-Index: AQHRYoZDK9zX977Aak+i2I4nCLSSvZ8yG4LAgAAN+ACAAArkq4AABVRi Date: Thu, 18 Feb 2016 19:05:47 +0000 Message-ID: References: <20160208123035.1562.80507.idtracker@ietfa.amsl.com> <56B8B561.8040300@ericsson.com> , <7F9C975440487E49BBD35F4FB088ED74CFCDBF14@EXMDB01.org.aalto.fi>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.129.140.11] x-microsoft-exchange-diagnostics: 1; VI1PR07MB1581; 5:OGEWhU+aBdbRxgJsbG7Pwysla5GNzRYzUvjavpPX7y8kV7R7mtzjxjAVPG8C5OoCb8fn4mxHgghITsJaBRpjZOcmoRPAMjg8llQpLvY4N65BRVue2koKMMcWJUv+U3pueTESSV07Bt9RR8InqXW9/g==; 24:aR6OLodE6dTQecJ7HIyhnSuSrqLrt2jV0zGrN0YD2CdBDiB0mQmxISs3emQTxMJo4N2IcEJJzugQEYqItmvAxZz9d1f6KcyJrw0YxF9l3ZI=; 20:b1sTtd4Erof2Plr2OsjrWOK+W+s4wy13rRGq4Gx5gi5KJqQQ4zGe7fVA14oIipTF3XpMNrWESeSGjXJ2IRY9LwgOq6WSnlIoP1Of9tGtnVpkdOH1LKXmSDNNTm5GPTc7XGgE8wz5XO82NX3ztbwyGv7k/Li4lY2HLsCNbBwWT4w= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1581; x-ms-office365-filtering-correlation-id: ee40a5ba-9388-4a4f-645d-08d338968267 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR07MB1581; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1581; x-forefront-prvs: 085634EFF4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377424004)(13464003)(2473001)(3905003)(40100003)(15650500001)(2201001)(93886004)(2900100001)(586003)(6116002)(189998001)(11100500001)(86362001)(3846002)(122556002)(5008740100001)(74316001)(5001770100001)(2950100001)(87936001)(107886002)(1096002)(74482002)(102836003)(5002640100001)(2906002)(230783001)(3660700001)(19617315012)(16236675004)(19580405001)(5003600100002)(10400500002)(19625215002)(2501003)(3280700002)(77096005)(19580395003)(66066001)(106116001)(5001960100002)(1220700001)(92566002)(54356999)(50986999)(76576001)(76176999)(5004730100002)(15975445007)(33656002)(3900700001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB1581; H:VI1PR07MB1581.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2016 19:05:47.0779 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1581 X-MC-Unique: 0-9X5F6uRWmm-giyLIIpjQ-1 Content-Type: multipart/alternative; boundary="_000_VI1PR07MB1581375F3F25055C60A72362BCAF0VI1PR07MB1581eurp_" Archived-At: Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 19:06:00 -0000 --_000_VI1PR07MB1581375F3F25055C60A72362BCAF0VI1PR07MB1581eurp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Sorry, ignore question 3, it makes no sense here. From: Josh Howlett Sent: 18 February 2016 18:47 To: Aura Tuomas; Mohit Sethi; saag@ietf.org; emu@ietf.org Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap-noob-0= 0.txt Hi Aura, A couple of other questions on the deployment theme: 1. How would requests towards the single special people realm get dis= ambiguated among the multiple AAA servers? 2. In fact, what=92s the need for this special purpose realm at all = =96 why not let the vendor burn one into the firmware, and use an intermedi= ate AAA routing fabric do the AAA server discovery? 3. Why this and not WPS (or something similar?) Josh. Sent from Outlook Mail fo= r Windows 10 phone From: Aura Tuomas Sent: 18 February 2016 18:07 To: Josh Howlett; Mohit Sethi; saag@ietf.org; emu@ietf.org Subject: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-0= 0.txt Hi Josh, Good observation; we may need to be clearer about the intended usage scenar= ios for EAP-NOOB. In the home setting, the AAA server would typically be a cloud-based servic= e, where the consumer can register a user account. This does require the 80= 2.1X authentication (i.e. WPA2-Enterprise) to be configured at the home NAS= , so that authentication for "@eap-noob.net" is forwarded to the cloud-base= d AAA server. You only need to configure the NAS once, and all future devic= es can be connected without touching the NAS. This is a change from the way home wireless routers are configured today. W= e think that, as the number of IoT devices grows, configuring them with a s= hared passphrase will be too inconvenient. Obviously, the shared passphrase= is also vulnerable to a single untrusted IoT device that may leak the pass= phrase, and using EAP helps to isolate the devices. Of course, the benefits of EAP-NOOB will be greater in organizations which = already use 802.1X authentication and which have larger numbers of IoT devi= ces than a single home. Anything else that we need to address? Tuomas -----Original Message----- From: Josh Howlett [mailto:Josh.Howlett@jisc.ac.uk] Sent: Thursday, 18 February, 2016 19:28 To: Mohit Sethi ; saag@ietf.org; emu@ietf.org Cc: Aura Tuomas Subject: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-0= 0.txt Hi Mohit, This is an interesting draft, but I'm struggling to understand how this wou= ld be deployed in the consumer settings that the document alludes to. For e= xample, who do you anticipate will be operating the NAS (the consumer?), AA= A server (the vendor?), and the AAA fabric between these actors? Josh. > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Mohit Sethi > Sent: 08 February 2016 15:34 > To: saag@ietf.org; emu@ietf.org > Cc: tuomas.aura@aalto.fi > Subject: [saag] Fwd: New Version Notification for > draft-aura-eap-noob-00.txt > > Dear all > > We have just submitted a new IETF Draft titled =93Nimble out-of-band > authentication for EAP (EAP-NOOB)=94. > > The draft defines an EAP method where the authentication is based on a > user-assisted out-of-band (OOB) channel between the server and peer. > It is intended as a generic bootstrapping solution for > Internet-of-Things devices which have no pre-configured authentication > credentials and which are not yet registered on the authentication > server. Consider devices you just bought or borrowed. > > The EAP-NOOB method is more generic than most ad-hoc bootstrapping > solutions in that it supports many types of OOB channels. We specify > the exact in-band messages but only the OOB message contents and not > the OOB channel details. Also, EAP-NOOB supports ubicomp devices with > only output (e.g. display) or only input (e.g. camera). Moreover, it > makes combined use of both secrecy and integrity of the OOB channel > for more robust security than the ad-hoc solutions. We have put a lot > of effort into designing a robust security protocol. > > For one application example, we have used an earlier version of the > protocol for bootstrapping security for ubiquitous displays: the user > can configure wireless network access, link the device to a cloud > service, and register ownership of the device for a specific cloud > user =96 all in one simple step of scanning a QR code with a smart > phone. There seemed to more potential to this idea than just using it > for our own system, and thus we decided to write a generic EAP method for= out-of-band authentication. > > The draft is available here: > https://tools.ietf.org/html/draft-aura-eap-noob-00 > > Please see if you can make use of it. We look forward to your feedback > and comments. > > Regards > /--Mohit > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-aura-eap-noob-00.txt > Date: Mon, 08 Feb 2016 04:30:35 -0800 > From: internet-drafts@ietf.org > To: Tuomas Aura , Mohit Sethi > > > > > A new version of I-D, draft-aura-eap-noob-00.txt has been successfully > submitted by Tuomas Aura and posted to the IETF repository. > > Name: draft-aura-eap-noob > Revision: 00 > Title: Nimble out-of-band authentication for EAP (EAP-NOOB= ) > Document date: 2016-02-08 > Group: Individual Submission > Pages: 35 > URL:https://www.ietf.org/internet-drafts/draft-aura-eap-noob-00.txt > Status:https://datatracker.ietf.org/doc/draft-aura-eap-noob/ > Htmlized:https://tools.ietf.org/html/draft-aura-eap-noob-00 > > > Abstract: > Extensible Authentication Protocol (EAP) [RFC3748] provides support > for multiple authentication methods. This document defines the EAP- > NOOB authentication method for nimble out-of-band (OOB) > authentication and key derivation. This EAP method is intended for > bootstrapping all kinds of Internet-of-Things (IoT) devices that have > a minimal user interface and no pre-configured authentication > credentials. The method makes use of a user-assisted one-directional > OOB channel between the peer device and authentication server. > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.iet= f.org. > > The IETF Secretariat > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag Jisc is a registered charity (number 1149740) and a company limited by guar= antee which is registered in England under Company No. 5747339, VAT No. GB = 197 0632 86. Jisc=92s registered office is: One Castlepark, Tower Hill, Bri= stol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limit= ed by guarantee which is registered in England under company number 2881024= , VAT number GB 197 0632 86. The registered office is: One Castle Park, Tow= er Hill, Bristol BS2 0JA. T 0203 697 5800. --_000_VI1PR07MB1581375F3F25055C60A72362BCAF0VI1PR07MB1581eurp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Sorry, ignore question 3, it makes no sense here.

 

From: Josh Howlett
Sent: 18 February 2016 18:47
To: Aura Tuomas; Mohit Sethi; saag@ietf.org; emu@ietf.org
Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap= -noob-00.txt

 

Hi Aura,

 

A couple of other questions on the deployment them= e:

 

1.  =      How would requests towards the single special people realm ge= t disambiguated among the multiple AAA servers?

2.  =      In fact, what=92s the need for this special purpose realm at = all =96 why not let the vendor burn one into the firmware, and use an inter= mediate AAA routing fabric do the AAA server discovery?

3.  =      Why this and not WPS (or something similar?)

 

Josh.

 

 

 

Sent from Outlook Mail for Windows 10 phone

 

From: Aura Tuomas
Sent: 18 February 2016 18:07
To: Josh Howlett; Mohit Sethi; saag@ietf.org; emu@ietf.org
Subject: RE: [saag] Fwd: New Version Notification for draft-aura-eap= -noob-00.txt

 

Hi Josh,

Good observation; we may need to be clearer about the intended usage scenar= ios for EAP-NOOB.

In the home setting, the AAA server would typically be a cloud-based servic= e, where the consumer can register a user account. This does require the 80= 2.1X authentication (i.e. WPA2-Enterprise) to be configured at the home NAS= , so that authentication for "@eap-noob.net" is forwarded to the cloud-based AAA server. You only need to configure the= NAS once, and all future devices can be connected without touching the NAS= .

This is a change from the way home wireless routers are configured today. W= e think that, as the number of IoT devices grows, configuring them with a s= hared passphrase will be too inconvenient. Obviously, the shared passphrase= is also vulnerable to a single untrusted IoT device that may leak the passphrase, and using EAP helps to = isolate the devices.

Of course, the benefits of EAP-NOOB will be greater in organizations which = already use 802.1X authentication and which have larger numbers of IoT devi= ces than a single home.

Anything else that we need to address?

Tuomas



-----Original Message-----
From: Josh Howlett [mailto:Josh.= Howlett@jisc.ac.uk]
Sent: Thursday, 18 February, 2016 19:28
To: Mohit Sethi <mohit.m.sethi@ericsson.com>; saag@ietf.org; emu@ietf= .org
Cc: Aura Tuomas <tuomas.aura@aalto.fi>
Subject: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-0= 0.txt

Hi Mohit,

This is an interesting draft, but I'm struggling to understand how this wou= ld be deployed in the consumer settings that the document alludes to. For e= xample, who do you anticipate will be operating the NAS (the consumer?), AA= A server (the vendor?), and the AAA fabric between these actors?

Josh.

> -----Original Message-----
> From: saag [mailto:saag-bounc= es@ietf.org] On Behalf Of Mohit Sethi
> Sent: 08 February 2016 15:34
> To: saag@ietf.org; emu@ietf.org
> Cc: tuomas.aura@aalto.fi
> Subject: [saag] Fwd: New Version Notification for
> draft-aura-eap-noob-00.txt
>
> Dear all
>
> We have just submitted a new IETF Draft titled =93Nimble out-of-band <= br> > authentication for EAP (EAP-NOOB)=94.
>
> The draft defines an EAP method where the authentication is based on a=
> user-assisted out-of-band (OOB) channel between the server and peer. <= br> > It is intended as a generic bootstrapping solution for
> Internet-of-Things devices which have no pre-configured authentication=
> credentials and which are not yet registered on the authentication > server. Consider devices you just bought or borrowed.
>
> The EAP-NOOB method is more generic than most ad-hoc bootstrapping > solutions in that it supports many types of OOB channels. We specify <= br> > the exact in-band messages but only the OOB message contents and not <= br> > the OOB channel details. Also, EAP-NOOB supports ubicomp devices with =
> only output (e.g. display) or only input (e.g. camera). Moreover, it <= br> > makes combined use of both secrecy and integrity of the OOB channel > for more robust security than the ad-hoc solutions. We have put a lot =
> of effort into designing a robust security protocol.
>
> For one application example, we have used an earlier version of the > protocol for bootstrapping security for ubiquitous displays: the user =
> can configure wireless network access, link the device to a cloud
> service, and register ownership of the device for a specific cloud > user =96 all in one simple step of scanning a QR code with a smart > phone. There seemed to more potential to this idea than just using it =
> for our own system, and thus we decided to write a generic EAP method = for out-of-band authentication.
>
> The draft is available here:
> https:/= /tools.ietf.org/html/draft-aura-eap-noob-00
>
> Please see if you can make use of it. We look forward to your feedback=
> and comments.
>
> Regards
> /--Mohit
>
>
> -------- Forwarded Message --------
> Subject:       New Version Notification = for draft-aura-eap-noob-00.txt
> Date:  Mon, 08 Feb 2016 04:30:35 -0800
> From:  internet-drafts@ietf.org
> To:    Tuomas Aura <tuomas.aura@aalto.fi>, Mohit = Sethi
> <mohit@piuha.net>
>
>
>
> A new version of I-D, draft-aura-eap-noob-00.txt has been successfully=
> submitted by Tuomas Aura and posted to the IETF repository.
>
> Name:         draft-aura-eap-n= oob
> Revision:     00
> Title:          &nbs= p;     Nimble out-of-band authentication for EAP (EAP-N= OOB)
> Document date:        2016-02-08 > Group:          &nbs= p;     Individual Submission
> Pages:          &nbs= p;     35
> URL:https://www.ietf.org/internet-drafts/draft-aura-eap-noob-00.txt > Status:https://datatracker.ietf.org/doc/draft-aura-eap-noob/
> Htmlized:https://tools.ietf.org/html/draft-aura-eap-noob-00
>
>
> Abstract:
>     Extensible Authentication Protocol (EAP) [RFC3= 748] provides support
>     for multiple authentication methods.  Thi= s document defines the EAP-
>     NOOB authentication method for nimble out-of-b= and (OOB)
>     authentication and key derivation.  This = EAP method is intended for
>     bootstrapping all kinds of Internet-of-Things = (IoT) devices that have
>     a minimal user interface and no pre-configured= authentication
>     credentials.  The method makes use of a u= ser-assisted one-directional
>     OOB channel between the peer device and authen= tication server.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at tools.= ietf.org.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.iet= f.org/mailman/listinfo/saag

Jisc is a registered charity (number 1149740) and a company limited by guar= antee which is registered in England under Company No. 5747339, VAT No. GB = 197 0632 86. Jisc=92s registered office is: One Castlepark, Tower Hill, Bri= stol, BS2 0JA. T 0203 697 5800.

Jisc Services Limited is a wholly owned Jisc subsidiary and a company limit= ed by guarantee which is registered in England under company number 2881024= , VAT number GB 197 0632 86. The registered office is: One Castle Park, Tow= er Hill, Bristol BS2 0JA. T 0203 697 5800. 
--_000_VI1PR07MB1581375F3F25055C60A72362BCAF0VI1PR07MB1581eurp_-- From nobody Fri Feb 19 09:59:53 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4B51A6FE5 for ; Fri, 19 Feb 2016 05:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.308 X-Spam-Level: X-Spam-Status: No, score=-4.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Y9QHxsmCRlMJ for ; Fri, 19 Feb 2016 05:48:38 -0800 (PST) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 886A51A6FDA for ; Fri, 19 Feb 2016 05:48:37 -0800 (PST) X-DKIM: Courier DKIM Filter v0.50+pk-2016-01-27 mail.cs.helsinki.fi Fri, 19 Feb 2016 15:48:32 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=to:from:subject:message-id:date:mime-version:content-type :content-transfer-encoding; s=dkim20130528; bh=T00SABMJ0mqPDmeGE LXIGGIHp8kn8++VEKCeu8Z4gAc=; b=APcwDBpk1ihqjqQlZKPX5qFdYRTsNxx7U Nyrj/24y6Y26IPLHOGYiDa4RR9DLbfrq+QiI5Wfc3dLytilCPYHwUbPpqrhEzqhg EbQfP4VQHPTR04e1rft3By69qAzJUb8DdMWy1bSO+u/GIuQ+rKrl9KF8oKWG4ODh JX+BgEvzG0= Received: from [198.18.17.230] ([188.126.80.45]) (AUTH: PLAIN gurtov, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by mail.cs.helsinki.fi with ESMTPSA; Fri, 19 Feb 2016 15:48:32 +0200 id 00000000005A0045.0000000056C71D30.00007299 To: saag@ietf.org From: Andrei Gurtov X-Enigmail-Draft-Status: N1110 Message-ID: <56C71D30.10506@cs.helsinki.fi> Date: Fri, 19 Feb 2016 15:48:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Fri, 19 Feb 2016 09:59:51 -0800 Subject: [saag] feedback on draft-aura-eap-noob-00 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 13:48:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I read the new draft draft-aura-eap-noob-00.txt and just want to provide some comments on it. I think the draft is quite useful as it provides an opportunity to enroll new devices to network which has only limited communication capabilities (e.g. a public display). The draft is very readable and almost complete, i didn't find any typos or obvious omissions in it. The NOOB name is kind of funny, but I guess authors chose it intentionally. About the protocol, I'm wondering if explicit OOB authentication is needed if during DH it's possible to transmit one of the messages on the other channel or spread the messages using coding over multiple channels. See e.g. http://link.springer.com/chapter/10.1007%2F978-3-642-41717-7_24 In Security claims sec 5.4 there is no mentioning of DoS attacks. Is the protocol vulnerable to those? Is there a need to employ a puzzle mechanism, for example? BR Andrei - -- Andrei Gurtov, PhD, ACM Distinguished Scientist IEEE ComSoc Distinguished Lecturer & Vice-chair, IEEE Finland Principal Scientist, Helsinki Institute for Information Technology HIIT Adjunct Professor Aalto University, University of Oulu and University of Helsinki http://www.hiit.fi/~gurtov https://www.researchgate.net/profile/Andrei_Gurtov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlbHHTAACgkQP7jp0uceFkSdfQCdFiX5EvvpmgDRA1x4qn6h3fxm KXIAoI+uCh5km2sqAFe+D7ovCg06Uez2 =rOEB -----END PGP SIGNATURE----- From nobody Mon Feb 29 09:02:49 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6E01B37BF for ; Mon, 29 Feb 2016 09:02:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.199 X-Spam-Level: X-Spam-Status: No, score=-99.199 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 m2ry9mc95LHL for ; Mon, 29 Feb 2016 09:02:42 -0800 (PST) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 517721B37BA for ; Mon, 29 Feb 2016 09:02:37 -0800 (PST) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id BF500F9C024 for ; Mon, 29 Feb 2016 12:02:36 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id FunvuWdFW06g for ; Mon, 29 Feb 2016 11:50:56 -0500 (EST) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id DD376F9C00F for ; Mon, 29 Feb 2016 12:02:34 -0500 (EST) From: Russ Housley Content-Type: multipart/alternative; boundary=Apple-Mail-67--430698928 Date: Mon, 29 Feb 2016 12:02:34 -0500 Message-Id: <3ADA49CD-3817-462C-A8BC-1F638482DFCB@vigilsec.com> To: IETF SAAG Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: Subject: [saag] Call for Papers: 3rd International Conference on Security (SSR 2016) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 17:02:46 -0000 --Apple-Mail-67--430698928 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Call for Papers SSR 2016: 3rd International Conference on Security Standardization Research 5th-6th December 2016, NIST, Gaithersburg, MD, USA http://csrc.nist.gov/groups/ST/ssr2016/ Over the last two decades a huge range of standards have been developed covering many different aspects of cyber security. These documents have been published by national and international formal standardization bodies, as well as by industry consortia. Many of these standards have become very widely used - to take just one example, the ISO/IEC 27000 series have become a commonly used basis for managing corporate information security. Despite their wide use, there will always be a need to revise existing security standards and to add new standards to cover new domains. The purpose of this conference is to discuss the many research problems deriving from studies of existing standards, the development of revisions to existing standards, and the exploration of completely new areas of standardization. Indeed, many security standards bodies are only beginning to address the issue of transparency, so that the process of selecting security techniques for standardization can be seen to be as scientific and unbiased as possible. This conference is intended to cover the full spectrum of research on security standardization, including, but not restricted to, work on cryptographic techniques (including ANSI, IEEE, IETF, ISO/IEC JTC 1/SC 27, ITU-T and NIST), security management, security evaluation criteria, network security, privacy and identity management, smart cards and RFID tags, biometrics, security modules, and industry-specific security standards (e.g. those produced by the payments, telecommunications and computing industries for such things as payment protocols, mobile telephony and trusted computing). Papers offering research contributions to the area of security standardization are solicited for submission to the SSR 2016 conference. Papers may present theory, applications or practical experience in the field of security standardization, including, but not necessarily limited to: * access control * biometrics * cloud computing * critical national infrastructure (CNI) protection * consistency and comparison of multiple standards * critiques of standards * cryptanalysis * cryptographic protocols * cryptographic techniques * evaluation criteria * formal analysis of standards * history of standardization * identity management * industrial control systems security * internet security * interoperability of standards * intrusion detection * key management and PKIs * management of the standardization process * mobile security * network security * open standards and open source * payment system security * privacy * regional and international standards * RFID tag security * risk analysis * security controls * security management * security protocols * security services * security tokens * smart cards * telecommunications security * trusted computing * web security Papers addressing the following more general topics are particularly welcome: * Do standards processes promote complexity that detracts from security? * Are there processes or approaches that can minimize complexity? * Are there technical areas in which standards are misaligned with the security models developed in research? Studies that show areas of misalignment are interesting, as is work that aims to improve alignment. * How long does it take for good ideas to propagate from research to standards to adoption and deployment? How long does it take for security problems in standards to be identified by the research community? How can we improve communication between these communities in order to expedite both of these processes? * What is the impact of nationally-driven security research on international security standards? * Are there cases in which a security standard was done well or done poorly? Studies that describe processes that should (or should not) be emulated are welcome. * Is Open Source replacing security standards development organizations, or changing the way that they operate? What are the implications on security standards? Submissions must be original and must not substantially duplicate work that any of the authors has published elsewhere or has submitted in parallel to any journal or to any other conference or workshop that has published proceedings. All accepted papers will be published in the conference proceedings, and it is intended that these proceedings will be published in the Springer-Verlag Lecture Notes in Computer Science (LNCS) series (www.springer.com/lncs), as has been the case for the two preceding conferences in the series. The proceedings will be available at the conference. Papers published in the LNCS series are indexed by both EI and ISTP. Authors of accepted papers must guarantee that their paper will be presented at the conference, and at least one author of every accepted paper must register for the conference. All submissions will be blind-reviewed. Papers must be anonymous, with no author names, affiliations, acknowledgements, or obvious references. A submitted paper should begin with a title, a short abstract, and a list of keywords. Clear instructions for the preparation of a final proceedings version will be sent to the authors of accepted papers. Authors are strongly recommended to submit their papers in the standard LNCS format (see http://www.springer.com/computer/lncs?SGWID=0-164-0-0-0 for details), with length at most 15 pages (excluding bibliography and appendices). Committee members are not required to review more pages than this, so papers should be intelligible within this length. Submissions not meeting these guidelines risk rejection without consideration of their merits. The conference will take place at the NIST headquarters in Gaithersburg, Maryland, USA. Papers must be submitted using the EasyChair conference management system at: https://easychair.org/conferences/?conf=ssr20160 Please send any enquiries to: ssr2016-0@easychair.org Key dates Deadline for submissions: Monday, 30 May 2016 (23:59 Hawaii) Notifications to authors: Monday, 8 August 2016 Camera ready due: Monday, 19 September 2016 Opening of conference: Monday, 5 December 2016 Conference organisation General Chair Lily Chen, NIST, USA Programme Committee Chair David McGrew, Cisco, USA Chris Mitchell, RHUL, UK Programme Committee: Colin Boyd, Norwegian University of Science and Technology (NTNU) Nancy Cam-Winget, Cisco Systems Liqun Chen, Hewlett Packard Labs Takeshi Chikazawa, IPA Cas Cremers, University of Oxford Scott Fluhrer, Cisco Systems Aline Gouget, Gemalto Feng Hao, Newcastle University Jens Hermans, KU Leuven - ESAT/COSIC and iMinds Dirk Kuhlmann Xuejia Lai, Shanghai Jiaotong University Pil Joong Lee, Postech Peter Lipp, Graz University of Technology Joseph Liu, Monash University Javier Lopez, University of Malaga Catherine Meadows, NRL Jinghua Min, China Electronic Cyberspace Great Wall Co., Ltd. Atsuko Miyaji Valtteri Niemi, University of Helsinki Pascal Paillier, CryptoExperts Kenneth Paterson, Royal Holloway, University of London Sihan Qing, School of Software and Microelectronics, Peking University Kai Rannenberg, Goethe University Frankfurt Matt Robshaw, Impinj Christoph Ruland, University of Siegen Mark Ryan, University of Birmingham Kazue Sako, NEC Ben Smyth, Huawei Jacques Traore, Orange Labs Claire Vishik, Intel Corporation (UK) Debby Wallner, National Security Agency Michael Ward, MasterCard William Whyte, Security Innovation Yanjiang Yang, Huawei Singapore Research Center Jianying Zhou, Institute for Infocomm Research --Apple-Mail-67--430698928 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

                        Call for Papers

 

      SSR 2016: 3rd International Conference on Security

                   Standardization Research

 

      5th-6th December 2016, NIST, Gaithersburg, MD, USA

            http://csrc.nist.gov/groups/ST/ssr2016/

 

Over the last two decades a huge range of standards have been

developed covering many different aspects of cyber security.

These documents have been published by national and

international formal standardization bodies, as well as by

industry consortia. Many of these standards have become very

widely used - to take just one example, the ISO/IEC 27000

series have become a commonly used basis for managing corporate

information security.

 

Despite their wide use, there will always be a need to revise

existing security standards and to add new standards to cover

new domains. The purpose of this conference is to discuss the

many research problems deriving from studies of existing

standards, the development of revisions to existing standards,

and the exploration of completely new areas of standardization.

Indeed, many security standards bodies are only beginning to

address the issue of transparency, so that the process of

selecting security techniques for standardization can be seen

to be as scientific and unbiased as possible.

 

This conference is intended to cover the full spectrum of

research on security standardization, including, but not

restricted to, work on cryptographic techniques (including

ANSI, IEEE, IETF, ISO/IEC JTC 1/SC 27, ITU-T and NIST),

security management, security evaluation criteria, network

security, privacy and identity management, smart cards and RFID

tags, biometrics, security modules, and industry-specific

security standards (e.g. those produced by the payments,

telecommunications and computing industries for such things as

payment protocols, mobile telephony and trusted computing).

 

Papers offering research contributions to the area of security

standardization are solicited for submission to the SSR 2016

conference. Papers may present theory, applications or

practical experience in the field of security standardization,

including, but not necessarily limited to:

* access control

* biometrics

* cloud computing

* critical national infrastructure (CNI) protection

* consistency and comparison of multiple standards

* critiques of standards

* cryptanalysis

* cryptographic protocols

* cryptographic techniques

* evaluation criteria

* formal analysis of standards

* history of standardization

* identity management

* industrial control systems security

* internet security

* interoperability of standards

* intrusion detection

* key management and PKIs

* management of the standardization process

* mobile security

* network security

* open standards and open source

* payment system security

* privacy

* regional and international standards

* RFID tag security

* risk analysis

* security controls

* security management

* security protocols

* security services

* security tokens

* smart cards

* telecommunications security

* trusted computing

* web security

 

Papers addressing the following more general topics are

particularly welcome:

* Do standards processes promote complexity that detracts from

security?

* Are there processes or approaches that can minimize complexity?

* Are there technical areas in which standards are misaligned

with the security models developed in research? Studies that

show areas of misalignment are interesting, as is work that

aims to improve alignment.

* How long does it take for good ideas to propagate from

research to standards to adoption and deployment? How long does

it take for security problems in standards to be identified by

the research community? How can we improve communication

between these communities in order to expedite both of these

processes?

* What is the impact of nationally-driven security

research on international security standards?

* Are there cases in which a security standard was done well or

done poorly? Studies that describe processes that should (or

should not) be emulated are welcome.

* Is Open Source replacing security standards development

organizations, or changing the way that they operate? What are

the implications on security standards?

 

Submissions must be original and must not substantially

duplicate work that any of the authors has published elsewhere

or has submitted in parallel to any journal or to any other

conference or workshop that has published proceedings.

 

All accepted papers will be published in the conference

proceedings, and it is intended that these proceedings will be

published in the Springer-Verlag Lecture Notes in Computer

Science (LNCS) series (www.springer.com/lncs), as has been the

case for the two preceding conferences in the series. The

proceedings will be available at the conference. Papers

published in the LNCS series are indexed by both EI and ISTP.

 

Authors of accepted papers must guarantee that their paper will

be presented at the conference, and at least one author of

every accepted paper must register for the conference.

 

All submissions will be blind-reviewed. Papers must be

anonymous, with no author names, affiliations,

acknowledgements, or obvious references. A submitted paper

should begin with a title, a short abstract, and a list of

keywords.

 

Clear instructions for the preparation of a final proceedings

version will be sent to the authors of accepted papers. Authors

are strongly recommended to submit their papers in the standard

LNCS format (see

  http://www.springer.com/computer/lncs?SGWID=0-164-0-0-0 for

details), with length at most 15 pages (excluding bibliography

and appendices). Committee members are not required to review

more pages than this, so papers should be intelligible within

this length. Submissions not meeting these guidelines risk

rejection without consideration of their merits.

 

The conference will take place at the NIST headquarters in

Gaithersburg, Maryland, USA.

 

Papers must be submitted using the EasyChair conference

management system at:

  https://easychair.org/conferences/?conf=ssr20160

Please send any enquiries to:

  ssr2016-0@easychair.org

 

 

Key dates

 

Deadline for submissions: Monday, 30 May 2016 (23:59 Hawaii)

Notifications to authors: Monday, 8 August 2016

Camera ready due:         Monday, 19 September 2016

Opening of conference:    Monday, 5 December 2016

 

 

Conference organisation

 

General Chair

  Lily Chen, NIST, USA

 

Programme Committee Chair

  David McGrew, Cisco, USA

  Chris Mitchell, RHUL, UK

 

Programme Committee:

Colin Boyd, Norwegian University of Science and Technology (NTNU)

Nancy Cam-Winget, Cisco Systems

Liqun Chen, Hewlett Packard Labs

Takeshi Chikazawa, IPA

Cas Cremers, University of Oxford

Scott Fluhrer, Cisco Systems

Aline Gouget, Gemalto

Feng Hao, Newcastle University

Jens Hermans, KU Leuven - ESAT/COSIC and iMinds

Dirk Kuhlmann

Xuejia Lai, Shanghai Jiaotong University

Pil Joong Lee, Postech

Peter Lipp, Graz University of Technology

Joseph Liu, Monash University

Javier Lopez, University of Malaga

Catherine Meadows, NRL

Jinghua Min, China Electronic Cyberspace Great Wall Co., Ltd.

Atsuko Miyaji

Valtteri Niemi, University of Helsinki

Pascal Paillier, CryptoExperts

Kenneth Paterson, Royal Holloway, University of London

Sihan Qing, School of Software and Microelectronics, Peking University

Kai Rannenberg, Goethe University Frankfurt

Matt Robshaw, Impinj

Christoph Ruland, University of Siegen

Mark Ryan, University of Birmingham

Kazue Sako, NEC

Ben Smyth, Huawei

Jacques Traore, Orange Labs

Claire Vishik, Intel Corporation (UK)

Debby Wallner, National Security Agency

Michael Ward, MasterCard

William Whyte, Security Innovation

Yanjiang Yang, Huawei Singapore Research Center

Jianying Zhou, Institute for Infocomm Research

 

--Apple-Mail-67--430698928-- From nobody Mon Feb 29 09:06:42 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5465E1B37CA for ; Mon, 29 Feb 2016 09:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 Ks2IFRe6E0V9 for ; Mon, 29 Feb 2016 09:06:39 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017391B3782 for ; Mon, 29 Feb 2016 09:06:38 -0800 (PST) X-AuditID: c1b4fb30-f79096d000002f68-41-56d47a9d2ed7 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 51.1E.12136.D9A74D65; Mon, 29 Feb 2016 18:06:37 +0100 (CET) Received: from nomadiclab.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.248.2; Mon, 29 Feb 2016 18:06:36 +0100 Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 976B84EF83; Mon, 29 Feb 2016 19:09:22 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2A6384E9B6; Mon, 29 Feb 2016 19:09:22 +0200 (EET) To: , "tuomas.aura@aalto.fi" References: <56C71D30.10506@cs.helsinki.fi> From: Mohit Sethi Message-ID: <56D47A9C.8030602@ericsson.com> Date: Mon, 29 Feb 2016 19:06:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56C71D30.10506@cs.helsinki.fi> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030600000106010301050404" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM2K7h+7cqithBhu+8VtM6e9ksngzcSO7 A5PH8deLWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXRsfcra8E954o/Uz6xNDCet+ti5OCQEDCR WHimoouRE8gUk7hwbz1bFyMXh5DAYUaJrW1HoZxtjBJLtjxkgXDWMkps/HaOCcKZxyjRseou O0i/sICZxJ7Ju5hAbBEBJ4mrj+YwgawQEtCWmPe6CCTMJqAn0XnuODOIzQsUPjbrKytICYuA qsTGTYEgYVGBCInDnV3sECWCEidnPmEBKeEU0JFYdDgSZCuzQDejRPfOmWwQV6tJXD23CWyk kIC6xNaOA4wTGIVmIWmfhawHJMEsYCtxZ+5uZghbW2LZwtdQtrXEjF8HoWoUJaZ0P2SHsE0l Xh/9yAhhG0ssW/eXbQEjxypG0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2MwAg6uOW3wQ7Gl88d DzEKcDAq8fBucL4cJsSaWFZcmXuIUQVozqMNqy8wSrHk5eelKonwrvO8EibEm5JYWZValB9f VJqTWnyIUZqDRUmcl/UTUKdAemJJanZqakFqEUyWiYNTqoGxYdevFJMXbqvU3Obq3XDd9PyC wyWeGb9Ws07uDBG917/0wa6Mc91a+7sFt+eu3lL7fYN5Ss/K/m9sNdn8CjOnSp3RLzpzyjTY efmlprDIr10Gems/7ZIzkFkvlOgqpcFjsSdQtzfda3kh7/q3yzkq0sXk2B3D1i6a9vGSSmJn wtXzYYHPzssosRRnJBpqMRcVJwIAOO/8+qgCAAA= Archived-At: Subject: Re: [saag] feedback on draft-aura-eap-noob-00 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 17:06:41 -0000 --------------ms030600000106010301050404 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Andrei Thank you for your feedback. I read the paper that suggests spraying the messages over multiple paths = between the sender an receiver in a MANET. However, the scheme presented = there relies on the special network topology and the assumption that=20 there are several independent paths between the sender and the receiver. = However, in typical 802.1x port-based authentication scenario, there is=20 only one path between the peer and server. Therefore we require the OOB=20 step. While a puzzle mechanism might be suitable in some scenarios, battery=20 operated IoT devices are at a disadvantage compared to the potential=20 attacker in solving computational puzzles. However, we will add a=20 section on DoS attack considerations in the next revision. /--Mohit On 02/19/2016 03:48 PM, Andrei Gurtov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I read the new draft draft-aura-eap-noob-00.txt and just want to > provide some comments on it. > > I think the draft is quite useful as it provides an opportunity to > enroll new devices to network which has only limited communication > capabilities (e.g. a public display). > > The draft is very readable and almost complete, i didn't find any > typos or obvious omissions in it. The NOOB name is kind of funny, but > I guess authors chose it intentionally. > > About the protocol, I'm wondering if explicit OOB authentication is > needed if during DH it's possible to transmit one of the messages on > the other channel or spread the messages using coding over multiple > channels. See e.g. > http://link.springer.com/chapter/10.1007%2F978-3-642-41717-7_24 > > In Security claims sec 5.4 there is no mentioning of DoS attacks. Is > the protocol vulnerable to those? Is there a need to employ a puzzle > mechanism, for example? > > BR > Andrei > - --=20 > Andrei Gurtov, PhD, ACM Distinguished Scientist > IEEE ComSoc Distinguished Lecturer & Vice-chair, IEEE Finland > Principal Scientist, Helsinki Institute for Information Technology HIIT= > Adjunct Professor Aalto University, University of Oulu and University > of Helsinki > http://www.hiit.fi/~gurtov > https://www.researchgate.net/profile/Andrei_Gurtov > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iEYEARECAAYFAlbHHTAACgkQP7jp0uceFkSdfQCdFiX5EvvpmgDRA1x4qn6h3fxm > KXIAoI+uCh5km2sqAFe+D7ovCg06Uez2 > =3DrOEB > -----END PGP SIGNATURE----- > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --------------ms030600000106010301050404 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKwwggXuMIID1qADAgECAhAQR5JVnNLKtD1FopLU12S6MA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTEwNjA3MzMxNFoXDTE3MTEwNjA3MzMxM1owaDERMA8GA1UECgwIRXJpY3Nzb24x FjAUBgNVBAMMDU1vaGl0IFNldGhpIE0xKTAnBgkqhkiG9w0BCQEWGm1vaGl0Lm0uc2V0aGlA ZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlc2V0bW9oMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAvSfTetNQu8RTOPssYplNRFzoIht/yijWoVTkmFBi71zeZer1H0YVv7MdMeeH 7FAPhlJ8tz5l+ovh5Osu8JX+hpJYG4pvr6yI/wMMIiA4XnyD1Bw4N1X20hy23mUTzuDhBl65 HF2iOAcD2hjCQM9ObVY4A6R1Ckn6TdEzmRQ/68vzrGIY41iffIvmlT2GYvqoQIzGwdBHW78b Es3sulc1tC+inyqhqSobXcdh/mtBbg1sHlwFwlOhu7Bpa+W1hqJuZcix5HMV7D4Cg3QJ6WJ/ SOjdtnvnHM88dCFKZWftoSizUcp5MY9CMUReid0YxNi9Q016ECumbzB4rFC/8lgGjQIDAQAB o4IBwDCCAbwwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20v ZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUF BzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8v Y2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIw JQYDVR0RBB4wHIEabW9oaXQubS5zZXRoaUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwr BgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1Ud DgQWBBTiYWRwmLJKozqivzho0MUE4onqjjAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52 cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBADx5ydquiV9FvleFR/s2 8/QwBlbi6WoY4WZd5oymC2MH3iAyneZkbBlcUAWNG1XlNsYRkAYv4JR8+1TrbpeWH/D/pSwW ArWsUp41nOW9PEfZCA4oRvso9e0UWtc5bhJuEdE3Y42FJfZJcJXsUN8APuX50lcAMoqgZKqm XcAk/RsTjQp0+r63ibD5hU/EeJXpNjIoEo5NRuzHDdWFYdLAL5JjLa6RD6mp3MuuPqDw0q0h BxBrvDdxf9Ev6TPFfKhVdCOgAVVJ6B+4ky7YqVhOylT8n2v2Y2b0WhpHOTXXr1q0aMAYKI+R X1NReXfS0opDMC0Yi/y0G2s3d5zbEBtKuwukbF1nQWZpCJbwFa4So8V+f5se4PdxU/0eLfE3 bKUOpfjwdyjPoVcrs0lsJe+FNNgfPDlj39AZuNEax/DX7Nq/F6YrYrwaF5EgSLMIzfn9lPtY Cd4AmJzLjr8D4XzZGt2f/EWGZwRGR/Yn9q6oWCa+G48tkTEow1FBXD4lPtbKb+GoKK7Ziidi /hMteorcOC/S61DCOGhINSe8r+9sgpOUM5smVEL7U2/0P1uZwqSvPSLpaG+44ZTwbkGfsSMu R4U2aBkEaK9RhcM954VtbWFRT9G7NXmQw3HhoMMyGs1U9D293wwq1GD0jV1ibQH/z74bVW+G GCeXO00w3rFcVl60MIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcN AQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJv b3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJ KoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5I EyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uw ojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiI EeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgA mInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zAN henIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI 4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYA SC+NV8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZ OskPEwtaIHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1 rTqTGIBIe9wjNnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMB AAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50 cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRy dXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8E CDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0 dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIw QKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFy b290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQE AwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz 9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2 dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A 1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl 6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEA OLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+k XDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpK B0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk 9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAY HZi7RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+ qE/h2DZAJwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF 4PBTVMZtMYIDFDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJp Y3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQEEeSVZzSyrQ9RaKS1NdkujANBglghkgBZQME AgEFAKCCAZcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYw MjI5MTcwNjM2WjAvBgkqhkiG9w0BCQQxIgQgkKrHvmOdU/x0vUfpj/6sVryjpMJ7eTwqnoJX gzFXOp4wXQYJKwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQEEeSVZzSyrQ9RaKS1NdkujBfBgsqhkiG 9w0BCRACCzFQoE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EgdjICEBBHklWc0sq0PUWiktTXZLowbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASC AQAsLvMfpaoYYI6GTxSwAGFGVDscHaZnwGLYl0fhMHhGzMYWdQs2AjX17YoXESDb6Zvdv5SD kT3Fn77IPh3nfdJIMVh7d8/KFt0GXerMlpw36AEXUiONa9rHoGKzdHMM8ew/Z2KHcGQ87ZTJ t/D2OB0TcwICdyG9NUl1rrNiu+xh3O8F6j/Y2XYiWbIcAh9mU1yGib683TyXxH9RnrP2teFR p/JT7aKBxThCGAoyq1PGzr2jTnf8+dk5MxxenNWkwBwnq/sZK685BJDGFFzishCzqX/VqRon NxXXzz9+jsj551EaSjx/Ow5yRc2l4Ya/wEtwBc/MJ4Xm78GzGV7bTA0cAAAAAAAA --------------ms030600000106010301050404-- From nobody Mon Feb 29 09:08:38 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8A51B37D6; Mon, 29 Feb 2016 09:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 aBVTvtg3dv0k; Mon, 29 Feb 2016 09:08:32 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88D461B37D4; Mon, 29 Feb 2016 09:08:31 -0800 (PST) X-AuditID: c1b4fb2d-f79836d000006396-aa-56d47b0d63f6 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id AD.3D.25494.D0B74D65; Mon, 29 Feb 2016 18:08:29 +0100 (CET) Received: from nomadiclab.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.248.2; Mon, 29 Feb 2016 18:08:29 +0100 Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 46FB94EF83; Mon, 29 Feb 2016 19:11:15 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B3BF14E9B6; Mon, 29 Feb 2016 19:11:14 +0200 (EET) To: Stefan Winter , , , "tuomas.aura@aalto.fi" References: <20160208123035.1562.80507.idtracker@ietfa.amsl.com> <56B8B561.8040300@ericsson.com> <7F9C975440487E49BBD35F4FB088ED74CFCDBF14@EXMDB01.org.aalto.fi> <56C6C4C4.6070201@restena.lu> From: Mohit Sethi Message-ID: <56D47B0D.5040000@ericsson.com> Date: Mon, 29 Feb 2016 19:08:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56C6C4C4.6070201@restena.lu> Content-Type: multipart/alternative; boundary="------------060400090900010701070409" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyM2K7pS5v9ZUwg/ZtehbH1q9lsZjS38lk Ma+hkd3izcSN7A4sHsdfL2b1WLLkJ5PH8i6fAOYoLpuU1JzMstQifbsEroz9598wF7yprTjw w72B8WBGFyMnh4SAicTH9ZuZIWwxiQv31rOB2EIChxklXs9V6WLkArK3MUocX7SGBcJZyyjx ckMjE4Qzj1Hi5+ImFpAWYYEIidb358BGiQjUSdz5NBmqYzqTxLaHp8HmsgnoSXSeOw5UxMHB K6At0bhREiTMIqAq8Xz/RbBeUaA5hzu72EFsXgFBiZMzn4DN5xTQkjizZA4TiM0sECbxumse G8TZahJXz21ihjhbXWJrxwHGCYxCs5C0z0LSMgtoM7OAvcSDrWUQYXmJ5q2zmSFsfYnrd+6z IosvYGRbxShanFpcnJtuZKyXWpSZXFycn6eXl1qyiREYKwe3/Nbdwbj6teMhRgEORiUe3g3O l8OEWBPLiitzDzFKcDArifCu87wSJsSbklhZlVqUH19UmpNafIhRmoNFSZyX7RNQtUB6Yklq dmpqQWoRTJaJg1OqgVEuQ+nuauWT7yYbXBZianDuexu/m/0Bm97Sv6aT3j+YbirvJ2mxuuNn iXjJ3i7uiNNih7iqAph/KppW3ItiF61Q6FibMqej3K0o2+j4TPX2i7nevT+zCxbHMZocTFY3 WTL7Q3DjnG2ykYu4fA6E/FDyu3v/T9lhxSWXbDrmCmb/PJ4dYrmNSYmlOCPRUIu5qDgRAPhT gSeRAgAA Archived-At: Subject: Re: [saag] [Emu] Fwd: New Version Notification for draft-aura-eap-noob-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 17:08:35 -0000 --------------060400090900010701070409 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Hi Stefan It is hard to have an exact number on how many "home" access points / integrated all-layer-devices do or do not support 802.1X. In many cases, support can be added to the APs with a software update if there is demand. We believe that given the benefits of this solution and the added security, the deployment of such NAS would increase in general. /--Mohit PS: Let's keep the future discussion for this draft on the SAAG mailing list for now. On 02/19/2016 09:31 AM, Stefan Winter wrote: > Hi, > >> Of course, the benefits of EAP-NOOB will be greater in organizations which already use 802.1X authentication and which have larger numbers of IoT devices than a single home. > Particularly because many "home" access points / integrated > all-layer-devices do not support 802.1X so do not qualify as a NAS. > > Which is unfortunate and yes it would be great to have 802.1X NASes > everywhere. :-) But for your scenario, it's a significant limitation if > you exclude a large percentage of homes. > > (I don't dare make up any real percentage numbers; I'm sure this varies > a lot per country and per operator) > > Greetings, > > Stefan Winter > > >> Anything else that we need to address? >> >> Tuomas >> >> >> >> -----Original Message----- >> From: Josh Howlett [mailto:Josh.Howlett@jisc.ac.uk] >> Sent: Thursday, 18 February, 2016 19:28 >> To: Mohit Sethi ; saag@ietf.org; emu@ietf.org >> Cc: Aura Tuomas >> Subject: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt >> >> Hi Mohit, >> >> This is an interesting draft, but I'm struggling to understand how this would be deployed in the consumer settings that the document alludes to. For example, who do you anticipate will be operating the NAS (the consumer?), AAA server (the vendor?), and the AAA fabric between these actors? >> >> Josh. >> >>> -----Original Message----- >>> From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Mohit Sethi >>> Sent: 08 February 2016 15:34 >>> To: saag@ietf.org; emu@ietf.org >>> Cc: tuomas.aura@aalto.fi >>> Subject: [saag] Fwd: New Version Notification for >>> draft-aura-eap-noob-00.txt >>> >>> Dear all >>> >>> We have just submitted a new IETF Draft titled “Nimble out-of-band >>> authentication for EAP (EAP-NOOB)”. >>> >>> The draft defines an EAP method where the authentication is based on a >>> user-assisted out-of-band (OOB) channel between the server and peer. >>> It is intended as a generic bootstrapping solution for >>> Internet-of-Things devices which have no pre-configured authentication >>> credentials and which are not yet registered on the authentication >>> server. Consider devices you just bought or borrowed. >>> >>> The EAP-NOOB method is more generic than most ad-hoc bootstrapping >>> solutions in that it supports many types of OOB channels. We specify >>> the exact in-band messages but only the OOB message contents and not >>> the OOB channel details. Also, EAP-NOOB supports ubicomp devices with >>> only output (e.g. display) or only input (e.g. camera). Moreover, it >>> makes combined use of both secrecy and integrity of the OOB channel >>> for more robust security than the ad-hoc solutions. We have put a lot >>> of effort into designing a robust security protocol. >>> >>> For one application example, we have used an earlier version of the >>> protocol for bootstrapping security for ubiquitous displays: the user >>> can configure wireless network access, link the device to a cloud >>> service, and register ownership of the device for a specific cloud >>> user – all in one simple step of scanning a QR code with a smart >>> phone. There seemed to more potential to this idea than just using it >>> for our own system, and thus we decided to write a generic EAP method for out-of-band authentication. >>> >>> The draft is available here: >>> https://tools.ietf.org/html/draft-aura-eap-noob-00 >>> >>> Please see if you can make use of it. We look forward to your feedback >>> and comments. >>> >>> Regards >>> /--Mohit >>> >>> >>> -------- Forwarded Message -------- >>> Subject: New Version Notification for draft-aura-eap-noob-00.txt >>> Date: Mon, 08 Feb 2016 04:30:35 -0800 >>> From: internet-drafts@ietf.org >>> To: Tuomas Aura , Mohit Sethi >>> >>> >>> >>> >>> A new version of I-D, draft-aura-eap-noob-00.txt has been successfully >>> submitted by Tuomas Aura and posted to the IETF repository. >>> >>> Name: draft-aura-eap-noob >>> Revision: 00 >>> Title: Nimble out-of-band authentication for EAP (EAP-NOOB) >>> Document date: 2016-02-08 >>> Group: Individual Submission >>> Pages: 35 >>> URL:https://www.ietf.org/internet-drafts/draft-aura-eap-noob-00.txt >>> Status:https://datatracker.ietf.org/doc/draft-aura-eap-noob/ >>> Htmlized:https://tools.ietf.org/html/draft-aura-eap-noob-00 >>> >>> >>> Abstract: >>> Extensible Authentication Protocol (EAP) [RFC3748] provides support >>> for multiple authentication methods. This document defines the EAP- >>> NOOB authentication method for nimble out-of-band (OOB) >>> authentication and key derivation. This EAP method is intended for >>> bootstrapping all kinds of Internet-of-Things (IoT) devices that have >>> a minimal user interface and no pre-configured authentication >>> credentials. The method makes use of a user-assisted one-directional >>> OOB channel between the peer device and authentication server. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> >>> >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://www.ietf.org/mailman/listinfo/saag >> Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. >> >> Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800. >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu >> > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu --------------060400090900010701070409 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Hi Stefan

It is hard to have an exact number on how many "home" access points / integrated all-layer-devices do or do not support 802.1X. In many cases, support can be added to the APs with a software update if there is demand. We believe that given the benefits of this solution and the added security, the deployment of such NAS would increase in general.

/--Mohit

PS: Let's keep the future discussion for this draft on the SAAG mailing list for now.

On 02/19/2016 09:31 AM, Stefan Winter wrote:
Hi,


Of course, the benefits of EAP-NOOB will be greater in organizations which already use 802.1X authentication and which have larger numbers of IoT devices than a single home. 

Particularly because many "home" access points / integrated
all-layer-devices do not support 802.1X so do not qualify as a NAS.

Which is unfortunate and yes it would be great to have 802.1X NASes
everywhere. :-) But for your scenario, it's a significant limitation if
you exclude a large percentage of homes.

(I don't dare make up any real percentage numbers; I'm sure this varies
a lot per country and per operator)

Greetings,

Stefan Winter



Anything else that we need to address?

Tuomas



-----Original Message-----
From: Josh Howlett [mailto:Josh.Howlett@jisc.ac.uk] 
Sent: Thursday, 18 February, 2016 19:28
To: Mohit Sethi <mohit.m.sethi@ericsson.com>; saag@ietf.org; emu@ietf.org
Cc: Aura Tuomas <tuomas.aura@aalto.fi>
Subject: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt

Hi Mohit,

This is an interesting draft, but I'm struggling to understand how this would be deployed in the consumer settings that the document alludes to. For example, who do you anticipate will be operating the NAS (the consumer?), AAA server (the vendor?), and the AAA fabric between these actors?

Josh.


-----Original Message-----
From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Mohit Sethi
Sent: 08 February 2016 15:34
To: saag@ietf.org; emu@ietf.org
Cc: tuomas.aura@aalto.fi
Subject: [saag] Fwd: New Version Notification for 
draft-aura-eap-noob-00.txt

Dear all

We have just submitted a new IETF Draft titled “Nimble out-of-band 
authentication for EAP (EAP-NOOB)”.

The draft defines an EAP method where the authentication is based on a 
user-assisted out-of-band (OOB) channel between the server and peer. 
It is intended as a generic bootstrapping solution for 
Internet-of-Things devices which have no pre-configured authentication 
credentials and which are not yet registered on the authentication 
server. Consider devices you just bought or borrowed.

The EAP-NOOB method is more generic than most ad-hoc bootstrapping 
solutions in that it supports many types of OOB channels. We specify 
the exact in-band messages but only the OOB message contents and not 
the OOB channel details. Also, EAP-NOOB supports ubicomp devices with 
only output (e.g. display) or only input (e.g. camera). Moreover, it 
makes combined use of both secrecy and integrity of the OOB channel 
for more robust security than the ad-hoc solutions. We have put a lot 
of effort into designing a robust security protocol.

For one application example, we have used an earlier version of the 
protocol for bootstrapping security for ubiquitous displays: the user 
can configure wireless network access, link the device to a cloud 
service, and register ownership of the device for a specific cloud 
user – all in one simple step of scanning a QR code with a smart 
phone. There seemed to more potential to this idea than just using it 
for our own system, and thus we decided to write a generic EAP method for out-of-band authentication.

The draft is available here:
https://tools.ietf.org/html/draft-aura-eap-noob-00

Please see if you can make use of it. We look forward to your feedback 
and comments.

Regards
/--Mohit


-------- Forwarded Message --------
Subject: 	New Version Notification for draft-aura-eap-noob-00.txt
Date: 	Mon, 08 Feb 2016 04:30:35 -0800
From: 	internet-drafts@ietf.org
To: 	Tuomas Aura <tuomas.aura@aalto.fi>, Mohit Sethi
<mohit@piuha.net>



A new version of I-D, draft-aura-eap-noob-00.txt has been successfully 
submitted by Tuomas Aura and posted to the IETF repository.

Name:		draft-aura-eap-noob
Revision:	00
Title:		Nimble out-of-band authentication for EAP (EAP-NOOB)
Document date:	2016-02-08
Group:		Individual Submission
Pages:		35
URL:https://www.ietf.org/internet-drafts/draft-aura-eap-noob-00.txt
Status:https://datatracker.ietf.org/doc/draft-aura-eap-noob/
Htmlized:https://tools.ietf.org/html/draft-aura-eap-noob-00


Abstract:
    Extensible Authentication Protocol (EAP) [RFC3748] provides support
    for multiple authentication methods.  This document defines the EAP-
    NOOB authentication method for nimble out-of-band (OOB)
    authentication and key derivation.  This EAP method is intended for
    bootstrapping all kinds of Internet-of-Things (IoT) devices that have
    a minimal user interface and no pre-configured authentication
    credentials.  The method makes use of a user-assisted one-directional
    OOB channel between the peer device and authentication server.




Please note that it may take a couple of minutes from the time of 
submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.

Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.  
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu






_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

--------------060400090900010701070409-- From nobody Mon Feb 29 09:10:26 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34CA31B37D9 for ; Mon, 29 Feb 2016 09:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 BnSOOdxxUne5 for ; Mon, 29 Feb 2016 09:10:20 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9101D1B37D4 for ; Mon, 29 Feb 2016 09:10:19 -0800 (PST) X-AuditID: c1b4fb2d-f79836d000006396-c1-56d47b790004 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E0.7D.25494.97B74D65; Mon, 29 Feb 2016 18:10:17 +0100 (CET) Received: from nomadiclab.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.248.2; Mon, 29 Feb 2016 18:10:16 +0100 Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 358814EF83; Mon, 29 Feb 2016 19:13:03 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9CB074E9B6; Mon, 29 Feb 2016 19:13:02 +0200 (EET) To: Josh Howlett , Aura Tuomas , Mohit Sethi , "saag@ietf.org" References: <20160208123035.1562.80507.idtracker@ietfa.amsl.com> <56B8B561.8040300@ericsson.com> <7F9C975440487E49BBD35F4FB088ED74CFCDBF14@EXMDB01.org.aalto.fi> From: Mohit Sethi Message-ID: <56D47B79.7010306@ericsson.com> Date: Mon, 29 Feb 2016 19:10:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000209030701050106030507" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGbHdTLey+kqYwfl1ZhbXbj5it5jS38lk 8WbiRnYHZo/jrxezeixZ8pPJY+XvK2wBzFFcNimpOZllqUX6dglcGZfvPmUpuPGcsWLB9gPs DYy3lzN2MXJySAiYSFzc0sQKYYtJXLi3nq2LkYtDSOAwo8SONe+YIZxtjBLzznezQDhrGSW+ f1rECOHMY5S4+XEJC0i/sECQxOR1E8ASIgJzGSUev7zJDlE1l1liZ/NBsI1sAnoSneeOM4PY vALaEqduPgazWQRUJV417QObJCoQIXG4s4sdokZQ4uTMJ2BxToFYidU7DoLZzAJhEjvfbGOC uFxN4uq5TWBzhATUJbZ2HGCcwCg0C0n7LCQtsxg5gGx7iQdbyyDC8hLNW2czQ9j6Etfv3GdF Fl/AyLaKUbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQTIzBeDm75rbuDcfVrx0OMAhyMSjy8G5wv hwmxJpYVV+YeYpTgYFYS4e2vuhImxJuSWFmVWpQfX1Sak1p8iFGag0VJnJftE1C1QHpiSWp2 ampBahFMlomDU6qBUT4m1ud72t9JZ2and1wW3LzMwMiEjUvcIn9tt2HWqfBEx8Tsvu2bQq10 bt9T/8fu+StubZ3tt7wr+reiAu3jFY3fB2XHXOJ8ltVwW02rldlH8euR+0zWOos3GoUd32H2 2yp3+7FvV9pX7pbjsNkmoDO/a1ZdwvX3kzNc0p8uZWDeMOlse+o0JZbijERDLeai4kQA4a4u 8pMCAAA= Archived-At: Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 17:10:24 -0000 --------------000209030701050106030507 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Hi Josh Thanks again for your useful questions. 1. The requests for "eap-noob.net" would either be served by a local AAA server or a remote AAA server for which a forwarding rule has been added. The request would not be forwarded to a global server based on DNS lookups. Hence, a DNS lookup for eap-noob.net is expected to respond with NXDOMAIN. 2. The need for the special purpose realm is to allow devices from any manufacturer to be directed to the AAA server of your choice. You only need setup the server or add the forwarding once for all the devices from any manufacturer. Not everyone wants to depend on the device vendor's AAA service for security.Besides, depending on a vendor service may not be always safe. As Stephen had pointed out in another mail thread (https://www.ietf.org/mail-archive/web/ace/current/msg01470.html), commercial devices will be end-of-lifed by vendors, and yet they still need to be functional for the owner. /--Mohit On 02/18/2016 09:05 PM, Josh Howlett wrote: > > Sorry, ignore question 3, it makes no sense here. > > *From: *Josh Howlett > *Sent: *18 February 2016 18:47 > *To: *Aura Tuomas ; Mohit Sethi > ; saag@ietf.org > ; emu@ietf.org > *Subject: *Re: [saag] Fwd: New Version Notification for > draft-aura-eap-noob-00.txt > > Hi Aura, > > A couple of other questions on the deployment theme: > > 1.How would requests towards the single special people realm get > disambiguated among the multiple AAA servers? > > 2.In fact, what’s the need for this special purpose realm at all – why > not let the vendor burn one into the firmware, and use an intermediate > AAA routing fabric do the AAA server discovery? > > 3.Why this and not WPS (or something similar?) > > Josh. > > Sent from Outlook Mail > for Windows 10 phone > > *From: *Aura Tuomas > *Sent: *18 February 2016 18:07 > *To: *Josh Howlett ; Mohit Sethi > ; saag@ietf.org > ; emu@ietf.org > *Subject: *RE: [saag] Fwd: New Version Notification for > draft-aura-eap-noob-00.txt > > Hi Josh, > > Good observation; we may need to be clearer about the intended usage > scenarios for EAP-NOOB. > > In the home setting, the AAA server would typically be a cloud-based > service, where the consumer can register a user account. This does > require the 802.1X authentication (i.e. WPA2-Enterprise) to be > configured at the home NAS, so that authentication for "@eap-noob.net" > is forwarded to the cloud-based AAA server. You only need to configure > the NAS once, and all future devices can be connected without touching > the NAS. > > This is a change from the way home wireless routers are configured > today. We think that, as the number of IoT devices grows, configuring > them with a shared passphrase will be too inconvenient. Obviously, the > shared passphrase is also vulnerable to a single untrusted IoT device > that may leak the passphrase, and using EAP helps to isolate the devices. > > Of course, the benefits of EAP-NOOB will be greater in organizations > which already use 802.1X authentication and which have larger numbers > of IoT devices than a single home. > > Anything else that we need to address? > > Tuomas > > > > -----Original Message----- > From: Josh Howlett [mailto:Josh.Howlett@jisc.ac.uk] > Sent: Thursday, 18 February, 2016 19:28 > To: Mohit Sethi ; saag@ietf.org; emu@ietf.org > Cc: Aura Tuomas > Subject: RE: [saag] Fwd: New Version Notification for > draft-aura-eap-noob-00.txt > > Hi Mohit, > > This is an interesting draft, but I'm struggling to understand how > this would be deployed in the consumer settings that the document > alludes to. For example, who do you anticipate will be operating the > NAS (the consumer?), AAA server (the vendor?), and the AAA fabric > between these actors? > > Josh. > > > -----Original Message----- > > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Mohit Sethi > > Sent: 08 February 2016 15:34 > > To: saag@ietf.org; emu@ietf.org > > Cc: tuomas.aura@aalto.fi > > Subject: [saag] Fwd: New Version Notification for > > draft-aura-eap-noob-00.txt > > > > Dear all > > > > We have just submitted a new IETF Draft titled “Nimble out-of-band > > authentication for EAP (EAP-NOOB)”. > > > > The draft defines an EAP method where the authentication is based on a > > user-assisted out-of-band (OOB) channel between the server and peer. > > It is intended as a generic bootstrapping solution for > > Internet-of-Things devices which have no pre-configured authentication > > credentials and which are not yet registered on the authentication > > server. Consider devices you just bought or borrowed. > > > > The EAP-NOOB method is more generic than most ad-hoc bootstrapping > > solutions in that it supports many types of OOB channels. We specify > > the exact in-band messages but only the OOB message contents and not > > the OOB channel details. Also, EAP-NOOB supports ubicomp devices with > > only output (e.g. display) or only input (e.g. camera). Moreover, it > > makes combined use of both secrecy and integrity of the OOB channel > > for more robust security than the ad-hoc solutions. We have put a lot > > of effort into designing a robust security protocol. > > > > For one application example, we have used an earlier version of the > > protocol for bootstrapping security for ubiquitous displays: the user > > can configure wireless network access, link the device to a cloud > > service, and register ownership of the device for a specific cloud > > user – all in one simple step of scanning a QR code with a smart > > phone. There seemed to more potential to this idea than just using it > > for our own system, and thus we decided to write a generic EAP > method for out-of-band authentication. > > > > The draft is available here: > > https://tools.ietf.org/html/draft-aura-eap-noob-00 > > > > Please see if you can make use of it. We look forward to your feedback > > and comments. > > > > Regards > > /--Mohit > > > > > > -------- Forwarded Message -------- > > Subject: New Version Notification for draft-aura-eap-noob-00.txt > > Date: Mon, 08 Feb 2016 04:30:35 -0800 > > From: internet-drafts@ietf.org > > To: Tuomas Aura , Mohit Sethi > > > > > > > > > > A new version of I-D, draft-aura-eap-noob-00.txt has been successfully > > submitted by Tuomas Aura and posted to the IETF repository. > > > > Name: draft-aura-eap-noob > > Revision: 00 > > Title: Nimble out-of-band authentication for EAP > (EAP-NOOB) > > Document date: 2016-02-08 > > Group: Individual Submission > > Pages: 35 > > URL:https://www.ietf.org/internet-drafts/draft-aura-eap-noob-00.txt > > Status:https://datatracker.ietf.org/doc/draft-aura-eap-noob/ > > Htmlized:https://tools.ietf.org/html/draft-aura-eap-noob-00 > > > > > > Abstract: > > Extensible Authentication Protocol (EAP) [RFC3748] provides support > > for multiple authentication methods. This document defines the EAP- > > NOOB authentication method for nimble out-of-band (OOB) > > authentication and key derivation. This EAP method is intended for > > bootstrapping all kinds of Internet-of-Things (IoT) devices that > have > > a minimal user interface and no pre-configured authentication > > credentials. The method makes use of a user-assisted > one-directional > > OOB channel between the peer device and authentication server. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > The IETF Secretariat > > > > > > > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag > > Jisc is a registered charity (number 1149740) and a company limited by > guarantee which is registered in England under Company No. 5747339, > VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, > Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. > > Jisc Services Limited is a wholly owned Jisc subsidiary and a company > limited by guarantee which is registered in England under company > number 2881024, VAT number GB 197 0632 86. The registered office is: > One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800. > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --------------000209030701050106030507 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Hi Josh

Thanks again for your useful questions.

1. The requests for "eap-noob.net" would either be served by a local AAA server or a remote AAA server for which a forwarding rule has been added. The request would not be forwarded to a global server based on DNS lookups. Hence, a DNS lookup for eap-noob.net is expected to respond with NXDOMAIN.

2. The need for the special purpose realm is to allow devices from any manufacturer to be directed to the AAA server of your choice. You only need setup the server or add the forwarding once for all the devices from any manufacturer. Not everyone wants to depend on the device vendor's AAA service for security.Besides, depending on a vendor service may not be always safe. As Stephen had pointed out in another mail thread (https://www.ietf.org/mail-archive/web/ace/current/msg01470.html), commercial devices will be end-of-lifed by vendors, and yet they still need to be functional for the owner.

/--Mohit

On 02/18/2016 09:05 PM, Josh Howlett wrote:

Sorry, ignore question 3, it makes no sense here.

 

From: Josh Howlett
Sent: 18 February 2016 18:47
To: Aura Tuomas; Mohit Sethi; saag@ietf.org; emu@ietf.org
Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt

 

Hi Aura,

 

A couple of other questions on the deployment theme:

 

1.       How would requests towards the single special people realm get disambiguated among the multiple AAA servers?

2.       In fact, what’s the need for this special purpose realm at all – why not let the vendor burn one into the firmware, and use an intermediate AAA routing fabric do the AAA server discovery?

3.       Why this and not WPS (or something similar?)

 

Josh.

 

 

 

Sent from Outlook Mail for Windows 10 phone

 

From: Aura Tuomas
Sent: 18 February 2016 18:07
To: Josh Howlett; Mohit Sethi; saag@ietf.org; emu@ietf.org
Subject: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt

 

Hi Josh,

Good observation; we may need to be clearer about the intended usage scenarios for EAP-NOOB.

In the home setting, the AAA server would typically be a cloud-based service, where the consumer can register a user account. This does require the 802.1X authentication (i.e. WPA2-Enterprise) to be configured at the home NAS, so that authentication for "@eap-noob.net" is forwarded to the cloud-based AAA server. You only need to configure the NAS once, and all future devices can be connected without touching the NAS.

This is a change from the way home wireless routers are configured today. We think that, as the number of IoT devices grows, configuring them with a shared passphrase will be too inconvenient. Obviously, the shared passphrase is also vulnerable to a single untrusted IoT device that may leak the passphrase, and using EAP helps to isolate the devices.

Of course, the benefits of EAP-NOOB will be greater in organizations which already use 802.1X authentication and which have larger numbers of IoT devices than a single home.

Anything else that we need to address?

Tuomas



-----Original Message-----
From: Josh Howlett [mailto:Josh.Howlett@jisc.ac.uk]
Sent: Thursday, 18 February, 2016 19:28
To: Mohit Sethi <mohit.m.sethi@ericsson.com>; saag@ietf.org; emu@ietf.org
Cc: Aura Tuomas <tuomas.aura@aalto.fi>
Subject: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt

Hi Mohit,

This is an interesting draft, but I'm struggling to understand how this would be deployed in the consumer settings that the document alludes to. For example, who do you anticipate will be operating the NAS (the consumer?), AAA server (the vendor?), and the AAA fabric between these actors?

Josh.

> -----Original Message-----
> From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Mohit Sethi
> Sent: 08 February 2016 15:34
> To: saag@ietf.org; emu@ietf.org
> Cc: tuomas.aura@aalto.fi
> Subject: [saag] Fwd: New Version Notification for
> draft-aura-eap-noob-00.txt
>
> Dear all
>
> We have just submitted a new IETF Draft titled “Nimble out-of-band
> authentication for EAP (EAP-NOOB)”.
>
> The draft defines an EAP method where the authentication is based on a
> user-assisted out-of-band (OOB) channel between the server and peer.
> It is intended as a generic bootstrapping solution for
> Internet-of-Things devices which have no pre-configured authentication
> credentials and which are not yet registered on the authentication
> server. Consider devices you just bought or borrowed.
>
> The EAP-NOOB method is more generic than most ad-hoc bootstrapping
> solutions in that it supports many types of OOB channels. We specify
> the exact in-band messages but only the OOB message contents and not
> the OOB channel details. Also, EAP-NOOB supports ubicomp devices with
> only output (e.g. display) or only input (e.g. camera). Moreover, it
> makes combined use of both secrecy and integrity of the OOB channel
> for more robust security than the ad-hoc solutions. We have put a lot
> of effort into designing a robust security protocol.
>
> For one application example, we have used an earlier version of the
> protocol for bootstrapping security for ubiquitous displays: the user
> can configure wireless network access, link the device to a cloud
> service, and register ownership of the device for a specific cloud
> user – all in one simple step of scanning a QR code with a smart
> phone. There seemed to more potential to this idea than just using it
> for our own system, and thus we decided to write a generic EAP method for out-of-band authentication.
>
> The draft is available here:
> https://tools.ietf.org/html/draft-aura-eap-noob-00
>
> Please see if you can make use of it. We look forward to your feedback
> and comments.
>
> Regards
> /--Mohit
>
>
> -------- Forwarded Message --------
> Subject:       New Version Notification for draft-aura-eap-noob-00.txt
> Date:  Mon, 08 Feb 2016 04:30:35 -0800
> From:  internet-drafts@ietf.org
> To:    Tuomas Aura <tuomas.aura@aalto.fi>, Mohit Sethi
> <mohit@piuha.net>
>
>
>
> A new version of I-D, draft-aura-eap-noob-00.txt has been successfully
> submitted by Tuomas Aura and posted to the IETF repository.
>
> Name:         draft-aura-eap-noob
> Revision:     00
> Title:                Nimble out-of-band authentication for EAP (EAP-NOOB)
> Document date:        2016-02-08
> Group:                Individual Submission
> Pages:                35
> URL:https://www.ietf.org/internet-drafts/draft-aura-eap-noob-00.txt
> Status:https://datatracker.ietf.org/doc/draft-aura-eap-noob/
> Htmlized:https://tools.ietf.org/html/draft-aura-eap-noob-00
>
>
> Abstract:
>     Extensible Authentication Protocol (EAP) [RFC3748] provides support
>     for multiple authentication methods.  This document defines the EAP-
>     NOOB authentication method for nimble out-of-band (OOB)
>     authentication and key derivation.  This EAP method is intended for
>     bootstrapping all kinds of Internet-of-Things (IoT) devices that have
>     a minimal user interface and no pre-configured authentication
>     credentials.  The method makes use of a user-assisted one-directional
>     OOB channel between the peer device and authentication server.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag

Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.

Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.  


_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

--------------000209030701050106030507-- From nobody Mon Feb 29 13:29:36 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307601B3C88 for ; Mon, 29 Feb 2016 13:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham 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 lmTS0fw7-A5j for ; Mon, 29 Feb 2016 13:29:25 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017D91B3C87 for ; Mon, 29 Feb 2016 13:29:24 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0183.outbound.protection.outlook.com [213.199.154.183]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-1-nr6Q1CltQl6sdIWsQ8FR5A-1; Mon, 29 Feb 2016 21:29:17 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vuEs2BNEX5U6DURkYBuVHmGQvEXfe9QRP+Bp99+Hn6E=; b=iQ5GfK6HjEvNaU7HuWUtY20QbycGCxAEgoieVjHnnqvdagvjFW9k6tED78iFNzoE+uC7jIOoCRCIonMIFQTOdGRyY0XLBSmEgzI99zI/FrBNKV2lrWIzqavMkGgz+8Rj1tX3DU6aTF/hcTJzgJ6/9OwgTXwFLiLtlRBiL+3tKMo= Received: from VI1PR07MB1581.eurprd07.prod.outlook.com (10.165.239.15) by VI1PR07MB1581.eurprd07.prod.outlook.com (10.165.239.15) with Microsoft SMTP Server (TLS) id 15.1.415.20; Mon, 29 Feb 2016 21:29:15 +0000 Received: from VI1PR07MB1581.eurprd07.prod.outlook.com ([10.165.239.15]) by VI1PR07MB1581.eurprd07.prod.outlook.com ([10.165.239.15]) with mapi id 15.01.0415.022; Mon, 29 Feb 2016 21:29:15 +0000 From: Josh Howlett To: Mohit Sethi , Aura Tuomas , "saag@ietf.org" Thread-Topic: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt Thread-Index: AQHRYoZDK9zX977Aak+i2I4nCLSSvZ8yG4LAgAAN+ACAAArkq4AABVRigBEpYICAAEYSoA== Date: Mon, 29 Feb 2016 21:29:15 +0000 Message-ID: References: <20160208123035.1562.80507.idtracker@ietfa.amsl.com> <56B8B561.8040300@ericsson.com> <7F9C975440487E49BBD35F4FB088ED74CFCDBF14@EXMDB01.org.aalto.fi> <56D47B79.7010306@ericsson.com> In-Reply-To: <56D47B79.7010306@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.129.19.245] x-microsoft-exchange-diagnostics: 1; VI1PR07MB1581; 5:3UCWL7bL6zjRtWMOa8RZSJujBk2GtYP3BzYUxEGz3LwnYQFC8376Qn9LmM8KDf6TsPo6C9GvaGzxYmMkJN20hNuYC5SDsjETjIAOWhLAnTaaQwUEke2N9EH7pJfC/A4Abu/l2f+lZATMiAI7gSO3SA==; 24:jcxddhFQeviDcbnzDaxW6bjVI5eYbToIxzhPwyxWM4IphdcnwU/YHqNGESjrNzI28gI4hKuiEfdFkbDyyjrQ1r31zSwEvRFRlrte2ldrFlw=; 20:jO/eQ5AbjTDSHEArVUwVpNA7/NlBE4ZxMQxO/C0DAtYzqFxs5LlftxFYDPEZ8m6jawXqAhON0RRjABrIQhhEZ0j+xjQH8DX5XsqLoN+LTN98bjEH8MK8/qOW9aF9FkqLIa9v6TcV2Ommkit+zC0381cZomYZbraMhx9lNzeWMlE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1581; x-ms-office365-filtering-correlation-id: dcd461f4-81ab-469c-8e51-08d3414f5fe8 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(274715658323672); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:VI1PR07MB1581; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1581; x-forefront-prvs: 0867F4F1AA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377424004)(479174004)(377454003)(164054003)(43784003)(3905003)(24454002)(13464003)(2473001)(76176999)(77096005)(5004730100002)(11100500001)(93886004)(15975445007)(586003)(19300405004)(102836003)(74316001)(1220700001)(2950100001)(2900100001)(1096002)(87936001)(5001960100003)(86362001)(6116002)(3846002)(50986999)(790700001)(189998001)(5001770100001)(107886002)(122556002)(19625215002)(33656002)(5008740100001)(230783001)(7110500001)(19617315012)(40100003)(92566002)(74482002)(15650500001)(66066001)(5003600100002)(76576001)(10710500007)(54356999)(16236675004)(5002640100001)(2501003)(10400500002)(3900700001)(2420400007)(3280700002)(2906002)(19580395003)(81156008)(3660700001)(19580405001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB1581; H:VI1PR07MB1581.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Feb 2016 21:29:15.5263 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1581 X-MC-Unique: nr6Q1CltQl6sdIWsQ8FR5A-1 Content-Type: multipart/alternative; boundary="_000_VI1PR07MB158122B1D7CA9D7B1D5B55CBBCBA0VI1PR07MB1581eurp_" Archived-At: Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 21:29:35 -0000 --_000_VI1PR07MB158122B1D7CA9D7B1D5B55CBBCBA0VI1PR07MB1581eurp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi Mohit, Thanks, but I still don't follow the use case. I thought the draft is tryin= g to address the scenario where I have devices from multiple vendors wantin= g to register themselves against each vendors' systems (e.g., my fridge reg= isters with my fridge vendor's AAA server; my washing machine with my washi= ng machine vendor's AAA server; etc.). How does my NAS know how to forward = a request to the correct realm if each request is using the same realm? Josh. From: Mohit Sethi [mailto:mohit.m.sethi@ericsson.com] Sent: 29 February 2016 17:10 To: Josh Howlett ; Aura Tuomas ; Mohit Sethi ; saag@ietf.org Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap-noob-0= 0.txt Hi Josh Thanks again for your useful questions. 1. The requests for "eap-noob.net" would either be served by a local AAA se= rver or a remote AAA server for which a forwarding rule has been added. The= request would not be forwarded to a global server based on DNS lookups. He= nce, a DNS lookup for eap-noob.net is expected to respond with NXDOMAIN. 2. The need for the special purpose realm is to allow devices from any manu= facturer to be directed to the AAA server of your choice. You only need set= up the server or add the forwarding once for all the devices from any manuf= acturer. Not everyone wants to depend on the device vendor's AAA service fo= r security.Besides, depending on a vendor service may not be always safe. A= s Stephen had pointed out in another mail thread (https://www.ietf.org/mail= -archive/web/ace/current/msg01470.html), commercial devices will be end-of-= lifed by vendors, and yet they still need to be functional for the owner. /--Mohit On 02/18/2016 09:05 PM, Josh Howlett wrote: Sorry, ignore question 3, it makes no sense here. From: Josh Howlett Sent: 18 February 2016 18:47 To: Aura Tuomas; Mohit Sethi; saag@ietf.org; emu@ietf.org Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap-noob-0= 0.txt Hi Aura, A couple of other questions on the deployment theme: 1. How would requests towards the single special people realm get dis= ambiguated among the multiple AAA servers? 2. In fact, what's the need for this special purpose realm at all - w= hy not let the vendor burn one into the firmware, and use an intermediate A= AA routing fabric do the AAA server discovery? 3. Why this and not WPS (or something similar?) Josh. Sent from Outlook Mail fo= r Windows 10 phone From: Aura Tuomas Sent: 18 February 2016 18:07 To: Josh Howlett; Mohit Sethi; saag@ietf.org; emu@ietf.org Subject: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-0= 0.txt Hi Josh, Good observation; we may need to be clearer about the intended usage scenar= ios for EAP-NOOB. In the home setting, the AAA server would typically be a cloud-based servic= e, where the consumer can register a user account. This does require the 80= 2.1X authentication (i.e. WPA2-Enterprise) to be configured at the home NAS= , so that authentication for "@eap-noob.net" is forwarded to the cloud-base= d AAA server. You only need to configure the NAS once, and all future devic= es can be connected without touching the NAS. This is a change from the way home wireless routers are configured today. W= e think that, as the number of IoT devices grows, configuring them with a s= hared passphrase will be too inconvenient. Obviously, the shared passphrase= is also vulnerable to a single untrusted IoT device that may leak the pass= phrase, and using EAP helps to isolate the devices. Of course, the benefits of EAP-NOOB will be greater in organizations which = already use 802.1X authentication and which have larger numbers of IoT devi= ces than a single home. Anything else that we need to address? Tuomas -----Original Message----- From: Josh Howlett [mailto:Josh.Howlett@jisc.ac.uk] Sent: Thursday, 18 February, 2016 19:28 To: Mohit Sethi ; saag@ietf.org; emu@ietf.org Cc: Aura Tuomas Subject: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-0= 0.txt Hi Mohit, This is an interesting draft, but I'm struggling to understand how this wou= ld be deployed in the consumer settings that the document alludes to. For e= xample, who do you anticipate will be operating the NAS (the consumer?), AA= A server (the vendor?), and the AAA fabric between these actors? Josh. > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Mohit Sethi > Sent: 08 February 2016 15:34 > To: saag@ietf.org; emu@ietf.org > Cc: tuomas.aura@aalto.fi > Subject: [saag] Fwd: New Version Notification for > draft-aura-eap-noob-00.txt > > Dear all > > We have just submitted a new IETF Draft titled "Nimble out-of-band > authentication for EAP (EAP-NOOB)". > > The draft defines an EAP method where the authentication is based on a > user-assisted out-of-band (OOB) channel between the server and peer. > It is intended as a generic bootstrapping solution for > Internet-of-Things devices which have no pre-configured authentication > credentials and which are not yet registered on the authentication > server. Consider devices you just bought or borrowed. > > The EAP-NOOB method is more generic than most ad-hoc bootstrapping > solutions in that it supports many types of OOB channels. We specify > the exact in-band messages but only the OOB message contents and not > the OOB channel details. Also, EAP-NOOB supports ubicomp devices with > only output (e.g. display) or only input (e.g. camera). Moreover, it > makes combined use of both secrecy and integrity of the OOB channel > for more robust security than the ad-hoc solutions. We have put a lot > of effort into designing a robust security protocol. > > For one application example, we have used an earlier version of the > protocol for bootstrapping security for ubiquitous displays: the user > can configure wireless network access, link the device to a cloud > service, and register ownership of the device for a specific cloud > user - all in one simple step of scanning a QR code with a smart > phone. There seemed to more potential to this idea than just using it > for our own system, and thus we decided to write a generic EAP method for= out-of-band authentication. > > The draft is available here: > https://tools.ietf.org/html/draft-aura-eap-noob-00 > > Please see if you can make use of it. We look forward to your feedback > and comments. > > Regards > /--Mohit > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-aura-eap-noob-00.txt > Date: Mon, 08 Feb 2016 04:30:35 -0800 > From: internet-drafts@ietf.org > To: Tuomas Aura , M= ohit Sethi > > > > > A new version of I-D, draft-aura-eap-noob-00.txt has been successfully > submitted by Tuomas Aura and posted to the IETF repository. > > Name: draft-aura-eap-noob > Revision: 00 > Title: Nimble out-of-band authentication for EAP (EAP-NOOB= ) > Document date: 2016-02-08 > Group: Individual Submission > Pages: 35 > URL:https://www.ietf.org/internet-drafts/draft-aura-eap-noob-00.txt > Status:https://datatracker.ietf.org/doc/draft-aura-eap-noob/ > Htmlized:https://tools.ietf.org/html/draft-aura-eap-noob-00 > > > Abstract: > Extensible Authentication Protocol (EAP) [RFC3748] provides support > for multiple authentication methods. This document defines the EAP- > NOOB authentication method for nimble out-of-band (OOB) > authentication and key derivation. This EAP method is intended for > bootstrapping all kinds of Internet-of-Things (IoT) devices that have > a minimal user interface and no pre-configured authentication > credentials. The method makes use of a user-assisted one-directional > OOB channel between the peer device and authentication server. > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.iet= f.org. > > The IETF Secretariat > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag Jisc is a registered charity (number 1149740) and a company limited by guar= antee which is registered in England under Company No. 5747339, VAT No. GB = 197 0632 86. Jisc's registered office is: One Castlepark, Tower Hill, Brist= ol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limit= ed by guarantee which is registered in England under company number 2881024= , VAT number GB 197 0632 86. The registered office is: One Castle Park, Tow= er Hill, Bristol BS2 0JA. T 0203 697 5800. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --_000_VI1PR07MB158122B1D7CA9D7B1D5B55CBBCBA0VI1PR07MB1581eurp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Hi Mohit,

 

Thanks, but I still don’t follow the use case. I thought the dra= ft is trying to address the scenario where I have devices from multiple ven= dors wanting to register themselves against each vendors’ systems (e.g., my fridge registers with my fridge vend= or’s AAA server; my washing machine with my washing machine vendor= 217;s AAA server; etc.). How does my NAS know how to forward a request to t= he correct realm if each request is using the same realm?

 

Josh.

 

F= rom: Mohit Sethi= [mailto:mohit.m.sethi@ericsson.com]
Sent: 29 February 2016 17:10
To: Josh Howlett <Josh.Howlett@jisc.ac.uk>; Aura Tuomas <tu= omas.aura@aalto.fi>; Mohit Sethi <mohit.m.sethi@ericsson.com>; saa= g@ietf.org
Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap= -noob-00.txt

 

Hi Josh

Thanks again for your useful questions.

1. The requests for "eap-noob.net" would either be served by a lo= cal AAA server or a remote AAA server for which a forwarding rule has been = added. The request would not be forwarded to a global server based on DNS l= ookups. Hence, a DNS lookup for eap-noob.net is expected to respond with NXDOMAIN.

2. The need for the special purpose realm is to allow devices from any manu= facturer to be directed to the AAA server of your choice. You only need set= up the server or add the forwarding once for all the devices from any manuf= acturer. Not everyone wants to depend on the device vendor's AAA service for security.Besides, depending on a ve= ndor service may not be always safe. As Stephen had pointed out in another = mail thread (https://www.ietf.org/mail-archive/web/ace/current/msg01470.ht= ml), commercial devices will be end-of-lifed by vendors, and yet they still nee= d to be functional for the owner.

/--Mohit

On 02/18/2016 09:05 PM, Josh Howlett wrote:

Sorry, ignore question 3, it makes no sense here.

 

From: Josh Howlett
Sent: 18 February 2016 18:47
To: Aura Tuomas; Mohit Sethi; saag@ietf.org; emu@ietf.org
Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap= -noob-00.txt

 

Hi Aura,

 

A couple of other questions on the deployment them= e:

 

1. &n= bsp;     How would requests towards the single special people realm get disam= biguated among the multiple AAA servers?

2. &n= bsp;     In fact, what’s the need for this special purpose realm at all= – why not let the vendor burn one into the firmware, and use an inte= rmediate AAA routing fabric do the AAA server discovery?

3. &n= bsp;     Why this and not WPS (or something similar?)

 

Josh.

 

 

 

Sent from Outlook Mail for Windows 10 phone

 

From: Aura Tuomas
Sent: 18 February 2016 18:07
To: Josh Howlett; Mohit Sethi; saag@ietf.org; emu@ietf.org
Subject: RE: [saag] Fwd: New Version Notification for draft-aura-eap= -noob-00.txt

 

Hi Josh,

Good observation; we may need to be clearer about the intended usage scenar= ios for EAP-NOOB.

In the home setting, the AAA server would typically be a cloud-based servic= e, where the consumer can register a user account. This does require the 80= 2.1X authentication (i.e. WPA2-Enterprise) to be configured at the home NAS= , so that authentication for "@eap-noob.net" is forwarded to the cloud-based AAA server. You only need to configure the= NAS once, and all future devices can be connected without touching the NAS= .

This is a change from the way home wireless routers are configured today. W= e think that, as the number of IoT devices grows, configuring them with a s= hared passphrase will be too inconvenient. Obviously, the shared passphrase= is also vulnerable to a single untrusted IoT device that may leak the passphrase, and using EAP helps to = isolate the devices.

Of course, the benefits of EAP-NOOB will be greater in organizations which = already use 802.1X authentication and which have larger numbers of IoT devi= ces than a single home.

Anything else that we need to address?

Tuomas



-----Original Message-----
From: Josh Howlett [mailto:Josh.= Howlett@jisc.ac.uk]
Sent: Thursday, 18 February, 2016 19:28
To: Mohit Sethi <mohit.m.s= ethi@ericsson.com>; saag@ietf.org; emu@ietf.org
Cc: Aura Tuomas <tuomas.aura@aal= to.fi>
Subject: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-0= 0.txt

Hi Mohit,

This is an interesting draft, but I'm struggling to understand how this wou= ld be deployed in the consumer settings that the document alludes to. For e= xample, who do you anticipate will be operating the NAS (the consumer?), AA= A server (the vendor?), and the AAA fabric between these actors?

Josh.

> -----Original Message-----
> From: saag [mailto:saag-bounc= es@ietf.org] On Behalf Of Mohit Sethi
> Sent: 08 February 2016 15:34
> To: saag@ietf.org; emu@ietf.org
> Cc: tuomas.aura@aalto.fi > Subject: [saag] Fwd: New Version Notification for
> draft-aura-eap-noob-00.txt
>
> Dear all
>
> We have just submitted a new IETF Draft titled “Nimble out-of-ba= nd
> authentication for EAP (EAP-NOOB)”.
>
> The draft defines an EAP method where the authentication is based on a=
> user-assisted out-of-band (OOB) channel between the server and peer. <= br> > It is intended as a generic bootstrapping solution for
> Internet-of-Things devices which have no pre-configured authentication=
> credentials and which are not yet registered on the authentication > server. Consider devices you just bought or borrowed.
>
> The EAP-NOOB method is more generic than most ad-hoc bootstrapping > solutions in that it supports many types of OOB channels. We specify <= br> > the exact in-band messages but only the OOB message contents and not <= br> > the OOB channel details. Also, EAP-NOOB supports ubicomp devices with =
> only output (e.g. display) or only input (e.g. camera). Moreover, it <= br> > makes combined use of both secrecy and integrity of the OOB channel > for more robust security than the ad-hoc solutions. We have put a lot =
> of effort into designing a robust security protocol.
>
> For one application example, we have used an earlier version of the > protocol for bootstrapping security for ubiquitous displays: the user =
> can configure wireless network access, link the device to a cloud
> service, and register ownership of the device for a specific cloud > user – all in one simple step of scanning a QR code with a smart=
> phone. There seemed to more potential to this idea than just using it =
> for our own system, and thus we decided to write a generic EAP method = for out-of-band authentication.
>
> The draft is available here:
> https:/= /tools.ietf.org/html/draft-aura-eap-noob-00
>
> Please see if you can make use of it. We look forward to your feedback=
> and comments.
>
> Regards
> /--Mohit
>
>
> -------- Forwarded Message --------
> Subject:       New Version Notification = for draft-aura-eap-noob-00.txt
> Date:  Mon, 08 Feb 2016 04:30:35 -0800
> From:  internet-draft= s@ietf.org
> To:    Tuomas Aura <tuomas.aura@aalto.fi>, Mohit Sethi
> <mohit@piuha.net>
>
>
>
> A new version of I-D, draft-aura-eap-noob-00.txt has been successfully=
> submitted by Tuomas Aura and posted to the IETF repository.
>
> Name:         draft-aura-eap-n= oob
> Revision:     00
> Title:          &nbs= p;     Nimble out-of-band authentication for EAP (EAP-N= OOB)
> Document date:        2016-02-08 > Group:          &nbs= p;     Individual Submission
> Pages:          &nbs= p;     35
> URL:https://www.ietf.org/internet-drafts/draft-aura-eap-noob-00.txt
> Status:https://datatracker.ietf.org/doc/draft-aura-eap-noob/
> Htmlized:https://tools.ietf.org/html/draft-aura-eap-noob-00
>
>
> Abstract:
>     Extensible Authentication Protocol (EAP) [RFC3= 748] provides support
>     for multiple authentication methods.  Thi= s document defines the EAP-
>     NOOB authentication method for nimble out-of-b= and (OOB)
>     authentication and key derivation.  This = EAP method is intended for
>     bootstrapping all kinds of Internet-of-Things = (IoT) devices that have
>     a minimal user interface and no pre-configured= authentication
>     credentials.  The method makes use of a u= ser-assisted one-directional
>     OOB channel between the peer device and authen= tication server.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at tools.= ietf.org.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.iet= f.org/mailman/listinfo/saag

Jisc is a registered charity (number 1149740) and a company limited by guar= antee which is registered in England under Company No. 5747339, VAT No. GB = 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill,= Bristol, BS2 0JA. T 0203 697 5800.

Jisc Services Limited is a wholly owned Jisc subsidiary and a company limit= ed by guarantee which is registered in England under company number 2881024= , VAT number GB 197 0632 86. The registered office is: One Castle Park, Tow= er Hill, Bristol BS2 0JA. T 0203 697 5800.  




_______________________________________________
saag mailing list
saag@ietf.org
https://www.iet=
f.org/mailman/listinfo/saag

 

--_000_VI1PR07MB158122B1D7CA9D7B1D5B55CBBCBA0VI1PR07MB1581eurp_--