From sumanth@cablelabs.com Tue Aug 2 13:12:08 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314B021F8610 for ; Tue, 2 Aug 2011 13:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.338 X-Spam-Level: X-Spam-Status: No, score=-0.338 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6Pn3eji0VkT for ; Tue, 2 Aug 2011 13:12:06 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8434E21F85FF for ; Tue, 2 Aug 2011 13:12:02 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id p72KCBYx030313 for ; Tue, 2 Aug 2011 14:12:11 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Tue, 2 Aug 2011 14:12:11 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 2 Aug 2011 14:12:11 -0600 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Tue, 2 Aug 2011 14:12:09 -0600 Thread-Topic: Interim meeting: Poll results Thread-Index: AcxRUHWZqoif0kTNRk6oh3COj5MfpA== Message-ID: <76AC5FEF83F1E64491446437EA81A61F8190804D52@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_76AC5FEF83F1E64491446437EA81A61F8190804D52srvxchg_" MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] Interim meeting: Poll results X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 20:12:08 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F8190804D52srvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Thanks to those who responded to the interim meeting poll from last week (= see below). Accordingly, it seems like the one option that works for everyo= ne (from those presented) is: - Tue, Aug 31, from 1:00 PM - 5:00 PM (Eastern) - See: http://www.doodle.com/zur2gmqygwyxbia9#table If anyone has objections to this date or time, or want to request additiona= l options, please let us know by Noon (Eastern) tomorrow. If we don't hear = any further requests, we will have an interim meeting with the interested p= arties on this date. This will be a virtual meeting and we will provide rem= ote participation information in advance of the interim meeting. - Alex and Sumanth (as WG Chairs) From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Sumanth Channabasappa Sent: Tuesday, July 26, 2011 8:05 PM To: Drinks@ietf.org Subject: [drinks] Poll to pick a day for the proposed interim meeting Folks, Thanks again for a productive DRINKS WG meeting earlier today! During the m= eeting we proposed that we have an interim meeting to complete and validate= the changes to the protocol document (and if required, the transport docum= ent). A few participants volunteered to participate. As a follow-up, here's a poll to pick a day that would work best for most o= f the interested parties. The dates are based on offline suggestions. If no= ne of the proposed days are feasible, please feel free to suggest alternati= ve dates (via email). Link to the poll: http://www.doodle.com/zur2gmqygwyxbia9#table (Pick the timezone from the drop-down.) If you are interested in attending, please provide your responses by the en= d of this week. Thanks! - Alex and Sumanth (as WG Chairs) --_000_76AC5FEF83F1E64491446437EA81A61F8190804D52srvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

<= p class=3DMsoNormal>Thanks to t= hose who responded to the interim meeting poll from last week  (see be= low). Accordingly, it seems like the one option that works for everyone (fr= om those presented) is:

 

- Tue, Aug 31, from 1:= 00 PM - 5:00 PM (Eastern)

- See: http://ww= w.doodle.com/zur2gmqygwyxbia9#table

 

If an= yone has objections to this date or time, or want to request additional opt= ions, please let us know by Noon (Eastern) tomorrow. If we don’t hear= any further requests, we will have an interim meeting with the interested = parties on this date. This will be a virtual meeting and we will provide re= mote participation information in advance of the interim meeting.

 

- Alex and Sumanth (as WG Chairs)

&nbs= p;

From: drinks-bounces@ie= tf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Sumanth Channab= asappa
Sent: Tuesday, July 26, 2011 8:05 PM
To: Drinks@= ietf.org
Subject: [drinks] Poll to pick a day for the proposed in= terim meeting

&n= bsp;

Folks,<= o:p>

=  

Thanks again for a productive DRINKS WG meeting earlier today! Durin= g the meeting we proposed that we have an interim meeting to complete and v= alidate the changes to the protocol document (and if required, the transpor= t document). A few participants volunteered to participate.

 

As a fo= llow-up, here’s a poll to pick a day that would work best for most of= the interested parties. The dates are based on offline suggestions. If non= e of the proposed days are feasible, please feel free to suggest alternativ= e dates (via email).

 

Link to the poll:

http://www.doodle.com/zur2gmqygwyxbia9#table

(Pick the timezone from the drop-down.)

 

<= p class=3DMsoNormal>If you are interested = in attending, please provide your responses by the end of this week.

&= nbsp;

Thanks!

- Alex and Sumanth (as WG Chairs)

 

 <= /p>

= --_000_76AC5FEF83F1E64491446437EA81A61F8190804D52srvxchg_-- From sumanth@cablelabs.com Wed Aug 3 12:51:07 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD36011E8088 for ; Wed, 3 Aug 2011 12:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.356 X-Spam-Level: X-Spam-Status: No, score=-0.356 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOTL+XssRN-M for ; Wed, 3 Aug 2011 12:51:05 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7195F11E807E for ; Wed, 3 Aug 2011 12:51:05 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id p73JpGhJ029902 for ; Wed, 3 Aug 2011 13:51:16 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 3 Aug 2011 13:51:16 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 3 Aug 2011 13:51:17 -0600 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Wed, 3 Aug 2011 13:51:16 -0600 Thread-Topic: [drinks] Interim meeting: Poll results Thread-Index: AcxRUHWZqoif0kTNRk6oh3COj5MfpAAfMZ2wABJIY6A= Message-ID: <76AC5FEF83F1E64491446437EA81A61F8190804E54@srvxchg> References: <76AC5FEF83F1E64491446437EA81A61F8190804D52@srvxchg> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_76AC5FEF83F1E64491446437EA81A61F8190804E54srvxchg_" MIME-Version: 1.0 X-Approved: ondar Subject: Re: [drinks] Interim meeting: Poll results X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 19:51:07 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F8190804E54srvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As a quick follow-up, there was one additional response to the poll and it = seems like Aug 31st is still a good date. Hence, we will have the interim v= irtual meeting on this date. Details to follow over the next few days. One correction from my earlier email (see below): Aug 31st of this year is = a Wednesday and not a Tuesday - thanks to Dan Romascanu for pointing that o= ut :)! - S Folks, Thanks to those who responded to the interim meeting poll from last week (= see below). Accordingly, it seems like the one option that works for everyo= ne (from those presented) is: - Tue, Aug 31, from 1:00 PM - 5:00 PM (Eastern) - See: http://www.doodle.com/zur2gmqygwyxbia9#table If anyone has objections to this date or time, or want to request additiona= l options, please let us know by Noon (Eastern) tomorrow. If we don't hear = any further requests, we will have an interim meeting with the interested p= arties on this date. This will be a virtual meeting and we will provide rem= ote participation information in advance of the interim meeting. - Alex and Sumanth (as WG Chairs) From: drinks-bounces@ietf.org [mailto:drink= s-bounces@ietf.org] On Behalf Of S= umanth Channabasappa Sent: Tuesday, July 26, 2011 8:05 PM To: Drinks@ietf.org Subject: [drinks] Poll to pick a day for the proposed interim meeting Folks, Thanks again for a productive DRINKS WG meeting earlier today! During the m= eeting we proposed that we have an interim meeting to complete and validate= the changes to the protocol document (and if required, the transport docum= ent). A few participants volunteered to participate. As a follow-up, here's a poll to pick a day that would work best for most o= f the interested parties. The dates are based on offline suggestions. If no= ne of the proposed days are feasible, please feel free to suggest alternati= ve dates (via email). Link to the poll: http://www.doodle.com/zur2gmqygwyxbia9#table (Pick the timezone from the drop-down.) If you are interested in attending, please provide your responses by the en= d of this week. Thanks! - Alex and Sumanth (as WG Chairs) --_000_76AC5FEF83F1E64491446437EA81A61F8190804E54srvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As a quick follow-up, there was one additional response to the p= oll and it seems like Aug 31st is still a good date. Hence, we w= ill have the interim virtual meeting on this date. Details to follow over t= he next few days.

 

One correction from my earlier email (see below): Aug 31st of this year is a Wednesday and not a Tuesday – thanks to = Dan Romascanu for pointing that out J!

=

 

- S

<= p class=3DMsoNormal> 

=

 

Folks,

 <= /span>

= Thanks to those who responded to the interim meeting poll from last week &n= bsp;(see below). Accordingly, it seems like the one option that works for e= veryone (from those presented) is:

 

<= p class=3DMsoNormal>- Tue, Aug = 31, from 1:00 PM - 5:00 PM (Eastern)

- See: http://www.doodle.com/zur2gmqygwyxbia9#table

=

 = ;

If anyone has objections to this date or time, or want to request a= dditional options, please let us know by Noon (Eastern) tomorrow. If we don= ’t hear any further requests, we will have an interim meeting with th= e interested parties on this date. This will be a virtual meeting and we wi= ll provide remote participation information in advance of the interim meeti= ng.

 

- Alex and Sumanth (as WG Chairs)

 

From:<= /b> drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.or= g] On Behalf Of Sumanth Channabasappa
Sent: Tuesday, J= uly 26, 2011 8:05 PM
To: Drink= s@ietf.org
Subject: [drinks] Poll to pick a day for the propo= sed interim meeting

<= o:p> 

F= olks,

 

Thanks again for a productive DRINKS WG meeting earlier today!= During the meeting we proposed that we have an interim meeting to complete= and validate the changes to the protocol document (and if required, the tr= ansport document). A few participants volunteered to participate.

&nb= sp;

A= s a follow-up, here’s a poll to pick a day that would work best for m= ost of the interested parties. The dates are based on offline suggestions. = If none of the proposed days are feasible, please feel free to suggest alte= rnative dates (via email).

 

Link to the poll:

<= p class=3DMsoNormal>http://www.doodle.com/zur2gmqygwyxbia9#t= able

(Pick the timezone from the drop-down.)

 <= /p>

If you are interes= ted in attending, please provide your responses by the end of this week.

 

Thanks!

- Alex and Sumanth (as WG Chairs)

 

=

 

= --_000_76AC5FEF83F1E64491446437EA81A61F8190804E54srvxchg_-- From alexander.mayrhofer@nic.at Wed Aug 3 13:29:45 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D3F21F8A95 for ; Wed, 3 Aug 2011 13:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.314 X-Spam-Level: X-Spam-Status: No, score=-10.314 tagged_above=-999 required=5 tests=[AWL=1.116, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkSFRng+S-5i for ; Wed, 3 Aug 2011 13:29:45 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 8035D21F8A96 for ; Wed, 3 Aug 2011 13:29:44 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47 ; Wed, 3 Aug 2011 22:29:55 +0200 Received: from nics-mail.sbg.nic.at (10.17.175.2) by NICS-EXCH.sbg.nic.at (10.17.175.3) with Microsoft SMTP Server id 14.1.218.12; Wed, 3 Aug 2011 22:29:49 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 3 Aug 2011 22:29:44 +0200 Message-ID: <8BC845943058D844ABFC73D2220D46650AB29273@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NITS review of draft-ietf-drinks-usecases-requirements-05 Thread-Index: AcxSFdXPbtaOulrZRJyG75zqdTM9gQ== From: Alexander Mayrhofer To: X-XWALL-BCKS: auto Subject: [drinks] NITS review of draft-ietf-drinks-usecases-requirements-05 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 20:29:45 -0000 I've done a NITS review of the usecases-requirements documents, my comments are as follows: Generally, the draft is well written, and looks ready for publication request, given that the following small issues are resolved: - Terminology & Capitalization: I understand the document specifies additional terminology in Section 1 with a capitalized initial letter (as many other IETF documents do). However, subsequently those terms are mostly referenced with lowercased initial letters, which could make readers assume that those terms do not refer to the terminology definition. Suche terms include "registry", "public identifier", "registrant", "destination group" and many others. This also includes cross-references within the Terminology section itself. Additionally, the term "public identity" and "lookup key" are used throughout the document, but not defined anywhere. Those should be defined, although i assume that "public identity" is identical to "public identifier". - "TN Range" Definition: I don't understand that implications of the part "whose SED can be looked up", as i don't see the defining effect of this here. What would probably work is "with identical SED" (?), but it might very well work to leave that text out. "contiguos set.... of telephone numbers." works well for me. - The abbreviation for "local data repositories" (LDR) should be added after the first instance in the draft (page 5). The legend of Figure 2 would then be redundant. (The first paragraph on page 6 contains many un-capitalized terminology terms!) - The names of some of the boxes in Figure 2 are partly "ALL CAPS". Is there a particular reason for that? - Data Relations on page 8: Given that a TN Range object can only be contained in exactly one Destination Group, can there be several TN Range objects that overlap? There might be scenarios where several Registrars "claim" a TN Range, for example in cases where several transit SSPs provision into a Registry.. - Same for Public Identifiers and DGs. (UC PROV #3: Note that there's text that actually requires the recent change about atomic transactions in the protocol document, where currently both "atomic" and "stop of first error" are allowed [but will be changed as agreed in Quebec]) - UC SED EXCHANGE #4 refers to "this protocol" (at the end of the use case). It is unclear what this refers to, since the document does not specify a protocol. "out of scope of this use case" might work. - UC DATA #3: I had to re-read this use case several times before i understood it (again ;), particularly because the text is quite similar to UC DATA #2. Is there any way to simplify UC DATA #3? - Section 3.6.: It is unclear what a "lookup key" is. I understand it's an instance of a Public Identifier for which information is sought in some way (being used in a "lookup")? A definition would be good. - UC LOOKUP #6 contains "public identity". Is that supposed to be a "public identifier"? - The acronym "SS7" in UC MISC #1 should be expanded. - Same for "PBX" in UC MISC #3. "Which is where" sounds funny to me as a non-native speaker - could a native speaker please re-read that paragraph? - Section 4: "must support these requirements" - isn't that supposed to be a "MUST"? - REQ-LOOKUP-3 sort of defines "Lookup Key". However, the semantics seem to be slightly different from the corresponding "lookup" use cases. A common definition would be beneficial. - REQ-LOOKUP-4 talks about provisioning of "lookup keys", although my impression was they were strictly limited to the "lookup side"? I don't see where "lookup keys" can be "moved to a different Destination Group".. -tia Alex From alexander.mayrhofer@nic.at Tue Aug 9 09:19:33 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497BF21F8C95 for ; Tue, 9 Aug 2011 09:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.438 X-Spam-Level: X-Spam-Status: No, score=-9.438 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZUUpgq7aM4i for ; Tue, 9 Aug 2011 09:19:32 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 75CA021F8C91 for ; Tue, 9 Aug 2011 09:19:31 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47 ; Tue, 9 Aug 2011 18:19:59 +0200 Received: from nics-mail.sbg.nic.at (10.17.175.2) by NICS-EXCH.sbg.nic.at (10.17.175.3) with Microsoft SMTP Server id 14.1.218.12; Tue, 9 Aug 2011 18:19:57 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CC56B0.2D728745" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 9 Aug 2011 18:19:56 +0200 Message-ID: <8BC845943058D844ABFC73D2220D46650AB29752@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: publication requested for use cases draft Thread-Index: AcxWrjPlUTlWveFuTh2zEhev++biZA== From: Alexander Mayrhofer To: X-XWALL-BCKS: auto Subject: [drinks] publication requested for use cases draft X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 16:19:33 -0000 ------_=_NextPart_001_01CC56B0.2D728745 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, we've just requested publication for draft-ietf-drinks-usecases-requirements-05. The PROTO writeup for the document is attached. Sumanth (as document author) is going to submit another version on Thursday, which will fix the NITS that i discovered during my review. Alex ------_=_NextPart_001_01CC56B0.2D728745 Content-Type: text/plain; name="proto-writeup-drinks-usecases.txt" Content-Transfer-Encoding: base64 Content-Description: proto-writeup-drinks-usecases.txt Content-Disposition: attachment; filename="proto-writeup-drinks-usecases.txt" UFJPVE8gV1JJVEVVUCBmb3IgZHJhZnQtaWV0Zi1kcmlua3MtdXNlY2FzZXMtcmVxdWlyZW1lbnRz LTA1DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0NCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWlldGYtZHJpbmtzLXVz ZWNhc2VzLXJlcXVpcmVtZW50cy0wNQ0KDQogICgxLmEpICBXaG8gaXMgdGhlIERvY3VtZW50IFNo ZXBoZXJkIGZvciB0aGlzIGRvY3VtZW50PyAgSGFzIHRoZQ0KICAgICAgICAgRG9jdW1lbnQgU2hl cGhlcmQgcGVyc29uYWxseSByZXZpZXdlZCB0aGlzIHZlcnNpb24gb2YgdGhlDQogICAgICAgICBk b2N1bWVudCBhbmQsIGluIHBhcnRpY3VsYXIsIGRvZXMgaGUgb3Igc2hlIGJlbGlldmUgdGhpcw0K ICAgICAgICAgdmVyc2lvbiBpcyByZWFkeSBmb3IgZm9yd2FyZGluZyB0byB0aGUgSUVTRyBmb3Ig cHVibGljYXRpb24/DQoNClRoZSBkb2N1bWVudCBzaGVwaGVyZCBpcyBBbGV4YW5kZXIgTWF5cmhv ZmVyIChhbGV4YW5kZXIubWF5cmhvZmVyQG5pYy5hdCkuDQpJIGhhdmUgcGVyc29uYWxseSByZXZp ZXdlZCB0aGUgZHJhZnQgc2V2ZXJhbCB0aW1lcywgaW5jbHVkaW5nIGEgZmluYWwgTklUUw0KcmV2 aWV3LCBhbmQgaSBiZWxpZXZlIHRoZSBkb2N1bWVudCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24u IFNvbWUgbWlub3INCk5JVFMgd2VyZSBkaXNjb3ZlcmVkLCBidXQgdGhvc2UgYXJlIGVkaXRvcmlh bCBvbmx5LCBhbmQgd2lsbCBiZSBmaXhlZCANCmFzYXAuDQoNCiAgKDEuYikgIEhhcyB0aGUgZG9j dW1lbnQgaGFkIGFkZXF1YXRlIHJldmlldyBib3RoIGZyb20ga2V5IFdHIG1lbWJlcnMNCiAgICAg ICAgIGFuZCBmcm9tIGtleSBub24tV0cgbWVtYmVycz8gIERvZXMgdGhlIERvY3VtZW50IFNoZXBo ZXJkIGhhdmUNCiAgICAgICAgIGFueSBjb25jZXJucyBhYm91dCB0aGUgZGVwdGggb3IgYnJlYWR0 aCBvZiB0aGUgcmV2aWV3cyB0aGF0DQogICAgICAgICBoYXZlIGJlZW4gcGVyZm9ybWVkPw0KDQpU aGUgZG9jdW1lbnQgaGFzIGJlZW4gcmV2aWV3ZWQgYW5kIGNvbW1lbnRlZCBvbiBieSBib3RoIHdv cmtpbmcgZ3JvdXANCm1lbWJlcnMgYW5kIG5vbi1XRyBjb250cmlidXRvcnMuIFRoZXJlIGFyZSBu byBjb25jZXJucyByZWdhcmRpbmcgdGhlIA0KZGVwdGggb3IgYnJlYXRoIG9mIHRoZSByZXZpZXdz LiBBbiBvbmdvaW5nIGltcGxlbWVudGF0aW9uIG9mIHRoZSANCnJlbGF0ZWQgcHJvdG9jb2wgZG9j dW1lbnQgaGFzIG5vdCBpbnN0aWdhdGVkIGFueSBjaGFuZ2VzIHRvIHRoZSANCnVzZWNhc2VzIC8g cmVxdWlyZW1lbnRzIGRvY3VtZW50Lg0KDQogICgxLmMpICBEb2VzIHRoZSBEb2N1bWVudCBTaGVw aGVyZCBoYXZlIGNvbmNlcm5zIHRoYXQgdGhlIGRvY3VtZW50DQogICAgICAgICBuZWVkcyBtb3Jl IHJldmlldyBmcm9tIGEgcGFydGljdWxhciBvciBicm9hZGVyIHBlcnNwZWN0aXZlLA0KICAgICAg ICAgZS5nLiwgc2VjdXJpdHksIG9wZXJhdGlvbmFsIGNvbXBsZXhpdHksIHNvbWVvbmUgZmFtaWxp YXIgd2l0aA0KICAgICAgICAgQUFBLCBpbnRlcm5hdGlvbmFsaXphdGlvbiwgb3IgWE1MPw0KDQpU aGVyZSBhcmUgbm8gY29uY2VybnMgdGhhdCBtb3JlIHJldmlldyBpcyByZXF1aXJlZC4gQXMgdGhp cyBpcyBhbiANCmluZm9ybWF0aW9uYWwgZG9jdW1lbnQgb25seSB0aGF0IGNvbnRhaW5zIG5vIHBy b3RvY29sIGVsZW1lbnRzLCBubyANCiJzcGVjaWFsaXplZCIgcmV2aWV3IGlzIGRlZW1lZCBuZWNl c3NhcnkuDQoNCiAgKDEuZCkgIERvZXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIGhhdmUgYW55IHNw ZWNpZmljIGNvbmNlcm5zIG9yDQogICAgICAgICBpc3N1ZXMgd2l0aCB0aGlzIGRvY3VtZW50IHRo YXQgdGhlIFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3INCiAgICAgICAgIGFuZC9vciB0aGUgSUVT RyBzaG91bGQgYmUgYXdhcmUgb2Y/ICBGb3IgZXhhbXBsZSwgcGVyaGFwcyBoZQ0KICAgICAgICAg b3Igc2hlIGlzIHVuY29tZm9ydGFibGUgd2l0aCBjZXJ0YWluIHBhcnRzIG9mIHRoZSBkb2N1bWVu dCwgb3INCiAgICAgICAgIGhhcyBjb25jZXJucyB3aGV0aGVyIHRoZXJlIHJlYWxseSBpcyBhIG5l ZWQgZm9yIGl0LiAgSW4gYW55DQogICAgICAgICBldmVudCwgaWYgdGhlIFdHIGhhcyBkaXNjdXNz ZWQgdGhvc2UgaXNzdWVzIGFuZCBoYXMgaW5kaWNhdGVkDQogICAgICAgICB0aGF0IGl0IHN0aWxs IHdpc2hlcyB0byBhZHZhbmNlIHRoZSBkb2N1bWVudCwgZGV0YWlsIHRob3NlDQogICAgICAgICBj b25jZXJucyBoZXJlLiAgSGFzIGFuIElQUiBkaXNjbG9zdXJlIHJlbGF0ZWQgdG8gdGhpcyBkb2N1 bWVudA0KICAgICAgICAgYmVlbiBmaWxlZD8gIElmIHNvLCBwbGVhc2UgaW5jbHVkZSBhIHJlZmVy ZW5jZSB0byB0aGUNCiAgICAgICAgIGRpc2Nsb3N1cmUgYW5kIHN1bW1hcml6ZSB0aGUgV0cgZGlz Y3Vzc2lvbiBhbmQgY29uY2x1c2lvbiBvbg0KICAgICAgICAgdGhpcyBpc3N1ZS4NCg0KVGhlcmUg YXJlIG5vIGNvbmNlcm5zLCBhbmQgbm8gSVBSIGRpc2Nsb3N1cmUgaGFzIGJlZW4gZmlsZWQuDQoN CiAgKDEuZSkgIEhvdyBzb2xpZCBpcyB0aGUgV0cgY29uc2Vuc3VzIGJlaGluZCB0aGlzIGRvY3Vt ZW50PyAgRG9lcyBpdA0KICAgICAgICAgcmVwcmVzZW50IHRoZSBzdHJvbmcgY29uY3VycmVuY2Ug b2YgYSBmZXcgaW5kaXZpZHVhbHMsIHdpdGgNCiAgICAgICAgIG90aGVycyBiZWluZyBzaWxlbnQs IG9yIGRvZXMgdGhlIFdHIGFzIGEgd2hvbGUgdW5kZXJzdGFuZCBhbmQNCiAgICAgICAgIGFncmVl IHdpdGggaXQ/DQoNClRoZXJlIGlzIHNvbGlkIGNvbmNlbnN1cyBhbW9uZyB0aGUgYWN0aXZlIHBh cnRpY2lwYW50cyBvZiB0aGUgDQp3b3JraW5nIGdyb3VwLg0KDQoNCiAgKDEuZikgIEhhcyBhbnlv bmUgdGhyZWF0ZW5lZCBhbiBhcHBlYWwgb3Igb3RoZXJ3aXNlIGluZGljYXRlZCBleHRyZW1lDQog ICAgICAgICBkaXNjb250ZW50PyAgSWYgc28sIHBsZWFzZSBzdW1tYXJpemUgdGhlIGFyZWFzIG9m IGNvbmZsaWN0IGluDQogICAgICAgICBzZXBhcmF0ZSBlbWFpbCBtZXNzYWdlcyB0byB0aGUgUmVz cG9uc2libGUgQXJlYSBEaXJlY3Rvci4gIChJdA0KICAgICAgICAgc2hvdWxkIGJlIGluIGEgc2Vw YXJhdGUgZW1haWwgYmVjYXVzZSB0aGlzIHF1ZXN0aW9ubmFpcmUgaXMNCiAgICAgICAgIGVudGVy ZWQgaW50byB0aGUgSUQgVHJhY2tlci4pDQoNClRoZXJlIGlzIG5vIG9wcG9zaXRpb24gdG8gdGhp cyBkb2N1bWVudC4NCg0KICAoMS5nKSAgSGFzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCBwZXJzb25h bGx5IHZlcmlmaWVkIHRoYXQgdGhlDQogICAgICAgICBkb2N1bWVudCBzYXRpc2ZpZXMgYWxsIElE IG5pdHM/ICAoU2VlDQogICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL0lELUNoZWNrbGlzdC5o dG1sIGFuZA0KICAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL3Rvb2xzL2lkbml0cy8uKSAg Qm9pbGVycGxhdGUgY2hlY2tzIGFyZQ0KICAgICAgICAgbm90IGVub3VnaDsgdGhpcyBjaGVjayBu ZWVkcyB0byBiZSB0aG9yb3VnaC4gIEhhcyB0aGUgZG9jdW1lbnQNCiAgICAgICAgIG1ldCBhbGwg Zm9ybWFsIHJldmlldyBjcml0ZXJpYSBpdCBuZWVkcyB0bywgc3VjaCBhcyB0aGUgTUlCDQogICAg ICAgICBEb2N0b3IsIG1lZGlhIHR5cGUsIGFuZCBVUkkgdHlwZSByZXZpZXdzPyAgSWYgdGhlIGRv Y3VtZW50DQogICAgICAgICBkb2VzIG5vdCBhbHJlYWR5IGluZGljYXRlIGl0cyBpbnRlbmRlZCBz dGF0dXMgYXQgdGhlIHRvcCBvZg0KICAgICAgICAgdGhlIGZpcnN0IHBhZ2UsIHBsZWFzZSBpbmRp Y2F0ZSB0aGUgaW50ZW5kZWQgc3RhdHVzIGhlcmUuDQoNClRoZSBkb2N1bWVudCB3YXMgTklUUyBy ZXZpZXdlZCBieSB0aGUgRG9jdW1lbnQgc2hlcGhlcmQsIGFuZCBzb21lIA0KbW9zdGx5IGVkaXRv cmlhbCBuaXRzIHdlcmUgZGlzY292ZXJlZC4gVGhvc2Ugd2lsbCBiZSBhZGRyZXNzZXMgYXNhcA0K aW4gYSBuZXcgcmV2aXNpb24uIFRoZSByZXBvcnQgZnJvbSB0aGUgTklUUyByZXZpZXcgd2FzIHBv c3RlZCB0byB0aGUgDQpEUklOS1MgbWFpbGluZyBsaXN0Og0KDQpodHRwOi8vd3d3LmlldGYub3Jn L21haWwtYXJjaGl2ZS93ZWIvZHJpbmtzL2N1cnJlbnQvbXNnMDA5NTguaHRtbA0KDQogICgxLmgp ICBIYXMgdGhlIGRvY3VtZW50IHNwbGl0IGl0cyByZWZlcmVuY2VzIGludG8gbm9ybWF0aXZlIGFu ZA0KICAgICAgICAgaW5mb3JtYXRpdmU/ICBBcmUgdGhlcmUgbm9ybWF0aXZlIHJlZmVyZW5jZXMg dG8gZG9jdW1lbnRzIHRoYXQNCiAgICAgICAgIGFyZSBub3QgcmVhZHkgZm9yIGFkdmFuY2VtZW50 IG9yIGFyZSBvdGhlcndpc2UgaW4gYW4gdW5jbGVhcg0KICAgICAgICAgc3RhdGU/ICBJZiBzdWNo IG5vcm1hdGl2ZSByZWZlcmVuY2VzIGV4aXN0LCB3aGF0IGlzIHRoZQ0KICAgICAgICAgc3RyYXRl Z3kgZm9yIHRoZWlyIGNvbXBsZXRpb24/ICBBcmUgdGhlcmUgbm9ybWF0aXZlIHJlZmVyZW5jZXMN CiAgICAgICAgIHRoYXQgYXJlIGRvd253YXJkIHJlZmVyZW5jZXMsIGFzIGRlc2NyaWJlZCBpbiBb UkZDMzk2N10/ICBJZg0KICAgICAgICAgc28sIGxpc3QgdGhlc2UgZG93bndhcmQgcmVmZXJlbmNl cyB0byBzdXBwb3J0IHRoZSBBcmVhDQogICAgICAgICBEaXJlY3RvciBpbiB0aGUgTGFzdCBDYWxs IHByb2NlZHVyZSBmb3IgdGhlbSBbUkZDMzk2N10uDQoNCg0KVGhlIGRvY3VtZW50IGhhcyByZWZl cmVuY2VzIHNwbGl0IGludG8gbm9ybWF0aXZlIGFuZCBpbmZvcm1hdGl2ZSByZWZlcmVuY2VzLg0K DQoNCiAgICgxLmkpIEhhcyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgdmVyaWZpZWQgdGhhdCB0aGUg ZG9jdW1lbnQncyBJQU5BDQogICAgICAgICBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIGV4aXN0cyBh bmQgaXMgY29uc2lzdGVudCB3aXRoIHRoZSBib2R5DQogICAgICAgICBvZiB0aGUgZG9jdW1lbnQ/ ICBJZiB0aGUgZG9jdW1lbnQgc3BlY2lmaWVzIHByb3RvY29sDQogICAgICAgICBleHRlbnNpb25z LCBhcmUgcmVzZXJ2YXRpb25zIHJlcXVlc3RlZCBpbiBhcHByb3ByaWF0ZSBJQU5BDQogICAgICAg ICByZWdpc3RyaWVzPyAgQXJlIHRoZSBJQU5BIHJlZ2lzdHJpZXMgY2xlYXJseSBpZGVudGlmaWVk PyAgSWYNCiAgICAgICAgIHRoZSBkb2N1bWVudCBjcmVhdGVzIGEgbmV3IHJlZ2lzdHJ5LCBkb2Vz IGl0IGRlZmluZSB0aGUNCiAgICAgICAgIHByb3Bvc2VkIGluaXRpYWwgY29udGVudHMgb2YgdGhl IHJlZ2lzdHJ5IGFuZCBhbiBhbGxvY2F0aW9uDQogICAgICAgICBwcm9jZWR1cmUgZm9yIGZ1dHVy ZSByZWdpc3RyYXRpb25zPyAgRG9lcyBpdCBzdWdnZXN0IGENCiAgICAgICAgIHJlYXNvbmFibGUg bmFtZSBmb3IgdGhlIG5ldyByZWdpc3RyeT8gIFNlZSBbUkZDMjQzNF0uICBJZiB0aGUNCiAgICAg ICAgIGRvY3VtZW50IGRlc2NyaWJlcyBhbiBFeHBlcnQgUmV2aWV3IHByb2Nlc3MsIGhhcyB0aGUg RG9jdW1lbnQNCiAgICAgICAgIFNoZXBoZXJkIGNvbmZlcnJlZCB3aXRoIHRoZSBSZXNwb25zaWJs ZSBBcmVhIERpcmVjdG9yIHNvIHRoYXQNCiAgICAgICAgIHRoZSBJRVNHIGNhbiBhcHBvaW50IHRo ZSBuZWVkZWQgRXhwZXJ0IGR1cmluZyBJRVNHIEV2YWx1YXRpb24/DQoNClRoZXJlIGFyZSBubyBJ QU5BIGNvbnNpZGVyYXRpb25zLg0KDQoNCiAgKDEuaikgIEhhcyB0aGUgRG9jdW1lbnQgU2hlcGhl cmQgdmVyaWZpZWQgdGhhdCBzZWN0aW9ucyBvZiB0aGUNCiAgICAgICAgIGRvY3VtZW50IHRoYXQg YXJlIHdyaXR0ZW4gaW4gYSBmb3JtYWwgbGFuZ3VhZ2UsIHN1Y2ggYXMgWE1MDQogICAgICAgICBj b2RlLCBCTkYgcnVsZXMsIE1JQiBkZWZpbml0aW9ucywgZXRjLiwgdmFsaWRhdGUgY29ycmVjdGx5 IGluDQogICAgICAgICBhbiBhdXRvbWF0ZWQgY2hlY2tlcj8NCg0KVGhlcmUgYXJlIG5vIHNlY3Rp b25zIGluIHRoZSBkb2N1bWVudCB0aGF0IG1ha2UgdXNlIG9mIGZvcm1hbCBsYW5ndWFnZS4NCg0K ICAoMS5rKSAgVGhlIElFU0cgYXBwcm92YWwgYW5ub3VuY2VtZW50IGluY2x1ZGVzIGEgRG9jdW1l bnQNCiAgICAgICAgIEFubm91bmNlbWVudCBXcml0ZS1VcC4gIFBsZWFzZSBwcm92aWRlIHN1Y2gg YSBEb2N1bWVudA0KICAgICAgICAgQW5ub3VuY2VtZW50IFdyaXRlLVVwLiAgUmVjZW50IGV4YW1w bGVzIGNhbiBiZSBmb3VuZCBpbiB0aGUNCiAgICAgICAgICJBY3Rpb24iIGFubm91bmNlbWVudHMg Zm9yIGFwcHJvdmVkIGRvY3VtZW50cy4gIFRoZSBhcHByb3ZhbA0KICAgICAgICAgYW5ub3VuY2Vt ZW50IGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgc2VjdGlvbnM6DQoNClRlY2huaWNhbCBTdW1tYXJ5 DQoNCiAgIFRoaXMgZG9jdW1lbnQgY2FwdHVyZXMgdGhlIHVzZSBjYXNlcyBhbmQgYXNzb2NpYXRl ZCByZXF1aXJlbWVudHMgZm9yDQogICBpbnRlcmZhY2VzIHRoYXQgcHJvdmlzaW9uIHNlc3Npb24g ZXN0YWJsaXNobWVudCBkYXRhIGludG8gU0lQIFNlcnZpY2UNCiAgIFByb3ZpZGVyIGNvbXBvbmVu dHMsIHRvIGFzc2lzdCB3aXRoIHNlc3Npb24gcm91dGluZy4gIFNwZWNpZmljYWxseSwNCiAgIHRo ZSBjdXJyZW50IHZlcnNpb24gb2YgdGhpcyBkb2N1bWVudCBmb2N1c2VzIG9uIHRoZSBwcm92aXNp b25pbmcgb2YNCiAgIG9uZSBzdWNoIGVsZW1lbnQsIHRlcm1lZCB0aGUgcmVnaXN0cnkuDQoNCg0K V29ya2luZyBHcm91cCBTdW1tYXJ5DQoNCiAgIFRoZSBXRyBhZ3JlZWQgdGhhdCBmb3IgdGhlIGRl dmVsb3BtZW50IG9mIHRoZSBTZXNzaW9uIFBlZXJpbmcgDQogICBQcm92aXNpb25pbmcgUHJvdG9j b2wsIGFuIGFwcHJvYWNoIHdoZXJlIHVzZSBjYXNlcyB3b3VsZCBkcml2ZQ0KICAgcmVxdWlyZW1l bnRzLCBhbmQgcmVxdWlyZW1lbnRzIGluIHR1cm4gd291bGQgdGhlbiBkcml2ZSANCiAgIHByb3Rv Y29sIGRldmVsb3BtZW50IHdhcyB0aGUgcmlnaHQgYXBwcm9hY2guIFRoZSB1c2UgY2FzZXMgYW5k IA0KICAgcmVxdWlyZW1lbnRzIGRvY3VtZW50IGhhcyBiZWVuIGRldmVsb3BlZCBvdmVyIHNldmVy YWwgKGludGVyaW0pDQogICBtZWV0aW5ncywgYW5kIGhhcyBub3QgY2hhbmdlZCBvdmVyIHRoZSBj b3Vyc2Ugb2YgdGhlIGxhc3QgaGFsZiANCiAgIHllYXIuIA0KDQpEb2N1bWVudCBRdWFsaXR5DQoN CiAgIFRoZSBkb2N1bWVudCBpcyBhIHByb2R1Y3Qgb2YgdGhlIERSSU5LUyB3b3JraW5nIGdyb3Vw Lg0KICAgSXQgaGFzIGJlZW4gcmV2aWV3ZWQgdGhvcm91Z2hseSBieSB0aGUgcG90ZW50aWFsIHVz ZXIgDQogICBjb21tdW5pdHkgKHRlbGVjb21tdW5pY2F0aW9ucyBzZXJ2aWNlIHByb3ZpZGVycykg d2hvDQogICBhcmUgYWxzbyBkZXZlbG9waW5nIGFuIG9wZW4gc291cmNlIGltcGxtZW50YXRpb24g b2YgDQogICB0aGUgcmVzcGVjdGl2ZSBwcm90b2NvbCB0aGF0IGlzIGRyaXZlbiBieSB0aGlzIHVz ZSBjYXNlDQogICBkb2N1bWVudC4gIA0KDQoNClBlcnNvbm5lbA0KDQogICAgQWxleGFuZGVyIE1h eXJob2ZlciBpcyB0aGUgZG9jdW1lbnQgc2hlcGhlcmQgZm9yIHRoaXMgZG9jdW1lbnQuDQoNCg0K ------_=_NextPart_001_01CC56B0.2D728745-- From alexander.mayrhofer@nic.at Wed Aug 10 13:19:07 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E5811E807E for ; Wed, 10 Aug 2011 13:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.436 X-Spam-Level: X-Spam-Status: No, score=-9.436 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSkTKICBHjDZ for ; Wed, 10 Aug 2011 13:19:06 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id CDE5011E8073 for ; Wed, 10 Aug 2011 13:19:05 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47 ; Wed, 10 Aug 2011 22:19:42 +0200 Received: from nics-mail.sbg.nic.at (10.17.175.2) by NICS-EXCH.sbg.nic.at (10.17.175.3) with Microsoft SMTP Server id 14.1.218.12; Wed, 10 Aug 2011 22:19:31 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 10 Aug 2011 22:19:24 +0200 Message-ID: <8BC845943058D844ABFC73D2220D46650AB298DA@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Virtual Interim Meeting on Aug 31. Thread-Index: AcxXmL3jh1NjuJ4sTiW89Lad0knntQ== From: Alexander Mayrhofer To: X-XWALL-BCKS: auto Subject: [drinks] Virtual Interim Meeting on Aug 31. X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 20:19:07 -0000 All, the DRINKS working group will hold a Virtual Interim Meeting on=20 Wed, Aug 31 2011, from 01:00 PM - 05:00 PM Eastern Time (18:00 - 22:00 GMT) We're going to use GotoMeeting, which allows for participation either via VoIP (use Web link) or telephone (use Call-in number & access code): Link: https://www1.gotomeeting.com/join/259806864 Call-in: Dial +1 (636) 277-0134 Access Code: 259-806-864 Meeting ID: 259-806-864 Slides will be posted to the WG mailing list before the meeting, and will also be made available via the collaboration tools of GotoMeeting (Web link only). The draft agenda is as follows: DRINKS Virtual Interim Meeting Aug 2011 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Wed, Aug 31 2011, 01:00 PM - 05:00 PM (Eastern Time) 0/ Administrivia (note well, scribes) 1/ Review and resolve open items related to the following: a) protocol document (draft-ietf-drinks-spprov) b) transport document (draft-ietf-drinks-sppp-over-soap) 2/ Discuss and respond to the ITU liaison 3/ Next Steps Please let the chairs know if you wish to get a slot on the Agenda - the final version will be posted about a week before the meeting. Alex & Sumanth From alexander.mayrhofer@nic.at Thu Aug 11 13:21:54 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517DD21F8B02 for ; Thu, 11 Aug 2011 13:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.278 X-Spam-Level: X-Spam-Status: No, score=-9.278 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dj0rVN7dwTsf for ; Thu, 11 Aug 2011 13:21:53 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 338E021F8AF4 for ; Thu, 11 Aug 2011 13:21:52 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47 ; Thu, 11 Aug 2011 22:22:24 +0200 Received: from nics-mail.sbg.nic.at (10.17.175.2) by NICS-EXCH.sbg.nic.at (10.17.175.3) with Microsoft SMTP Server id 14.1.218.12; Thu, 11 Aug 2011 22:22:22 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 11 Aug 2011 22:22:16 +0200 Message-ID: <8BC845943058D844ABFC73D2220D46650AB29A3B@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DRAFT meeting minutes of DRINKS WG session @IETF81 Thread-Index: AcxYZEsu4qSp0sJ7SFuy8uHE1MsWEw== From: Alexander Mayrhofer To: X-XWALL-BCKS: auto Subject: [drinks] DRAFT meeting minutes of DRINKS WG session @IETF81 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 20:21:54 -0000 All, i've just posted draft meeting minutes for our WG session in Quebec to the Meeting Materials Tool. The minutes are available here: http://www.ietf.org/proceedings/81/minutes/drinks.txt and are also appended below. Thanks to Ken Carthwright, Syed Ali, Sumanth Channabasappa for taking notes, and Kevin Fleming for doing the jabber scribing. If you have changes or additions to the minutes, please email the WG chairs no later than Aug 20 (cutoff date for minute submission is Aug 26). These draft minutes will automatically become the final minutes if we don't receive any update requests. thanks, Alex --- snip --- Minutes of the IETF DRINKS WG meeting during IETF 81 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Date/Location: TUESDAY, July 26, 2011, 1520-1700pm Quebec City, Quebec, Canada Agenda: http://www.ietf.org/proceedings/81/agenda/drinks.txt Slides: https://datatracker.ietf.org/meeting/81/materials.html http://www.ietf.org/proceedings/81/drinks.html =20 Audio recording:=20 http://www.ietf.org/audio/ietf81/ietf81-2103-20110726-1256-pm.mp3 Meetecho recordings: http://www.meetecho.com/ietf81/recordings Mailing List archive: http://www.ietf.org/mail-archive/web/drinks/current/maillist.html WG Chairs: Sumanth Channabasappa, Alex Mayrhofer RAI ADs: Gonzalo Camarillo, Robert Sparks 1) WG Session Welcome & Administrivia (Chairs, 5m) -------------------------------------------------- Link: http://tools.ietf.org/agenda/81/slides/drinks-4.ppt=20 - Scribes were identified: Syed Ali (note taker) and Ken Cartwright (backup while Syed presents), Kevin=20 Fleming (Jabber) - Alex presented the Note Well and administrivia=20 - Agenda is presented. - Gonzalo--Notes smaller attendance and lack of activity on the list. Advises on wrapping the work. Future work shall be handled in DISPATCH. XCON and SIMPLE are examples of where WG is shutting down, and new work is being considered within DISPATCH.=20 In short, new work should probably be picked within DISPATCH.=20 2) WG Status Chairs (10m) ------------------------- Link: http://tools.ietf.org/agenda/81/slides/drinks-4.ppt - Document status of WG items - Alex provided an update regarding the three WG documents; in summary: > the use cases document will be presented for publication soon=20 > the protocol and transport document should be completed by Sep. - Protocol document: Dean submitted comments that mainly arrived from implementers. - transport document: comments from Manjul - Transport: Peter St. Andre posted WGLC comments as well. And therefore, there will definitely be updates to=20 the transport document - David asks about bringing in additional work such as building another transport based on RESTful principles. - Gonzalo clarifies that DISPATCH would be the way - David also asks brings up OpenSPPP work and addressing subsequent issues that may arise. And how closing the=20 WG may be an issue. - Gonzalo said that the list can remain open and can be used for further dialog in order to address any=20 potential issues that may arise later. - (Gonzalo) provided many options: go dormant, shutdown the WG and take new work to DISPATCH, AD-sponsored=20 changes etc. - Alex: milestones and status. 3) Protocol Document (Authors, 30m) ----------------------------------- Link: http://tools.ietf.org/agenda/81/slides/drinks-0.pptx =09 Syed speaking -- covered the protocol document. (Ken's notes) - At Draft Version 09 - Presented slide listing comments provided since the last IETF. - Presented slides listing updates that were made in response to those comments. - Identified the fact that the Security Considerations section needs improvements in the next rev. - The fact that the current spec allows the SPPP implementer to chose between a stop-and-rollback (all or=20 nothing) policy or a stop-and-commit policy (partial success). This choice will be removed and a stop-and- rollback policy will be required. (Note added Alex: This is also in-line with the requirements document (Sumanth's notes) - He covered the comments received during WGLC (mostly from Dean Willis) and the resolutions; main issues and=20 resolutions: > Security requirements and considerations need more clarification (e.g., authentication v/s authorization) - Some clarifications have been provided > Guidance regarding the transport protocol - Proposed mandatory SOAP-based transport > Questions around IANA registry=20 - Decided against it > Clarifications around the use of Time - Specified the use of UTC > Editorial updates - Completed =20 - Next steps > Clean-up security requirements and considerations - No comments > Clarify the way commands are handled; specifically mandate atomicity of operations - WG Chairs asked if there were any objections; none were noted. =20 - Next Steps > Present an update with the remaining items in the next couple of weeks.=20 > The authors in the room agreed to this, based on a question from Sumanth (as the WG Chair) =20 4) Transport Document (Author, 10m) ----------------------------------- Ken -- presenting. - acknowledge Manjul for the comments provided. - identified the issues and the changes to the transport document since last IETF meeting - identified the comments from Peter St. Andrae. Acknowledges that these need to be addressed - Next Steps > Present an update with the remaining items in the next couple of weeks=20 > The authors in the room agreed to this, based on a question from Sumanth (as the WG Chair) =20 5) Open source project (project participants, 10m) -------------------------------------------------- Link: http://tools.ietf.org/agenda/81/slides/drinks-1.pdf=20 Dean providing overview for OpenSPP - mission statement; statement update and other project level updates. - David mentions the need for re-use of the same data model for building other server components, such as,=20 resolution server or distro server - Ken interested in feedback as to whether the existing response codes are sufficient or not - Dean noted that more situations were discovered during the implementation that could use more specific=20 response codes - Dean plans to the bring together developers and protocol contributors to give formal feedback on lessons=20 learned. - Dean extends comment from Jeremy: Validation of messaging data in the database is not sufficient in the=20 spec--(Syed: points to perhaps too much flexibility in the protocol) - Dean notes; that the implementers didn't have to, but they focused on the scalability concerns as well. What=20 was built is in fact scalable to host millions of queries. Gives credits to Jeremy and Vijay for the work. - (David) raised the question around Slide 6. His take was that the tight coupling of data models with SOAP=20 and XSD makes it hard for implementations to separate the data model from the protocol, especially when there=20 are future uses within lookup and distribution. > There were some discussions around this; with Ken clarifying that the data models in the document are not=20 the same that should be used for lookup and=20 - (Jeremy) the draft did not give sufficient data definition for validation of message and database data =20 6) Discussion around the possible need for a distribution protocol (Draft Authors, 10m) ------------------------------------------------------------------------ --------------- Link: http://www.ietf.org/id/draft-schwartz-drinks-spdist-00.txt - David is coming to present the SPDP protocol slides. - Slide 1: Is the SPDP needed. (Note: Towards the beginning of the session Gonzalo indicated that the question=20 is open and this work may have to go to DISPATCH) - Use case 1: Local server; SPPP doesn't claim to provide provisioning support from Registry to the Local=20 Server - Use case 2: Bulk data distro from registry to remote local data repo instead of incremental updates, the=20 updates are sent in bulk not triggered by each individual change - Use Case 3: incremental view update, slice of the full set and only the selected slice Switched away to a different slide deck. - Namespace: Local server get update from multiple registry - Incremental data=20 - Optimize bulk distro of data - Notion of versioning - Consistency across repos may be required - Data distrib - pull vs push; sync vs async; what if local repo is unavailable - Data Partitioning: segment the data so it is distributed as a whole across a set of servers - Next steps; DRINKS to address SPDP?; describe the relevant use cases; gain consensus before moving forward - hopes there can be an active dialog on this issue in the list before the next IETF. - mentions that people are asking for use of DNS protocol today=20 since there is no other mechanism available. There is a strong=20 need in this domain for a distribution protocol. - Alex: Notes that there are many different issues identified in the slides; operational + arch - David: Describes how the section of a number space cannot be obtained today in a DNS repl mech which is all=20 or none. - David: commits to putting out a more detailed document before next IETF meeting. - David notes that he has submitted the individual draft and encourages everyone to follow up on it. - David notes that he is using custom solutions to accomplish this today. SPDP is a need in the domain where ENUM is used for resolution. And the first repl solution happens to be=20 IXFR/AXFR, which is the wrong tool - Jon: Advises that he need to clarify the problem space and why the current mechanisms are insufficient - Shockey; agrees to Jon's assessment and notes that a step by step reasoning why DNS repl is broken will go a=20 long way. - When will this be done? - Need volunteers=20 - Standardized data sets over a SOAP UI - (David) will get a few more students =20 IXFR sucks for this purpose (Jon) You need to document this. (Rich) Share this with the DNS=20 - Discuss this on the mailing list - Bring it to DISPATCH in Taipei 7) Next Steps (15m) ------------------- - Shockey; we need to reserve a field within the protocol (David; we did) that can be used for global SPN=20 identification. - Alex; confirms that gSPID work will not happen in DRINKS. - Shockey; agrees. Area Directors wants the work to go on in the DISPATCH and follow up on the DISPATCH list. - Sumanth; repeats the directives to followup on the DISPATCH - Alex; Notes couple of issues in the sppp doc; and that transport doc needs to be fixed as well. - David; confirms that additional work like the REST api will have to be taken to the DISPATCH - Sumanth; confirms; it can be considered new work or DRINKS go dormant while the REST work continues. - Alex: at least 10 people signing up for the work will be needed to keep it open. Or else, the group will=20 have to be closed. - Sumanth; hum on publication of the use case document. ***No objections from attendees*** - Sumanth: Identifies a need for a virtual meeting to completing the protocol work. 5 people showed interest. - Sumanth: Notes that there will be update to the transport document as well. And that there will be a quick=20 last call for both sppp and transport document. - Sumanth: notes updates shall happen within two weeks. - Upcoming work? - The only work so far has been the one suggested by David - Related work (e.g., Global SPID)? (Rich) There is a liaison from ITU that is still valid.=20 (David) We did. =20 (Alex) What are the next steps? (Rich) This should continue on the DISPATCH list (individually submission or AD-sponsored I-D).=20 - WG shutdown before Taipei possible? - Asking for any final comments, discussions, etc. Session closes -------------- From internet-drafts@ietf.org Fri Aug 12 14:37:45 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C976621F8A35; Fri, 12 Aug 2011 14:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJspE0ftvL2v; Fri, 12 Aug 2011 14:37:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6350521F88B6; Fri, 12 Aug 2011 14:37:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110812213745.9378.11112.idtracker@ietfa.amsl.com> Date: Fri, 12 Aug 2011 14:37:45 -0700 Cc: drinks@ietf.org Subject: [drinks] I-D Action: draft-ietf-drinks-usecases-requirements-06.txt X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 21:37:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Data for Reachability of Inter/tra-Ne= tworK SIP Working Group of the IETF. Title : Data for Reachability of Inter/tra-NetworK SIP (DRINKS) = Use cases and Protocol Requirements Author(s) : Sumanth Channabasappa Filename : draft-ietf-drinks-usecases-requirements-06.txt Pages : 24 Date : 2011-08-12 This document captures the use cases and associated requirements for interfaces that provision session establishment data into Session Initiation Protocol (SIP) Service Provider components, to assist with session routing. Specifically, this document focuses on the provisioning of one such element, termed the registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-drinks-usecases-requirements= -06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-drinks-usecases-requirements-= 06.txt From dean.willis@softarmor.com Tue Aug 16 15:29:24 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEA021F874B for ; Tue, 16 Aug 2011 15:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.232 X-Spam-Level: X-Spam-Status: No, score=-103.232 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5JlIUntmjeK for ; Tue, 16 Aug 2011 15:29:24 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 046BC21F875E for ; Tue, 16 Aug 2011 15:29:23 -0700 (PDT) Received: by yxp4 with SMTP id 4so335745yxp.31 for ; Tue, 16 Aug 2011 15:30:13 -0700 (PDT) Received: by 10.236.78.202 with SMTP id g50mr944329yhe.130.1313533813214; Tue, 16 Aug 2011 15:30:13 -0700 (PDT) Received: from [192.168.2.143] (cpe-66-25-15-110.tx.res.rr.com [66.25.15.110]) by mx.google.com with ESMTPS id f4sm223170yhn.83.2011.08.16.15.30.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Aug 2011 15:30:12 -0700 (PDT) Content-Transfer-Encoding: quoted-printable From: Dean Willis Content-Type: text/plain; charset=us-ascii Message-Id: <52959D5F-D4DC-455C-B152-7A6195D6F6D8@softarmor.com> Date: Tue, 16 Aug 2011 17:30:11 -0500 To: drinks@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: openspp-team@lists.sourceforge.net Subject: [drinks] Questions about spprov-9 6.2 GetDestGrpsRqst X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 22:29:24 -0000 =09 =46rom the text: 6.2. Get Destination Groups Operation The getDestGrpsRqst operation allows an SPPP client to get the properties of Destination Group objects that a registrar is authorized to view on behalf of the registrant. The server will attempt to find a Destination Group object that has the registrant ID and destination group name pair contained in each ObjKeyType object instance. If there are no matching Destination Groups found then an empty result set will be returned. If no ObjKeyType objects are found in the request then the server will return the list of all Destination Group objects in the registry. If no matching records can be located then an empty result set will be returned. 1) The first line of the para refers to "getDestGrpsRqst", but the XML = schema has it as "GetDestGrpsRqst". Which is right? The OpenSPP = implementation goes with the schema right now. 2) I (and our server implementation) seem to find the "If no ObjKeyType = objects are found in the request then the server will return the list of = all Destination Group objects in the registry" part confusing. The auth model is based on the Registrant ID, aka "rant". But ObjKeyType = holds "rant" and "name". So if there's no objKey, we don't know which = registrant to look for. Note that earlier text says "that a registrar = is authorized to view on the behalf of the registrant". So, where's = there's no specified registrant, which records is the registrar entitled = to see? I suspect the answer is "It's outside of the protocol specification", = which I find unsatisfying. Right now, OpenSPP returns a null list of = there's no objKey in the request. And frankly, we've got no auth model, = and pretty much assume anybody can see anything. But if we were = authenticating requester against the request's rant, we still wouldn't = know how to respond to a null query. 3) Note that I find the whole "registrar" thing confusing. Can't we just = say "client"? You don't KNOW that the thing making SOAP calls is a = registrar. It might be, for example, a maintenance tool used by a sysop. = But you do know it's a client...= From sumanth@cablelabs.com Tue Aug 16 15:53:24 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02DE21F8B4F for ; Tue, 16 Aug 2011 15:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.38 X-Spam-Level: X-Spam-Status: No, score=-0.38 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyAJg4M4RcID for ; Tue, 16 Aug 2011 15:53:24 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 311E321F8B6B for ; Tue, 16 Aug 2011 15:53:21 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id p7GMs9fY005010 for ; Tue, 16 Aug 2011 16:54:09 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Tue, 16 Aug 2011 16:54:09 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 16 Aug 2011 16:54:09 -0600 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Tue, 16 Aug 2011 16:54:07 -0600 Thread-Topic: Rough Notes and AI list from the call on 8/11 Thread-Index: AcxcZ2E9uHJwDyQzQn6tSiEtUjxjcw== Message-ID: <76AC5FEF83F1E64491446437EA81A61F81908053B2@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] Rough Notes and AI list from the call on 8/11 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 22:53:24 -0000 IETF DRINKS DESIGN TEAM CALL=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D 8/11/2011, 10:00a-10:30a (Eastern)/8:00a-8:30a (Mountain) =20 Participants =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Ken Cartwright - Syed Ali - Sumanth Channabasappa=20 ACTION ITEMS=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [Syed, 8/15] Take a first pass at updates to the protocol document [Ken, 8/19] Complete remaining updates to the transport document [Sumanth] Check with Dean Willis and the OpenSPPP implementors if they have= any issues or questions to report AGENDA =3D=3D=3D=3D=3D=3D 1. General Updates related to the WG documents 2. Next Steps NOTES =3D=3D=3D=3D=3D 1. General Updates related to the WG documents + Use Cases and Requirements - [Sumanth] indicated that the use cases and reqs document will be updat= ed this week and requested members to provide any final comments. + Protocol Document - [Sumanth] requested authors to discuss and complete the remaining upda= tes prior to the interim meeting scheduled for Aug 31st. - We discussed the remaining open items, which are: > Tighten security considerations and requirements=20 > Include data validation requirements > Any feedback from the OpenSPPP implementors - Syed volunteered to take a stab at the first set of changes + Transport Document - [Ken] indicated that plans to complete the remaining updates (as indic= ated at the DRINKS WG meeting in Quebec) in the next week =20 2. Next Steps - Ask for publication of the use cases and reqs document - Complete updates to the protocol and transport document, with a goal o= f reviewing and completing them (unless there are issues) at the interim me= eting on 8/31 From kcartwright@tnsi.com Fri Aug 19 14:20:27 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 748DF21F8BB2 for ; Fri, 19 Aug 2011 14:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHMvlnvtzMIi for ; Fri, 19 Aug 2011 14:20:25 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 13C9D21F8BAB for ; Fri, 19 Aug 2011 14:20:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsUAAHvSTk6sEQfn/2dsb2JhbAA4CZgtkFgZgScBAQEBAwEBARdRAxcEAgEIEQQBASgHAiULFAkIAQEEEwgGh2epII9XgyiCQV8EnQqHGg X-IronPort-AV: E=Sophos;i="4.68,252,1312153200"; d="xml'217?scan'217,208,217";a="121468" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 19 Aug 2011 22:21:16 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Fri, 19 Aug 2011 17:21:16 -0400 From: "Cartwright, Ken" To: "drinks@ietf.org" Date: Fri, 19 Aug 2011 17:21:16 -0400 Thread-Topic: [drinks] review of draft-ietf-drinks-sppp-over-soap-04 Thread-Index: AcxHL7hYeVR4uLhzTQGn4wmKqZXE9wXfKjgQ Message-ID: <754963199212404AB8E9CFCA6C3D0CDA38DDA5DD43@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4E275C25.1050105@stpeter.im> In-Reply-To: <4E275C25.1050105@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_754963199212404AB8E9CFCA6C3D0CDA38DDA5DD43TNSMAILNAwin2_" MIME-Version: 1.0 Subject: Re: [drinks] review of draft-ietf-drinks-sppp-over-soap-04 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 21:20:27 -0000 --_002_754963199212404AB8E9CFCA6C3D0CDA38DDA5DD43TNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've incorporated the updates listed below, that address the points made by= Peter. The remaining task is to incorporate some SOAP message examples, a= s suggested by Ning. I will do that on Tuesday (I'm out on Monday). Ken 1. Clarified that sentence and others. 2. Changed the approach of other IETF RFCs that use WSDL (e.g. 4743) to re= fer to this reference as informative rather than normative. 3. Updated the wording in the Transport Security section to make it clear = the intent is to use HTTPS for integrity and privacy. Also added a referen= ce to 2818 later in the document. 4. The WSDL name space definition and the target namespace specifications = are correct as they stand. 5. Added to the wording of the Security Considerations section to refer to= the practice of using certificate exchange/verification to perform server = authentication, and referred to 2818. 6. Added some more verbiage to the "Environment Specific Considerations se= ction and removed the use of the overloaded word "may". 7. It is not clear to me that we really _need_ anything else in the IANA s= ection. So I left that as it stands. 8. Added a sentence about SOAP faults that could, theoretically, be genera= ted by the chosen SOAP library, but that do not relate to SPPP. However, t= his is a subject that does not directly relate to SPPP. So I did not get t= oo verbose on this subject. -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Peter Saint-Andre Sent: Wednesday, July 20, 2011 6:52 PM To: drinks@ietf.org Subject: [drinks] review of draft-ietf-drinks-sppp-over-soap-04 I've been asked to take a look at draft-ietf-drinks-sppp-over-soap. Overall I think it is in fine shape. Here are a few comments. 1. The document needs to be edited for clarity. For example, some of the sentences don't parse (e.g., the third sentence of Section 1). 2. There's a normative reference to W3C Note NOTE-wsdl-20010315, which says "This document is a NOTE made available by the W3C for discussion only. Publication of this Note by W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members. W3C has had no editorial control over the preparation of this Note. This document is a work in progress and may be updated, replaced, or rendered obsolete by other documents at any time." Thus the phrase "WSDL is a widely standardized and adopted technology" in this I-D is not accurate, at least with regard to standarization. Furthermore, no published RFCs contain a normative reference to the WSDL document, which also is not in the downref registry. This will need to be called out during IETF Last Call. 3. Section 3 states "SOAP faults are not used by the SPPP SOAP mapping." It would be good to define how an application is supposed to handle SOAP faults if they occur for other reasons, or reference the SOAP specification on this point. 4. Transport security is a bit unclear to me. The spec says: All SOAP and HTTP SPPP Clients and Servers MUST support Transport Layer Security (TLS) as defined in [RFC5246] as the secure transport mechanism. Does that mean supporting HTTP Over TLS (RFC 2818) except using the most up-to-date version of TLS, or using TLS directly over TCP? 5. I am not a WSDL expert, but the definition looks fine to me (even if hard to read). This seems a bit odd: xmlns:sppps=3D"urn:ietf:params:xml:ns:sppp:soap:1" targetNamespace=3D"urn:ietf:params:xml:ns:sppp:soap:1" Why define the same namespace in two ways? 6. Section 7 says "The identity of the server should also be authenticated by the client." However, no guidance is provided about how to do that. A reference to RFC 2818 seems necessary. 7. Section 7.3 states: Some deployments of SPPP over SOAP may choose to use transports without encryption. This presents vulnerabilities but may be selected for deployments involving closed networks or debugging scenarios. Do you mean "MAY"? Is encryption truly optional? Please clarify that you mean MUST-implement and SHOULD-deploy or somesuch (where your "may" here really means "here's why a deployment might have a good reason to violate the SHOULD-deploy"). 8. The IANA considerations seem a bit thin. Please see RFC 3688 for the template. I know there are a few examples in Section 14 of RFC 6120, so feel free to borrow from there. :) Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_002_754963199212404AB8E9CFCA6C3D0CDA38DDA5DD43TNSMAILNAwin2_ Content-Type: text/xml; name="draft-ietf-drinks-sppp-over-soap-05.xml" Content-Description: draft-ietf-drinks-sppp-over-soap-05.xml Content-Disposition: attachment; filename="draft-ietf-drinks-sppp-over-soap-05.xml"; size=22826; creation-date="Fri, 19 Aug 2011 16:15:30 GMT"; modification-date="Fri, 19 Aug 2011 17:20:44 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4KCjwhRE9DVFlQRSByZmMgU1lT VEVNICJyZmMyNjI5LmR0ZCIgWwogICAgICAgIDwhRU5USVRZIHJmYzIxMTkgUFVCTElDICIiCiAg ICAgICAgICAiaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJl bmNlLlJGQy4yMTE5LnhtbCI+CiAgICAgICAgPCFFTlRJVFkgcmZjMzY4OCBQVUJMSUMgIiIKICAg ICAgICAgICJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVu Y2UuUkZDLjM2ODgueG1sIj4KICAgICAgICA8IUVOVElUWSByZmM1NDg2IFBVQkxJQyAiIgogICAg ICAgICAgImh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5j ZS5SRkMuNTQ4Ni54bWwiPgogICAgICAgICA8IUVOVElUWSByZmM1MjQ2IFBVQkxJQyAiIgogICAg ICAgICAgImh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5j ZS5SRkMuNTI0Ni54bWwiPgogICAgICAgIDwhRU5USVRZIHJmYzI2MTcgUFVCTElDICIiCiAgICAg ICAgICAiaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNl LlJGQy4yNjE3LnhtbCI+CiAgICAgICAgPCFFTlRJVFkgcmZjMjYxNiBQVUJMSUMgIiIKICAgICAg ICAgICJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2Uu UkZDLjI2MTYueG1sIj4KCl0+CgoKPHJmYyBjYXRlZ29yeT0ic3RkIiBkb2NOYW1lPSJkcmFmdC1p ZXRmLWRyaW5rcy1zcHBwLW92ZXItc29hcC0wNSIgIGlwcj0idHJ1c3QyMDA5MDIiPgoKPD94bWwt c3R5bGVzaGVldCB0eXBlPSd0ZXh0L3hzbCcgaHJlZj0ncmZjMjYyOS54c2x0JyA/PgoKPD9yZmMg dG9jPSJ5ZXMiID8+Cjw/cmZjIHN5bXJlZnM9InllcyIgPz4KPD9yZmMgc29ydHJlZnM9InllcyI/ Pgo8P3JmYyBpcHJub3RpZmllZD0ibm8iID8+Cjw/cmZjIHN0cmljdD0ieWVzIiA/PgoKPGZyb250 PgogICAgICAgIDx0aXRsZSBhYmJyZXY9ImRyYWZ0LWlldGYtZHJpbmtzLXNwcHAtb3Zlci1zb2Fw Ij5TUFBQIE92ZXIgU09BUCBhbmQgSFRUUDwvdGl0bGU+CgogICAgICAgIDxhdXRob3IgaW5pdGlh bHM9J0suQy4nIHN1cm5hbWU9IkNhcnR3cmlnaHQiIGZ1bGxuYW1lPSdLZW5uZXRoIENhcnR3cmln aHQnPgogICAgICAgICAgICAgICAgPG9yZ2FuaXphdGlvbj5UTlM8L29yZ2FuaXphdGlvbj4KICAg ICAgICAgICAgICAgIDxhZGRyZXNzPgogICAgICAgICAgICAgICAgICAgICAgICA8cG9zdGFsPgog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxzdHJlZXQ+MTkzOSBSb2xhbmQgQ2xhcmtl IFBsYWNlPC9zdHJlZXQ+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGNpdHk+UmVz dG9uPC9jaXR5PiA8cmVnaW9uPlZBPC9yZWdpb24+IAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDxjb2RlPjIwMTkxPC9jb2RlPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDxjb3VudHJ5PlVTQTwvY291bnRyeT4KICAgICAgICAgICAgICAgICAgICAgICAgPC9wb3N0YWw+ CiAgICAgICAgICAgICAgICAgICAgICAgIDxlbWFpbD5rY2FydHdyaWdodEB0bnNpLmNvbTwvZW1h aWw+CiAgICAgICAgICAgICAgICA8L2FkZHJlc3M+CiAgICAgICAgPC9hdXRob3I+CgogICAgICAg IDxkYXRlIHllYXI9IjIwMTEiIG1vbnRoPSJBdWd1c3QiLz4KCiAgICA8YXJlYT5SZWFsLXRpbWUg QXBwbGljYXRpb25zIGFuZCBJbmZyYXN0cnVjdHVyZSBBcmVhPC9hcmVhPgoKICAgIDx3b3JrZ3Jv dXA+RFJJTktTPC93b3JrZ3JvdXA+CiAgICAKICAgIDxhYnN0cmFjdD4KICAgICAgPHQ+VGhlIFNl c3Npb24gUGVlcmluZyBQcm92aXNpb25pbmcgUHJvdG9jb2wgKFNQUFApIGlzIGFuIFhNTCBwcm90 b2NvbCAKCSAgdGhhdCBleGlzdHMgdG8gZW5hYmxlIHRoZSBwcm92aXNpb25pbmcgb2Ygc2Vzc2lv biBlc3RhYmxpc2htZW50IGRhdGEgaW50byAgCgkgIFNlc3Npb24gRGF0YSBSZWdpc3RyaWVzIG9y IFNJUCBTZXJ2aWNlIFByb3ZpZGVyIGRhdGEgc3RvcmVzLiAgU2VuZGluZyBYTUwgCgkgIGRhdGEg c3RydWN0dXJlcyBvdmVyIFNpbXBsZSBPYmplY3QgQWNjZXNzIFByb3RvY29sIChTT0FQKSBhbmQg SFRUUChzKSBpcyAKCSAgYSB3aWRlbHkgdXNlZCwgZGUtZmFjdG8gc3RhbmRhcmQgZm9yIG1lc3Nh Z2luZyBiZXR3ZWVuIGVsZW1lbnRzIG9mIAoJICBwcm92aXNpb25pbmcgc3lzdGVtcy4gIFRoZXJl Zm9yZSB0aGUgY29tYmluYXRpb24gb2YgU09BUCBhbmQgSFRUUChzKSBhcyAKCSAgYSB0cmFuc3Bv cnQgZm9yIFNQUFAgaXMgYSBuYXR1cmFsIGZpdC4gIFRoZSBvYnZpb3VzIGJlbmVmaXRzIGluY2x1 ZGUgCgkgIGxldmVyYWdpbmcgZXhpc3RpbmcgaW5kdXN0cnkgZXhwZXJ0aXNlLCBsZXZlcmFnaW5n IGV4aXN0aW5nIHN0YW5kYXJkcywgCgkgIGFuZCBhIGhpZ2hlciBwcm9iYWJpbGl0eSB0aGF0IGV4 aXN0aW5nIHByb3Zpc2lvbmluZyBzeXN0ZW1zIGNhbiBiZSBtb3JlIAoJICBlYXNpbHkgaW50ZWdy YXRlZCB3aXRoIHRoaXMgcHJvdG9jb2wuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgCgkg IHNwZWNpZmljYXRpb24gZm9yIHRyYW5zcG9ydGluZyBTUFBQIFhNTCBzdHJ1Y3R1cmVzIG92ZXIg U09BUCBhbmQgSFRUUChzKS4KCSAgPC90PgogICAgPC9hYnN0cmFjdD4KICA8L2Zyb250PgoKICA8 bWlkZGxlPgogICAgPHNlY3Rpb24gdGl0bGU9IkludHJvZHVjdGlvbiI+CiAgICAgIDx0PlNQUFAs IGRlZmluZWQgaW4gPHhyZWYgdGFyZ2V0PSJJLUQuZHJhZnQtaWV0Zi1kcmlua3Mtc3Bwcm92Ii8+ LAogICAgICBpcyBiZXN0IHN1cHBvcnRlZCBieSBhIHRyYW5zcG9ydCBhbmQgbWVzc2FnaW5nIGlu ZnJhc3RydWN0dXJlIAoJICB0aGF0IGlzIGNvbm5lY3Rpb24gb3JpZW50ZWQsIHJlcXVlc3QtcmVz cG9uc2Ugb3JpZW50ZWQsIGVhc2lseSBzZWN1cmVkLCAKCSAgc3VwcG9ydHMgcHJvcGFnYXRpb24g dGhyb3VnaCBmaXJld2FsbHMgaW4gYSBzdGFuZGFyZCBmYXNoaW9uLCBhbmQgdGhhdCAKCSAgaXMg ZWFzaWx5IGludGVncmF0ZWQgaW50byBiYWNrLW9mZmljZSBzeXN0ZW1zLiAgVGhpcyBpcyBkdWUg dG8gdGhlIGZhY3QgdGhhdCAKCSAgdGhlIGNsaWVudCBzaWRlIG9mIFNQUFAgaXMgbGlrZWx5IHRv IGJlIGludGVncmF0ZWQgd2l0aCBvcmdhbml6YXRpb25zJyAKCSAgb3BlcmF0aW9uYWwgc3VwcG9y dCBzeXN0ZW1zIHRoYXQgZmFjaWxpdGF0ZSB0cmFuc2FjdGlvbmFsIHByb3Zpc2lvbmluZyBvZiB1 c2VyICAKCSAgYWRkcmVzc2VzIGFuZCB0aGVpciBhc3NvY2lhdGVkIHNlc3Npb24gZXN0YWJsaXNo bWVudCBkYXRhLiAgV2hpbGUgdGhlIHNlcnZlciAgCgkgIHNpZGUgb2YgU1BQUCBpcyBsaWtlbHkg dG8gcmVzaWRlIGluIGEgc2VwYXJhdGUgb3JnYW5pemF0aW9uJ3MgbmV0d29yaywgcmVzdWx0aW5n ICAKCSAgdGhlIFNQUFAgcHJvdmlzaW9uaW5nIHRyYW5zYWN0aW9ucyB0cmF2ZXJzaW5nIHRoZSBJ bnRlcm5ldCBhcyAKCSAgdGhleSBhcmUgcHJvcGFnYXRlZCBmcm9tIHRoZSBTUFBQIGNsaWVudCB0 byB0aGUgU1BQUCBzZXJ2ZXIuICBHaXZlbiB0aGUgCgkgIGN1cnJlbnQgc3RhdGUgb2YgaW5kdXN0 cnkgcHJhY3RpY2UgYW5kIHRlY2hub2xvZ2llcywgCgkgIFNPQVAgYW5kIEhUVFAocykgYXJlIHdl bGwgc3VpdGVkIGZvciB0aGlzIHR5cGUgb2YgZW52aXJvbm1lbnQuIFRoaXMgZG9jdW1lbnQgCgkg IGRlc2NyaWJlcyB0aGUgc3BlY2lmaWNhdGlvbiBmb3IgdHJhbnNwb3J0aW5nIFNQUFAgWE1MIHN0 cnVjdHVyZXMgb3ZlciAKCSAgU09BUCBhbmQgSFRUUChzKS48L3Q+CiAgICAgIDx0PlRoZSBzcGVj aWZpY2F0aW9uIGluIHRoaXMgZG9jdW1lbnQgZm9yIHRyYW5zcG9ydGluZyBTUFBQIFhNTCBzdHJ1 Y3R1cmVzIAoJICBvdmVyIFNPQVAgYW5kIEhUVFAocykgaXMgcHJpbWFyaWx5IGNvbXByaXNlZCBv ZiBmaXZlIHN1YmplY3RzOiAgKDEpIGEgCgkgIGRlc2NyaXB0aW9uIG9mIGFueSBhcHBsaWNhYmxl IFNPQVAgZmVhdHVyZXMsICgyKSBhbnkgYXBwbGljYWJsZSBIVFRQIAoJICBmZWF0dXJlcywgKDMp IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLCBhbmQgcGVyaGFwcyBtb3N0IGltcG9ydGFudGx5LCAK CSAgKDUpIHRoZSBXZWIgU2VydmljZXMgRGVzY3JpcHRpb24gTGFuZ3VhZ2UgKFdTREwpIGRlZmlu aXRpb24gZm9yIFNQUFAgb3ZlciAKCSAgU09BUC48L3Q+Cgk8L3NlY3Rpb24+CiAgCiAgICA8c2Vj dGlvbiBhbmNob3I9IlRlcm1pbm9sb2d5IiB0aXRsZT0iVGVybWlub2xvZ3kiPgogICAgICA8dD5U aGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNI QUxMIE5PVCIsCiAgICAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJN QVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzCiAgICAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRl cnByZXRlZCBhcyBkZXNjcmliZWQgaW4gPHhyZWYgdGFyZ2V0PSJSRkMyMTE5Ii8+LjwvdD4KICAg IDwvc2VjdGlvbj4KCiAgICA8c2VjdGlvbiBhbmNob3I9IlNPQVBGZWF0dXJlcyIgdGl0bGU9IlNP QVAgRmVhdHVyZXMgYW5kIFNQUFAiPgogICAgICA8dD5UaGUgbGlzdCBvZiBTT0FQIGZlYXR1cmVz IHRoYXQgYXJlIGV4cGxpY2l0bHkgdXNlZCBhbmQgcmVxdWlyZWQgZm9yIFNQUFAgYXJlIGxpbWl0 ZWQuICBNb3N0IFNPQVAgZmVhdHVyZXMgYXJlIG5vdCBuZWNlc3NhcnkgZm9yIFNQUFAuICBTUFBQ IHByaW1hcmlseSB1c2VzIFNPQVAgc2ltcGx5IGFzIGEgc3RhbmRhcmQgbWVzc2FnZSBlbnZlbG9w ZSB0ZWNobm9sb2d5LiAgVGhlIFNPQVAgbWVzc2FnZSBlbnZlbG9wZSBpcyBjb21wcmlzZWQgb2Yg dGhlIFNPQVAgaGVhZGVyIGFuZCBib2R5LiAgQXMgZGVzY3JpYmVkIGluIHRoZSBTT0FQIHNwZWNp ZmljYXRpb25zLCB0aGUgU09BUCBoZWFkZXIgY2FuIGNvbnRhaW4gb3B0aW9uYWwsIGFwcGxpY2F0 aW9uIHNwZWNpZmljLCBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbWVzc2FnZS4gIFRoZSBTT0FQIGJv ZHkgY29udGFpbnMgdGhlIFNQUFAgbWVzc2FnZSBpdHNlbGYsIHdob3NlIHN0cnVjdHVyZSBpcyBk ZWZpbmVkIGJ5IHRoZSBjb21iaW5hdGlvbiBvZiBvbmUgb2YgdGhlIFdTREwgb3BlcmF0aW9ucyBk ZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgYW5kIHRoZSBTUFBQIFhNTCBkYXRhIHN0cnVjdHVyZXMg ZGVmaW5lZCBpbiB0aGUgU1BQUCBwcm90b2NvbCBkb2N1bWVudC4gIFNQUFAgZG9lcyBub3QgcmVs eSBvbiBhbnkgZGF0YSBlbGVtZW50cyBpbiB0aGUgU09BUCBoZWFkZXIuICBBbGwgcmVsZXZhbnQg ZGF0YSBlbGVtZW50cyBhcmUgZGVmaW5lZCBpbiB0aGUgU1BQUCBYTUwgc2NoZW1hIGRlc2NyaWJl ZCBpbiA8eHJlZiB0YXJnZXQ9IkktRC5kcmFmdC1pZXRmLWRyaW5rcy1zcHByb3YiLz4gYW5kIHRo ZSBTUFBQIFdTREwgc3BlY2lmaWNhdGlvbiBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudC48L3Q+ CgkgIDx0PldTREwgaXMgYSB3aWRlbHkgc3RhbmRhcmRpemVkIGFuZCBhZG9wdGVkIHRlY2hub2xv Z3kgZm9yIGRlZmluaW5nIHRoZSB0b3AtbGV2ZWwgc3RydWN0dXJlcyBvZiB0aGUgbWVzc2FnZXMg dGhhdCBhcmUgdHJhbnNwb3J0ZWQgd2l0aGluIHRoZSBib2R5IG9mIGEgU09BUCBtZXNzYWdlLiAg VGhlIFdTREwgZGVmaW5pdGlvbiBmb3IgdGhlIFNQUFAgU09BUCBtZXNzYWdlcyBpcyBkZWZpbmVk IGxhdGVyIGluIHRoaXMgZG9jdW1lbnQsIHdoaWNoIGltcG9ydHMgYnkgcmVmZXJlbmNlIHRoZSBY TUwgZGF0YSB0eXBlcyBjb250YWluZWQgaW4gdGhlIFNQUFAgc2NoZW1hLiAgVGhlIElBTkEgcmVn aXN0cnkgd2hlcmUgdGhlIFNQUFAgc2NoZW1hIHJlc2lkZXMgaXMgZGVzY3JpYmVkIGluIFRoZSBJ RVRGIFhNTCBSZWdpc3RyeSA8eHJlZiB0YXJnZXQ9IlJGQzM2ODgiLz4uPC90PgoJICA8dD5UaGVy ZSBhcmUgbXVsdGlwbGUgc3RydWN0dXJhbCBzdHlsZXMgdGhhdCBTT0FQIFdTREwgYWxsb3dzLiAg QnV0IHRoZSBiZXN0IHByYWN0aWNlIGZvciB0aGlzIHR5cGUgb2YgYXBwbGljYXRpb24gaXMgd2hh dCBpcyBzb21ldGltZXMgcmVmZXJyZWQgdG8gYXMgdGhlIERvY3VtZW50IExpdGVyYWwgV3JhcHBl ZCBzdHlsZSBvZiBkZXNpZ25pbmcgU09BUCBXU0RMLiAgVGhpcyBzdHlsZSBpcyBnZW5lcmFsbHkg cmVnYXJkZWQgYXMgYW4gb3B0aW1hbCBhcHByb2FjaCB0aGF0IGVuaGFuY2VzIG1haW50YWluYWJp bGl0eSwgY29tcHJlaGVuc2lvbiwgcG9ydGFiaWxpdHksIGFuZCwgdG8gYSBjZXJ0YWluIGV4dGVu dCwgcGVyZm9ybWFuY2UuICBJdCBpcyBjaGFyYWN0ZXJpemVkIGJ5IHNldHRpbmcgdGhlIHNvYXBB Y3Rpb24gYmluZGluZyBzdHlsZSBhcyBfZG9jdW1lbnRfLCB0aGUgc29hcEFjdGlvbiBlbmNvZGlu ZyBzdHlsZSBhcyBfbGl0ZXJhbF8sIGFuZCB0aGVuIGRlZmluaW5nIHRoZSBTT0FQIG1lc3NhZ2Vz IHRvIHNpbXBseSBjb250YWluIGEgc2luZ2xlIGRhdGEgZWxlbWVudCB0aGF0IF93cmFwc18gdGhh dCBpcyBhIGRhdGEgc3RydWN0dXJlIGNvbnRhaW5pbmcgYWxsIHRoZSByZXF1aXJlZCBpbnB1dCBv ciBvdXRwdXQgZGF0YSBlbGVtZW50cy4gVGhlIGZpZ3VyZSBiZWxvdyBpbGx1c3RyYXRlcyB0aGlz IGhpZ2ggbGV2ZWwgdGVjaG5pY2FsIHN0cnVjdHVyZS48L3Q+CgkgIAoJIDxmaWd1cmUgYW5jaG9y PSJUZWNobmljYWxTdHJ1Y3R1cmVvZlNQUFAiIAoJIHRpdGxlPSJUZWNobmljYWwgU3RydWN0dXJl IG9mIHRoZSBTUFBQIFNPQVAgTWVzc2FnZXMiPgogICAgICAgIDxhcnR3b3JrIGFsaWduPSJsZWZ0 Ij48IVtDREFUQVsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0t LS0rCiAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS18ICAgIFNPQVAgICAgICAgfC0tLS0t LSsKICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHwgIE9wZXJhdGlvbiAgICB8ICAgICAg fAogICAgICAgICAgICAgIENvbnRhaW5zIHwgICAgICArLS0tLS0tLS0tLS0tLS0tLSsgICAgICB8 IENvbnRhaW5zCiAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICBFeGFtcGxlOiAgICAg ICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICBWICAgICAgc3VibWl0VXBkYXRlUnFzdCAg ICAgICAgVgogICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICArLS0tLS0t LS0tLS0tLSsKICAgICAgICAgICAgICAgfFNPQVAgUmVxdWVzdCAgfCAgICAgICAgICAgfFNPQVAg UmVzcG9uc2V8CiAgICAgICBFeGFtcGxlOnwgIE1lc3NhZ2UgICAgIHwgICAgICAgICAgIHwgICBN ZXNzYWdlICAgfCBFeGFtcGxlOgogc3BwcFVwZGF0ZSAgICB8IChPcGVyYXRpb24gICB8ICAgICAg ICAgICB8IChPcGVyYXRpb24gIHxzcHBwVXBkYXRlCiAgICBSZXF1ZXN0TXNnIHwgICBJbnB1dCkg ICAgIHwgICAgICAgICAgIHwgIE91dHB1dCkgICAgfCAgIFJlc3BvbnNlTXNnCiAgICAgICAgICAg ICAgICstLS0tLS0tLS0tLS0tLSsgICAgICAgICAgICstLS0tLS0tLS0tLS0tKwogICAgICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgIENv bnRhaW5zIHwgICAgICAgICAgICAgICAgICAgICAgIHwgQ29udGFpbnMKICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAg ICBWICAgICAgICAgICAgICAgICAgICAgICBWCiAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0t LSsgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwogICAgICBFeGFtcGxlOnwgICAgV3JhcHBlZCAg ICB8ICAgICAgICAgfCAgV3JhcHBlZCAgICAgIHwgRXhhbXBsZToKICBzcHBwVXBkYXRlICB8UmVx dWVzdCBPYmplY3QgfCAgICAgICAgIHxSZXNwb25zZSBPYmplY3R8IHNwcHBVcGRhdGUKICAgICAg UmVxdWVzdCArLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rICAgICBS ZXNwb25zZQogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICB8 CiAgICAgICAgICAgICAgIENvbnRhaW5zIHwgICAgICAgICAgICAgICAgICAgICAgIHwgQ29udGFp bnMKICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgfAogICAg ICAgICAgICAgICAgICAgICAgICBWICAgICAgICAgICAgICAgICAgICAgICBWCiAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tLSsgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAg ICAgICAgICAgfCAgICAgIFNQUFAgICAgIHwgICAgICAgIHwgICAgICAgU1BQUCAgICAgICAgICB8 CiAgICAgICAgICAgICAgfCAgIFhNTCBUeXBlcyAgIHwgICAgICAgIHwgICAgIFhNTCBUeXBlcyAg ICAgICB8CiAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsgICAgICAgICstLS0tLS0tLS0t LS0tLS0tLS0tLS0rCiAgICAgICAgXV0+PC9hcnR3b3JrPgogICAgIDwvZmlndXJlPgoJICAKCSAg PHQ+VGhlIFNPQVAgb3BlcmF0aW9ucyBzdXBwb3J0ZWQgYnkgU1BQUCBhcmUgbm9ybWF0aXZlbHkg ZGVmaW5lZCBsYXRlciBpbiB0aGlzIAoJICBkb2N1bWVudC4gIEVhY2ggU09BUCBvcGVyYXRpb24g ZGVmaW5lcyBhIHJlcXVlc3QvaW5wdXQgbWVzc2FnZSBhbmQgYSAKCSAgcmVzcG9uc2Uvb3V0cHV0 IG1lc3NhZ2UuICBFYWNoIHN1Y2ggcmVxdWVzdCBhbmQgcmVzcG9uc2UgbWVzc2FnZSB0aGVuIAoJ ICBjb250YWlucyBhIHNpbmdsZSBvYmplY3QgdGhhdCB3cmFwcyB0aGUgU1BQUCBYTUwgZGF0YSB0 eXBlcyB0aGF0IGNvbXByaXNlIAoJICB0aGUgaW5wdXRzIGFuZCB0aGUgb3V0cHV0cywgcmVzcGVj dGl2ZWx5LCBvZiB0aGUgU09BUCBvcGVyYXRpb24uPC90PgoJICA8dD5TT0FQIGZhdWx0cyBhcmUg bm90IHVzZWQgYnkgdGhlIFNQUFAgU09BUCBtYXBwaW5nLiAgQWxsIFNQUFAgc3VjY2VzcyAKCSAg YW5kIGVycm9yIHJlc3BvbnNlcyBhcmUgc3BlY2lmaWVkIHdpdGhpbiB0aGUgU1BQUCBwcm90b2Nv bCBzcGVjaWZpY2F0aW9uIAoJICA8eHJlZiB0YXJnZXQ9IkktRC5kcmFmdC1pZXRmLWRyaW5rcy1z cHByb3YiLz4uICBIb3dldmVyLCBpZiBhIFNPQVAgZmF1bHQgd2VyZSAKCSAgdG8gb2NjdXIsIHBl cmhhcHMgZHVlIHRvIGZhaWx1cmVzIGluIHRoZSBTT0FQIG1lc3NhZ2UgaGFuZGxpbmcgbGF5ZXIg b2YgYSBTT0FQIAoJICBsaWJyYXJ5LCB0aGUgY2xpZW50IGFwcGxpY2F0aW9uIHNob3VsZCBjYXB0 dXJlIGFuZCBoYW5kbGUgdGhlIGZhdWx0LiAgU3BlY2lmaWNzIAoJICBvbiBob3cgdG8gaGFuZGxl IHN1Y2ggU09BUCBmYXVsdHMsIGlmIHRoZXkgc2hvdWxkIG9jY3VyLCB3aWxsIGJlIHNwZWNpZmlj IHRvIAoJICB0aGUgY2hvc2VuIFNPQVAgaW1wbGVtZW50YXRpb24uIDwvdD4KCSAgPHQ+U09BUCAx LjIgPHhyZWYgdGFyZ2V0PSJTT0FQUkVGIi8+IG9yIGhpZ2hlciBhbmQgV1NETCAxLjEgPHhyZWYg dGFyZ2V0PSJXU0RMUkVGIi8+IG9yIGhpZ2hlciBTSE9VTEQgYmUgdXNlZC48L3Q+Cgk8L3NlY3Rp b24+CgogICAgPHNlY3Rpb24gYW5jaG9yPSJIVFRQRmVhdHVyZXMiIHRpdGxlPSJIVFRQKHMpIEZl YXR1cmVzIGFuZCBTUFBQIj4KICAgICAgPHQ+U09BUCBpcyBub3QgdGllZCB0byBIVFRQKHMpLCBo b3dldmVyLCBmb3IgcmVhc29ucyBkZXNjcmliZWQgaW4gdGhlIAoJICBpbnRyb2R1Y3Rpb24sIEhU VFAocykgaXMgYSBnb29kIGNob2ljZSBhcyB0aGUgdHJhbnNwb3J0IG1lY2hhbmlzbSBmb3IgCgkg IHRoZSBTUFBQIFNPQVAgbWVzc2FnZXMuICBIVFRQIDEuMSBpbmNsdWRlcyB0aGUgJnF1b3Q7cGVy c2lzdGVudCBjb25uZWN0aW9uJnF1b3Q7IAoJICBmZWF0dXJlLCB3aGljaCBhbGxvd3MgbXVsdGlw bGUgSFRUUCByZXF1ZXN0L3Jlc3BvbnNlIHBhaXJzIHRvIGJlIHRyYW5zcG9ydGVkIAoJICBhY3Jv c3MgYSBzaW5nbGUgSFRUUCBjb25uZWN0aW9uLiAgVGhpcyBpcyBhbiBpbXBvcnRhbnQgcGVyZm9y bWFuY2UgCgkgIG9wdGltaXphdGlvbiBmZWF0dXJlLCBwYXJ0aWN1bGFybHkgd2hlbiB0aGUgY29u bmVjdGlvbnMgaXMgYW4gSFRUUFMgCgkgIGNvbm5lY3Rpb24gd2hlcmUgdGhlIHJlbGF0aXZlbHkg dGltZSBjb25zdW1pbmcgU1NMIGhhbmRzaGFrZSBoYXMgb2NjdXJyZWQuICAKCSAgUGVyc2lzdGVu dCBjb25uZWN0aW9ucyBTSE9VTEQgYmUgdXNlZCBmb3IgdGhlIFNQUFAgSFRUUCBjb25uZWN0aW9u cy48L3Q+IAoJICA8dD5IVFRQIDEuMSA8eHJlZiB0YXJnZXQ9IlJGQzI2MTYiLz4gb3IgaGlnaGVy IFNIT1VMRCBiZSB1c2VkLjwvdD4KICAgPC9zZWN0aW9uPgoKICAgIDxzZWN0aW9uIGFuY2hvcj0i QXV0aGVudGljYXRpb25TZXNzaW9uTWFuYWdlbWVudCIgdGl0bGU9IkF1dGhlbnRpY2F0aW9uIGFu ZCBTZXNzaW9uIE1hbmFnZW1lbnQiPgogICAgICAKICAgICAgPHQ+VG8gYWNoaWV2ZSBpbnRlZ3Jp dHkgYW5kcHJpdmFjeSwgY29uZm9ybWluZyBTUFBQIFNPQVAgQ2xpZW50cyBhbmQgU2VydmVycyBN VVNUIHN1cHBvcnQgU09BUCBvdmVyIEhUVFAgb3ZlciBUTFMgWzx4cmVmIHRhcmdldD0iUkZDNTI0 NiIvPl0gYXMgdGhlIHNlY3VyZSB0cmFuc3BvcnQgbWVjaGFuaXNtLiAgVGhpcyBjb21iaW5hdGlv biBvZiBIVFRQIGFuZCBUTFMgaXMgcmVmZXJyZWQgdG8gYXMgSFRUUFMuICBBbmQgdG8gYWNjb21w bGlzaCBhdXRoZW50aWNhdGlvbiBjb25mb3JtYWluZyBTT0FQIFNQUFAgQ2xpZW50cyBhbmQgU2Vy dmVycyBNVVNUIHVzZSBIVFRQIERpZ2VzdCBBdXRoZW50aWNhdGlvbiBhcyBkZWZpbmVkIGluIDx4 cmVmIHRhcmdldD0iUkZDMjYxNyIvPi4gIEFzIGEgcmVzdWx0LCB0aGUgY29tbXVuaWNhdGlvbiBz ZXNzaW9uIGlzIGVzdGFibGlzaGVkIHRocm91Z2ggdGhlIGluaXRpYWwgSFRUUCBjb25uZWN0aW9u IHNldHVwLCB0aGUgZGlnZXN0IGF1dGhlbnRpY2F0aW9uLCBhbmQgdGhlIFRMUyBoYW5kc2hha2Uu ICBXaGVuIHRoZSBIVFRQIGNvbm5lY3Rpb24gaXMgYnJva2VuIGRvd24sIHRoZSBjb21tdW5pY2F0 aW9uIHNlc3Npb24gZW5kcy48L3Q+CiAgICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gYW5jaG9y PSJTUFBQV1NETCIgdGl0bGU9IlNQUFAgU09BUCBXU0RMIERlZmluaXRpb24iPgogICAgICA8dD5U aGUgU1BQUCBXU0RMIGlzIGRlZmluZWQgYmVsb3cuICBUaGUgV1NETCBkZXNpZ24gYXBwcm9hY2gg aXMgY29tbW9ubHkgcmVmZXJyZWQgdG8gYXMgX0dlbmVyaWMgV1NETF8uICBJdCBpcyBnZW5lcmlj IGluIHRoZSBzZW5zZSB0aGF0IHRoZXJlIGlzIG5vdCBhIHNwZWNpZmljIFdTREwgb3BlcmF0aW9u IGRlZmluZWQgZm9yIGVhY2ggb2JqZWN0IHR5cGUgdGhhdCBpcyBzdXBwb3J0ZWQgYnkgdGhlIFNQ UFAgcHJvdG9jb2wuICBUaGVyZSBpcyBhIHNpbmdsZSBXU0RMIHVwZGF0ZSBvcGVyYXRpb24gY2Fs bGVkIHN1Ym1pdFVwZGF0ZVJxc3QsIGFuZCBhIHNpbmdsZSBXU0RMIHF1ZXJ5IG9wZXJhdGlvbiBj YWxsZWQgc3VibWl0UXVlcnlScXN0LiAgVGhlIHN1Ym1pdFVwZGF0ZVJxc3Qgb3BlcmF0aW9uIHRh a2VzIGFzIGlucHV0IGFuIHNwcHBVcGRhdGVSZXF1ZXN0TXNnIG9iamVjdCBhbmQgcmV0dXJucyBh cyBvdXRwdXQgYW4gc3BwcFVwZGF0ZVJlc3BvbnNlTXNnIG9iamVjdC4gIFRoZXNlIG9iamVjdHMg X3dyYXBfIHRoZSBzcHBwVXBkYXRlUmVxdWVzdCBhbmQgc3BwcFVwZGF0ZVJlc3BvbnNlIG9iamVj dHMgcmVzcGVjdGl2ZWx5LiAgVGhlc2UgdHdvIG9iamVjdCBkYXRhIHN0cnVjdHVyZXMgYXJlIGRl c2NyaWJlZCBpbiB0aGUgU1BQUCBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIDx4cmVmIHRhcmdldD0i SS1ELmRyYWZ0LWlldGYtZHJpbmtzLXNwcHJvdiIvPi4gIEFuZCBmaW5hbGx5LCB0aGUgc3BwcFNP QVBCaW5kaW5nIGluIHRoZSBXU0RMIGRlZmluZXMgdGhlIGJpbmRpbmcgc3R5bGUgYXMgX2RvY3Vt ZW50XyBhbmQgdGhlIGVuY29kaW5nIGFzIF9saXRlcmFsXy4gIEl0IGlzIHRoaXMgY29tYmluYXRp b24gb2YgX3dyYXBwZWRfIGlucHV0IGFuZCBvdXRwdXQgZGF0YSBzdHJ1Y3R1cmVzLCBfZG9jdW1l bnRfIGJpbmRpbmcgc3R5bGUsIGFuZCBfbGl0ZXJhbF8gZW5jb2RpbmcgdGhhdCBjaGFyYWN0ZXJp emUgdGhlIERvY3VtZW50IExpdGVyYWwgV3JhcHBlZCBzdHlsZSBvZiBXU0RMIHNwZWNpZmljYXRp b25zLjwvdD4KPHQ+VGhlIGFkdmFudGFnZSBvZiBnZW5lcmljIFdTREwgaXMgdGhhdCB0aGUgV1NE TCBpcyBtb3JlIHN1Y2NpbmN0LCBtdWNoIHNpbXBsZXIsIGFuZCB0aGVyZm9yZSBtb3JlIGVhc2ls eSBtYWludGFpbmVkLiAgQXMgbmV3IHR5cGVzIG9mIHByb3RvY29sIG9iamVjdHMgYW5kIGFjdGlv bnMgYXJlIGFkZGVkIGludG8gb3IgcmVtb3ZlZCBmcm9tIHRoZSBTUFBQIHByb3RvY29sLCB0aGUg V1NETCBkb2VzIG5vdCBuZWVkIHRvIGNoYW5nZS4gIFRoaXMgYXBwcm9hY2ggaXMgbWFkZSBwb3Nz aWJsZSBieSB0aGUgZmFjdCB0aGF0IHRoZSBTUFAgWE1MIGRhdGEgdHlwZXMgYW5kIHN1cHBvcnRl ZCBhY3Rpb25zIGFyZSBkZWZpbmVkIGluIHRoZSBTUFBQIFhNTCBzY2hlbWEsIG5vdCBpbiB0aGUg V1NETC4gIEFzIGEgcmVzdWx0IHRoZSBzdXBwb3J0ZWQgYWN0aW9ucyBkbyBub3QgbmVlZCB0byBi ZSByZS1kZWZpbmVkIGhlcmUgaW5zaWRlIHRoZSBTUFBQIFNPQVAgV1NETC48L3Q+CgoJPHQ+CgkJ Tm90ZTogVGhlIGZvbGxvd2luZyBXU0RMIGhhcyBiZWVuIGZvcm1hdHRlZCAoZS5nLiwgdGFicywg c3BhY2VzKSB0byBtZWV0IEktRCByZXF1aXJlbWVudHMuCgk8L3Q+CgogICAgICA8dD4KCSAgCSA8 ZmlndXJlIGFuY2hvcj0iV1NETCIgdGl0bGU9IldTREwiPgogICAgICAgIDxhcnR3b3JrIGFsaWdu PSJsZWZ0Ij48IVtDREFUQVsKCjw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8+ Cjx3c2RsOmRlZmluaXRpb25zIHhtbG5zOndzZGw9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3Jn L3dzZGwvIiAKIHhtbG5zOnNvYXA9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3dzZGwvc29h cC8iIAogeG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgCiB4bWxu czp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiAKIHhtbG5z OnNwcHBiPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnNwcHA6YmFzZToxIiAKIHhtbG5zOnNwcHBz PSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnNwcHA6c29hcDoxIiAKIHRhcmdldE5hbWVzcGFjZT0i dXJuOmlldGY6cGFyYW1zOnhtbDpuczpzcHBwOnNvYXA6MSIgCiB4c2k6c2NoZW1hTG9jYXRpb249 InNwcHBiYXNlLnhzZCI+Cgk8d3NkbDp0eXBlcz4KIDx4c2Q6c2NoZW1hPgogICAgICAgICAgPHhz ZDppbXBvcnQgbmFtZXNwYWNlPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnNwcHA6YmFzZToxIiAK ICAgICAgICAgICAgICAgICAgICAgIHNjaGVtYUxvY2F0aW9uPSJzcHBwYmFzZS54c2QiLz4KIDwv eHNkOnNjaGVtYT4KIDwvd3NkbDp0eXBlcz4KIDx3c2RsOm1lc3NhZ2UgbmFtZT0ic3BwcFVwZGF0 ZVJlcXVlc3RNc2ciPgogIDx3c2RsOnBhcnQgbmFtZT0icnFzdCIgZWxlbWVudD0ic3BwcGI6c3Bw cFVwZGF0ZVJlcXVlc3QiLz4KIDwvd3NkbDptZXNzYWdlPgogPHdzZGw6bWVzc2FnZSBuYW1lPSJz cHBwVXBkYXRlUmVzcG9uc2VNc2ciPgogIDx3c2RsOnBhcnQgbmFtZT0icnNwbnMiIGVsZW1lbnQ9 InNwcHBiOnNwcHBVcGRhdGVSZXNwb25zZSIvPgogPC93c2RsOm1lc3NhZ2U+CiA8d3NkbDptZXNz YWdlIG5hbWU9InNwcHBRdWVyeVJlcXVlc3RNc2ciPgogIDx3c2RsOnBhcnQgbmFtZT0icnFzdCIg ZWxlbWVudD0ic3BwcGI6c3BwcFF1ZXJ5UmVxdWVzdCIvPgogPC93c2RsOm1lc3NhZ2U+CiA8d3Nk bDptZXNzYWdlIG5hbWU9InNwcHBRdWVyeVJlc3BvbnNlTXNnIj4KICA8d3NkbDpwYXJ0IG5hbWU9 InJzcG5zIiBlbGVtZW50PSJzcHBwYjpzcHBwUXVlcnlSZXNwb25zZSIvPgogPC93c2RsOm1lc3Nh Z2U+CiA8d3NkbDptZXNzYWdlIG5hbWU9InNwcHBTZXJ2ZXJTdGF0dXNSZXF1ZXN0TXNnIj4KICA8 d3NkbDpwYXJ0IG5hbWU9InJxc3QiIGVsZW1lbnQ9InNwcHBiOnNwcHBTZXJ2ZXJTdGF0dXNSZXF1 ZXN0Ii8+CiA8L3dzZGw6bWVzc2FnZT4KIDx3c2RsOm1lc3NhZ2UgbmFtZT0ic3BwcFNlcnZlclN0 YXR1c1Jlc3BvbnNlTXNnIj4KICA8d3NkbDpwYXJ0IG5hbWU9InJzcG5zIiBlbGVtZW50PSJzcHBw YjpzcHBwU2VydmVyU3RhdHVzUmVzcG9uc2UiLz4KIDwvd3NkbDptZXNzYWdlPgogPHdzZGw6cG9y dFR5cGUgbmFtZT0ic3BwcFBvcnRUeXBlIj4KICA8d3NkbDpvcGVyYXRpb24gbmFtZT0ic3VibWl0 VXBkYXRlUnFzdCI+CiAgIDx3c2RsOmlucHV0IG1lc3NhZ2U9InNwcHBzOnNwcHBVcGRhdGVSZXF1 ZXN0TXNnIi8+CiAgIDx3c2RsOm91dHB1dCBtZXNzYWdlPSJzcHBwczpzcHBwVXBkYXRlUmVzcG9u c2VNc2ciLz4KICA8L3dzZGw6b3BlcmF0aW9uPgogIDx3c2RsOm9wZXJhdGlvbiBuYW1lPSJzdWJt aXRRdWVyeVJxc3QiPgogICA8d3NkbDppbnB1dCBtZXNzYWdlPSJzcHBwczpzcHBwUXVlcnlSZXF1 ZXN0TXNnIi8+CiAgIDx3c2RsOm91dHB1dCBtZXNzYWdlPSJzcHBwczpzcHBwUXVlcnlSZXNwb25z ZU1zZyIvPgogIDwvd3NkbDpvcGVyYXRpb24+CiAgPHdzZGw6b3BlcmF0aW9uIG5hbWU9InN1Ym1p dFNlcnZlclN0YXR1c1Jxc3QiPgogICA8d3NkbDppbnB1dCBtZXNzYWdlPSJzcHBwczpzcHBwU2Vy dmVyU3RhdHVzUmVxdWVzdE1zZyIvPgogICA8d3NkbDpvdXRwdXQgbWVzc2FnZT0ic3BwcHM6c3Bw cFNlcnZlclN0YXR1c1Jlc3BvbnNlTXNnIi8+CiAgPC93c2RsOm9wZXJhdGlvbj4KIDwvd3NkbDpw b3J0VHlwZT4KIDx3c2RsOmJpbmRpbmcgbmFtZT0ic3BwcFNvYXBCaW5kaW5nIiB0eXBlPSJzcHBw czpzcHBwUG9ydFR5cGUiPgogIDxzb2FwOmJpbmRpbmcgc3R5bGU9ImRvY3VtZW50IiAKCQl0cmFu c3BvcnQ9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvaHR0cCIvPgogIDx3c2RsOm9w ZXJhdGlvbiBuYW1lPSJzdWJtaXRVcGRhdGVScXN0Ij4KICAgPHNvYXA6b3BlcmF0aW9uIHNvYXBB Y3Rpb249InN1Ym1pdFVwZGF0ZVJxc3QiIHN0eWxlPSJkb2N1bWVudCIvPgogICA8d3NkbDppbnB1 dD4KICAgIDxzb2FwOmJvZHkgdXNlPSJsaXRlcmFsIi8+CiAgIDwvd3NkbDppbnB1dD4KICAgPHdz ZGw6b3V0cHV0PgogICAgPHNvYXA6Ym9keSB1c2U9ImxpdGVyYWwiLz4KICAgPC93c2RsOm91dHB1 dD4KICA8L3dzZGw6b3BlcmF0aW9uPgogIDx3c2RsOm9wZXJhdGlvbiBuYW1lPSJzdWJtaXRRdWVy eVJxc3QiPgogICA8c29hcDpvcGVyYXRpb24gc29hcEFjdGlvbj0ic3VibWl0UXVlcnlScXN0IiBz dHlsZT0iZG9jdW1lbnQiLz4KICAgPHdzZGw6aW5wdXQ+CiAgICA8c29hcDpib2R5IHVzZT0ibGl0 ZXJhbCIvPgogICA8L3dzZGw6aW5wdXQ+CiAgIDx3c2RsOm91dHB1dD4KICAgIDxzb2FwOmJvZHkg dXNlPSJsaXRlcmFsIi8+CiAgIDwvd3NkbDpvdXRwdXQ+CiAgPC93c2RsOm9wZXJhdGlvbj4KICA8 d3NkbDpvcGVyYXRpb24gbmFtZT0ic3VibWl0U2VydmVyU3RhdHVzUnFzdCI+CiAgPHNvYXA6b3Bl cmF0aW9uIHNvYXBBY3Rpb249InN1Ym1pdFNlcnZlclN0YXR1c1Jxc3QiIHN0eWxlPSJkb2N1bWVu dCIvPgogICA8d3NkbDppbnB1dD4KICAgIDxzb2FwOmJvZHkgdXNlPSJsaXRlcmFsIi8+CiAgIDwv d3NkbDppbnB1dD4KICAgPHdzZGw6b3V0cHV0PgogICAgPHNvYXA6Ym9keSB1c2U9ImxpdGVyYWwi Lz4KICAgPC93c2RsOm91dHB1dD4KICA8L3dzZGw6b3BlcmF0aW9uPgogPC93c2RsOmJpbmRpbmc+ CiA8d3NkbDpzZXJ2aWNlIG5hbWU9InNwcHBTZXJ2aWNlIj4KICA8d3NkbDpwb3J0IG5hbWU9InNw cHBQb3J0IiBiaW5kaW5nPSJzcHBwczpzcHBwU29hcEJpbmRpbmciPgogICA8c29hcDphZGRyZXNz IGxvY2F0aW9uPSJSRVBMQUNFX1dJVEhfQUNUVUFMX1VSTCIvPgogIDwvd3NkbDpwb3J0PgogPC93 c2RsOnNlcnZpY2U+Cjwvd3NkbDpkZWZpbml0aW9ucz4KCiAgICAgICBdXT48L2FydHdvcms+CiAg ICAgPC9maWd1cmU+PC90PgogICAgPC9zZWN0aW9uPgoKCiAgICA8c2VjdGlvbiBhbmNob3I9IlNl Y3VyaXR5Q29uc2lkZXJhdGlvbnMiIHRpdGxlPSJTZWN1cml0eSBDb25zaWRlcmF0aW9ucyI+CiAg ICAgIDx0PlNQUFAgaXMgdXNlZCB0byBxdWVyeSBhbmQgdXBkYXRlIHNlc3Npb24gcGVlcmluZyBk YXRhIGFuZCBhZGRyZXNzZXMsIHNvCiAgIHRoZSBhYmlsaXR5IHRvIGFjY2VzcyB0aGlzIHByb3Rv Y29sIHNob3VsZCBiZSBsaW1pdGVkIHRvIHVzZXJzIGFuZAogICBzeXN0ZW1zIHRoYXQgYXJlIGF1 dGhvcml6ZWQgdG8gcXVlcnkgYW5kIHVwZGF0ZSB0aGlzIGRhdGEuICBCZWNhdXNlIHRoaXMgCiAg IGRhdGEgaXMgc2VudCBpbiBib3RoIGRpcmVjdGlvbnMsIGl0IG1heSBub3QgYmUgc3VmZmljaWVu dCBmb3IganVzdCB0aGUgY2xpZW50IAogICBvciB1c2VyIHRvIGJlIGF1dGhlbnRpY2F0ZWQgd2l0 aCB0aGUgc2VydmVyLiAgVGhlIGlkZW50aXR5IG9mIHRoZSBzZXJ2ZXIgCiAgIHNob3VsZCBhbHNv IGJlIGF1dGhlbnRpY2F0ZWQgYnkgdGhlIGNsaWVudCwgd2hpY2ggaXMgb2Z0ZW4gYWNjb21wbGlz aGVkIHVzaW5nIAogICB0aGUgVExTIGNlcnRpZmljYXRlIGV4Y2hhbmdlIGFuZCB2YWxpZGF0aW9u IGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9IlJGQzI4MTgiLz4uICAKICAgU1BQUCBkYXRhIG1h eSBpbmNsdWRlIHNlbnNpdGl2ZSAKICAgaW5mb3JtYXRpb24sIHJvdXRpbmcgZGF0YSwgbGlzdHMg b2YgcmVzb2x2YWJsZSBhZGRyZXNzZXMsIGV0Yy4gIFNvIHdoZW4gdXNlZAogICBpbiBhIHByb2R1 Y3Rpb24gc2V0dGluZyBhbmQgYWNyb3NzIG5vbi1zZWN1cmUgbmV0d29ya3MsIFNQUFAgCiAgIHNo b3VsZCBvbmx5IGJlIHVzZWQgb3ZlciBjb21tdW5pY2F0aW9ucyBjaGFubmVscyB0aGF0IHByb3Zp ZGUgc3Ryb25nIAogICBlbmNyeXB0aW9uIGZvciBkYXRhIHByaXZhY3kuPC90PgoKICAgICAgPHNl Y3Rpb24gYW5jaG9yPSJJbnRlZ3JpdHlQcml2YWN5QXV0aGVudGljYXRpb24iIHRpdGxlPSJJbnRl Z3JpdHksIFByaXZhY3ksIGFuZCBBdXRoZW50aWNhdGlvbiI+CgogICA8dD5UaGUgU1BQUCBTT0FQ IGJpbmRpbmcgcmVsaWVzIG9uIGFuIHVuZGVybHlpbmcgc2VjdXJlIHRyYW5zcG9ydCBmb3IKICAg aW50ZWdyaXR5IGFuZCBwcml2YWN5LiAgU3VjaCB0cmFuc3BvcnRzIGFyZSBleHBlY3RlZCB0byBp bmNsdWRlIFRMUy9IVFRQUy4gIAogICBJbiBhZGRpdGlvbiB0byB0aGUgYXBwbGljYXRpb24gbGV2 ZWwgYXV0aGVudGljYXRpb24gaW1wb3NlZCBieSBhbiBTUFBQIAogICBzZXJ2ZXIsIHRoZXJlIGFy ZSBhIG51bWJlciBvZiBvcHRpb25zIGZvciBhdXRoZW50aWNhdGlvbiB3aXRoaW4gdGhlIHRyYW5z cG9ydCAKICAgbGF5ZXIgYW5kIHRoZSBtZXNzYWdpbmcgZW52ZWxvcGUuICBUaGVzZSBpbmNsdWRl IFRMUyBjbGllbnQgY2VydGlmaWNhdGVzLCAKICAgSFRUUCBEaWdlc3QgQWNjZXNzIEF1dGhlbnRp Y2F0aW9uLCBhbmQgZGlnaXRhbCBzaWduYXR1cmVzIHdpdGhpbiBTT0FQIGhlYWRlcnMuIDwvdD4K ICAgCiAgIDx0PkF0IGEgbWluaXVtdW0sIGFsbCBjb25mb3JtaW5nIFNQUFAgb3ZlciBTT0FQIGlt cGxlbWVudGF0aW9ucyBNVVNUCiAgIHN1cHBvcnQgSFRUUFMuPC90PgogICAKICAgICAgPC9zZWN0 aW9uPgoKICAgICAgPHNlY3Rpb24gYW5jaG9yPSJWdWxuZXJhYmlsaXRpZXMiIHRpdGxlPSJWdWxu ZXJhYmlsaXRpZXMiPgoKICAgPHQ+VGhlIGFib3ZlIHByb3RvY29scyBtYXkgaGF2ZSB2YXJpb3Vz IHZ1bG5lcmFiaWxpdGllcywgYW5kIHRoZXNlIG1heQogICBiZSBpbmhlcml0ZWQgYnkgU1BQUCBv dmVyIFNPQVAuICBBbmQgU1BQUCBpdHNlbGYgbWF5IGhhdmUgdnVsbmVyYWJpbGl0aWVzIAogICBi ZWNhdXNlIGFuIGF1dGhvcml6YXRpb24gbW9kZWwgaXMgbm90IGV4cGxpY2l0bHkgc3BlY2lmaWVk IGluIHRoZSBjdXJyZW50IAogICBzcGVjaWZpY2F0aW9uLgogICA8L3Q+CiAgIAogICA8dD5JdCBp cyBpbXBvcnRhbnQgdGhhdCBTUFBQIGltcGxlbWVudGF0aW9ucyBpbXBsZW1lbnQgYW4gYXV0aG9y aXphdGlvbiAKICAgbW9kZWwgdGhhdCBjb25zaWRlcnMgdGhlIHNvdXJjZSBvZiBlYWNoIFNQUFAg cXVlcnkgb3IgdXBkYXRlIHJlcXVlc3QgYW5kIAogICBkZXRlcm1pbmVzIHdoZXRoZXIgaXQgaXMg cmVhc29uYWJsZSB0byBhdXRob3JpemUgdGhhdCBzb3VyY2UgdG8gcGVyZm9ybSB0aGF0CiAgIHNw ZWNpZmljIHF1ZXJ5IG9yIHVwZGF0ZS4gPC90PgogICAKICAgICAgPC9zZWN0aW9uPgoKICAgICAg PHNlY3Rpb24gYW5jaG9yPSJEZXBsb3ltZW50RW52aXJvbm1lbnRTcGVjaWZpY3MiIHRpdGxlPSJE ZXBsb3ltZW50IEVudmlyb25tZW50IFNwZWNpZmljcyI+CgogICA8dD5Tb21lIGRlcGxveW1lbnRz IG9mIFNQUFAgb3ZlciBTT0FQIGNvdWxkIGNob29zZSB0byB1c2UgdHJhbnNwb3J0cwogICB3aXRo b3V0IGVuY3J5cHRpb24uICBUaGlzIHByZXNlbnRzIHZ1bG5lcmFiaWxpdGllcyBidXQgY291bGQg YmUKICAgc2VsZWN0ZWQgZm9yIGRlcGxveW1lbnRzIGludm9sdmluZyBjbG9zZWQgbmV0d29ya3Mg b3IgZGVidWdnaW5nCiAgIHNjZW5hcmlvcy4gIEhvd2V2ZXIsIHRoZSB2dWxuZXJhYmlsaXRpZXMg b2Ygc3VjaCBhIGRlcGxveW1lbnQgY291bGQgYmUgYSAKICAgbGFjayBvZiBpbnRlZ3JpdHkgYW5k IHByaXZhY3kgb2YgdGhlIGRhdGEgdHJhbnNwb3J0ZWQgb3ZlciBTUFBQIG1lc3NhZ2VzIGluIAog ICB0aGlzIHR5cGUgb2YgZGVwbG95bWVudC48L3Q+CiAgIAogICAgICA8L3NlY3Rpb24+CgogICAg PC9zZWN0aW9uPgogCiAgICA8c2VjdGlvbiBhbmNob3I9IklBTkFDb25zaWRlcmF0aW9ucyIgdGl0 bGU9IklBTkEgQ29uc2lkZXJhdGlvbnMiPgogICAgICA8dD5UaGlzIGRvY3VtZW50IHVzZXMgVVJO cyB0byBkZXNjcmliZSBYTUwgbmFtZXNwYWNlcyBhbmQgWE1MIHNjaGVtYXMKICAgY29uZm9ybWlu ZyB0byBhIHJlZ2lzdHJ5IG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gPHhyZWYgdGFyZ2V0PSJSRkMz Njg4Ii8+LgogICAgPC90PgogICA8dD5VUk4gYXNzaWdubWVudHMgYXJlIHJlcXVlc3RlZDogIHVy bjppZXRmOnBhcmFtczp4bWw6bnM6c3BwcDpzb2FwPC90PgogICAgPC9zZWN0aW9uPgogCiA8c2Vj dGlvbiBhbmNob3I9IkFja25vd2xlZGdlbWVudHMiIHRpdGxlPSJBY2tub3dsZWRnZW1lbnRzIj4K ICAgIDx0PgoJCVRoaXMgZG9jdW1lbnQgaXMgYSByZXN1bHQgb2YgdmFyaW91cyBkaXNjdXNzaW9u cyBoZWxkIGJ5IHRoZSBEUklOS1MgZGVzaWduIHRlYW0sIHdoaWNoIGlzIGNvbXByaXNlZCBvZiB0 aGUgZm9sbG93aW5nIGluZGl2aWR1YWxzLCBpbiBubyBzcGVjaWZpYyBvcmRlcjogU3llZCBBbGkg KE5ldVN0YXIpLCBTdW1hbnRoIENoYW5uYWJhc2FwcGEgKENhYmxlIExhYnMpLCBEYXZpZCBTY2h3 YXJ0eiAoWENvbm5lY3QpLCBKZWFuLUZyYW5jb2lzIE11bGUgKENhYmxlTGFicyksIEtlbm5ldGgg Q2FydHdyaWdodCAoVE5TLCBJbmMuKSwgTWFuanVsIE1haGFyaXNoaSAoVE5TLCBJbmMuKSwgQWxl eGFuZGVyIE1heXJob2ZlciAoZW51bS5hdCBHbWJIKS4KCQk8L3Q+CgogICAgPC9zZWN0aW9uPgoK ICA8L21pZGRsZT4KCiAgPGJhY2s+CiAgICA8cmVmZXJlbmNlcyB0aXRsZT0iTm9ybWF0aXZlIFJl ZmVyZW5jZXMiPgogICAgICAgICAgICAgICAgJnJmYzIxMTk7CiAgICAgICAgICAgICAgICAmcmZj MzY4ODsKICAgICAgICAgICAgICAgICZyZmM1MjQ2OwogICAgICAgICAgICAgICAgJnJmYzI2MTc7 CiAgICAgICAgICAgICAgICAmcmZjMjYxNjsKICAgICAgICAgICAgICAgICZyZmMyODE4CiAgICAg ICAgICAgICAgICA8cmVmZXJlbmNlIGFuY2hvcj0iSS1ELmRyYWZ0LWlldGYtZHJpbmtzLXNwcHJv diI+CiAgICAgICAgICAgICAgICAgICAgICAgIDxmcm9udD4KICAgICAgICAgICAgICAgICAgICAg ICAgICA8dGl0bGU+RFJJTktTIFVzZSBjYXNlcyBhbmQgUHJvdG9jb2wgUmVxdWlyZW1lbnRzPC90 aXRsZT4KCiAgICAJCQkJCSAgPGF1dGhvciBpbml0aWFscz0iSi1GLk0uIiBzdXJuYW1lPSJNdWxl Ii8+CiAgICAJCQkJCSAgPGF1dGhvciBpbml0aWFscz0iSy5DLiIgc3VybmFtZT0iQ2FydHdyaWdo dCIvPgogICAgCQkJCQkgIDxhdXRob3IgaW5pdGlhbHM9IlMuQS4iIHN1cm5hbWU9IkFsaSIvPgog ICAgCQkJCQkgIDxhdXRob3IgaW5pdGlhbHM9IkEuTS4iIHN1cm5hbWU9Ik1heXJob2ZlciIvPgog ICAgCQkJCQkKICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGF0ZSBtb250aD0iSnVuZSIgeWVh cj0iMjAxMSIgLz4KICAgICAgICAgICAgICAgICAgICAgICAgPC9mcm9udD4KICAgICAgICAgICAg ICAgICAgICAgICAgPHNlcmllc0luZm8gbmFtZT0iSW50ZXJuZXQtRHJhZnQiIHZhbHVlPSJkcmFm dC1pZXRmLWRyaW5rcy1zcHByb3YtMDciLz4KICAgICAgICAgICAgICAgICAgICAgICAgPGZvcm1h dCB0YXJnZXQ9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZHJpbmtzLXNw cHJvdi0wNyIgdHlwZT0iSFRNTCIgLz4KICAgICAgICAgICAgICAgIDwvcmVmZXJlbmNlPgoKICAg ICAgICAgICAgICAgIDxyZWZlcmVuY2UgYW5jaG9yPSJTT0FQUkVGIj4KICAgICAgICAgICAgICAg ICAgICAgICAgPGZyb250PgogICAgICAgICAgICAgICAgICAgICAgICAgIDx0aXRsZT5TT0FQIFZl cnNpb24gMS4yIFBhcnQgMTogTWVzc2FnaW5nIEZyYW1ld29yazwvdGl0bGU+CgogICAgCQkJCQkg ICA8YXV0aG9yIGluaXRpYWxzPSJNLiIgc3VybmFtZT0iR3VkZ2luIi8+CiAgICAJCQkJCSAgIDxh dXRob3IgaW5pdGlhbHM9Ik0uIiBzdXJuYW1lPSJIYWRsZXkiLz4KICAgIAkJCQkJICAgPGF1dGhv ciBpbml0aWFscz0iSi4iIHN1cm5hbWU9Ik1vcmVhdSIvPgogICAgCQkJCQkgICA8YXV0aG9yIGlu aXRpYWxzPSJILiIgc3VybmFtZT0iTmllbHNlbiIvPgoKICAgICAgICAgICAgICAgICAgICAgICAg ICAgPGRhdGUgbW9udGg9Ikp1bmUiIHllYXI9IjIwMDIiIC8+CiAgICAgICAgICAgICAgICAgICAg ICAgIDwvZnJvbnQ+CiAgICAgICAgICAgICAgICAgICAgICAgIDxzZXJpZXNJbmZvIG5hbWU9Ilcz QyBSZWNvbW1lbmRhdGlvbiIgdmFsdWU9IlJFQy1TT0FQMTItcGFydDEtMjAwMzA2MjQiLz4KICAg ICAgICAgICAgICAgICAgICAgICAgPGZvcm1hdCB0YXJnZXQ9Imh0dHA6Ly93d3cudzMub3JnL1RS L3NvYXAxMi1wYXJ0MS8iIHR5cGU9IkhUTUwiIC8+CiAgICAgICAgICAgICAgICA8L3JlZmVyZW5j ZT4KCiAgICAgICAgICAgICAgICA8cmVmZXJlbmNlIGFuY2hvcj0iV1NETFJFRiI+CiAgICAgICAg ICAgICAgICAgICAgICAgIDxmcm9udD4KICAgICAgICAgICAgICAgICAgICAgICAgICA8dGl0bGU+ V2ViIFNlcnZpY2VzIERlc2NyaXB0aW9uIExhbmd1YWdlIChXU0RMKSAxLjE8L3RpdGxlPgoKICAg IAkJCQkJICAgPGF1dGhvciBpbml0aWFscz0iRS4iIHN1cm5hbWU9IkNocmlzdGVuc2VuIi8+CiAg ICAJCQkJCSAgIDxhdXRob3IgaW5pdGlhbHM9IkYuIiBzdXJuYW1lPSJDdXJiZXJhIi8+CiAgICAJ CQkJCSAgIDxhdXRob3IgaW5pdGlhbHM9IkcuIiBzdXJuYW1lPSJNZXJlZGl0aCIvPgogICAgCQkJ CQkgICA8YXV0aG9yIGluaXRpYWxzPSJTLiIgc3VybmFtZT0iV2VlcmF3YXJhbmEiLz4KCiAgICAg ICAgICAgICAgICAgICAgICAgICAgIDxkYXRlIG1vbnRoPSJNYXJjaCIgeWVhcj0iMjAwMSIgLz4K ICAgICAgICAgICAgICAgICAgICAgICAgPC9mcm9udD4KICAgICAgICAgICAgICAgICAgICAgICAg PHNlcmllc0luZm8gbmFtZT0iVzNDIE5vdGUiIHZhbHVlPSJOT1RFLXdzZGwtMjAwMTAzMTUiLz4K ICAgICAgICAgICAgICAgICAgICAgICAgPGZvcm1hdCB0YXJnZXQ9Imh0dHA6Ly93d3cudzMub3Jn L1RSLzIwMDEvTk9URS13c2RsLTIwMDEwMzE1IiB0eXBlPSJIVE1MIiAvPgogICAgICAgICAgICAg ICAgPC9yZWZlcmVuY2U+CgogICAgPC9yZWZlcmVuY2VzPgogICAgCiAgICA8cmVmZXJlbmNlcyB0 aXRsZT0iSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyI+IAogICAgICAgICAgICAgICAgPHJlZmVyZW5j ZSBhbmNob3I9IldTRExSRUYiPgogICAgICAgICAgICAgICAgICAgICAgICA8ZnJvbnQ+CiAgICAg ICAgICAgICAgICAgICAgICAgICAgPHRpdGxlPldlYiBTZXJ2aWNlcyBEZXNjcmlwdGlvbiBMYW5n dWFnZSAoV1NETCkgMS4xPC90aXRsZT4KCiAgICAJCQkJCSAgIDxhdXRob3IgaW5pdGlhbHM9IkUu IiBzdXJuYW1lPSJDaHJpc3RlbnNlbiIvPgogICAgCQkJCQkgICA8YXV0aG9yIGluaXRpYWxzPSJG LiIgc3VybmFtZT0iQ3VyYmVyYSIvPgogICAgCQkJCQkgICA8YXV0aG9yIGluaXRpYWxzPSJHLiIg c3VybmFtZT0iTWVyZWRpdGgiLz4KICAgIAkJCQkJICAgPGF1dGhvciBpbml0aWFscz0iUy4iIHN1 cm5hbWU9IldlZXJhd2FyYW5hIi8+CgogICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGF0ZSBt b250aD0iTWFyY2giIHllYXI9IjIwMDEiIC8+CiAgICAgICAgICAgICAgICAgICAgICAgIDwvZnJv bnQ+CiAgICAgICAgICAgICAgICAgICAgICAgIDxzZXJpZXNJbmZvIG5hbWU9IlczQyBOb3RlIiB2 YWx1ZT0iTk9URS13c2RsLTIwMDEwMzE1Ii8+CiAgICAgICAgICAgICAgICAgICAgICAgIDxmb3Jt YXQgdGFyZ2V0PSJodHRwOi8vd3d3LnczLm9yZy9UUi8yMDAxL05PVEUtd3NkbC0yMDAxMDMxNSIg dHlwZT0iSFRNTCIgLz4KICAgICAgICAgICAgICAgIDwvcmVmZXJlbmNlPgogICAgPC9yZWZlcmVu Y2VzPgoKICA8L2JhY2s+CiAgCjwvcmZjPgo= --_002_754963199212404AB8E9CFCA6C3D0CDA38DDA5DD43TNSMAILNAwin2_-- From kcartwright@tnsi.com Tue Aug 23 13:31:16 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3893421F8880 for ; Tue, 23 Aug 2011 13:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odq206TnFmhY for ; Tue, 23 Aug 2011 13:31:12 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 51C4821F8841 for ; Tue, 23 Aug 2011 13:31:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUAAMoMVE6sEQfn/2dsb2JhbAA5CZgTkEkZgScBAQEBAwEBARcBUAMXBAIBCBEEAQEoBwIlCxQJCAEBBAEJCQgGh2etLpA4gyiCQV8EnRGHHg X-IronPort-AV: E=Sophos;i="4.68,271,1312153200"; d="xml'217?txt'217?scan'217,208,217";a="134517" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 23 Aug 2011 21:32:16 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Tue, 23 Aug 2011 16:32:15 -0400 From: "Cartwright, Ken" To: "Cartwright, Ken" , "drinks@ietf.org" Date: Tue, 23 Aug 2011 16:33:08 -0400 Thread-Topic: [drinks] review of draft-ietf-drinks-sppp-over-soap-04 Thread-Index: AcxHL7hYeVR4uLhzTQGn4wmKqZXE9wXfKjgQAMnPsVA= Message-ID: <754963199212404AB8E9CFCA6C3D0CDA38DDB8C58D@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4E275C25.1050105@stpeter.im> <754963199212404AB8E9CFCA6C3D0CDA38DDA5DD43@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA38DDA5DD43@TNS-MAIL-NA.win2k.corp.tnsi.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_003_754963199212404AB8E9CFCA6C3D0CDA38DDB8C58DTNSMAILNAwin2_" MIME-Version: 1.0 Subject: Re: [drinks] review of draft-ietf-drinks-sppp-over-soap-04 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 20:31:16 -0000 --_003_754963199212404AB8E9CFCA6C3D0CDA38DDB8C58DTNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is the updated version of the document that includes examples to addre= ss the point made by Ning. That was the last outstanding comment. Ken -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Cartwright, Ken Sent: Friday, August 19, 2011 5:21 PM To: drinks@ietf.org Subject: Re: [drinks] review of draft-ietf-drinks-sppp-over-soap-04 I've incorporated the updates listed below, that address the points made by= Peter. The remaining task is to incorporate some SOAP message examples, a= s suggested by Ning. I will do that on Tuesday (I'm out on Monday). Ken 1. Clarified that sentence and others. 2. Changed the approach of other IETF RFCs that use WSDL (e.g. 4743) to re= fer to this reference as informative rather than normative. 3. Updated the wording in the Transport Security section to make it clear = the intent is to use HTTPS for integrity and privacy. Also added a referen= ce to 2818 later in the document. 4. The WSDL name space definition and the target namespace specifications = are correct as they stand. 5. Added to the wording of the Security Considerations section to refer to= the practice of using certificate exchange/verification to perform server = authentication, and referred to 2818. 6. Added some more verbiage to the "Environment Specific Considerations se= ction and removed the use of the overloaded word "may". 7. It is not clear to me that we really _need_ anything else in the IANA s= ection. So I left that as it stands. 8. Added a sentence about SOAP faults that could, theoretically, be genera= ted by the chosen SOAP library, but that do not relate to SPPP. However, t= his is a subject that does not directly relate to SPPP. So I did not get t= oo verbose on this subject. -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Peter Saint-Andre Sent: Wednesday, July 20, 2011 6:52 PM To: drinks@ietf.org Subject: [drinks] review of draft-ietf-drinks-sppp-over-soap-04 I've been asked to take a look at draft-ietf-drinks-sppp-over-soap. Overall I think it is in fine shape. Here are a few comments. 1. The document needs to be edited for clarity. For example, some of the sentences don't parse (e.g., the third sentence of Section 1). 2. There's a normative reference to W3C Note NOTE-wsdl-20010315, which says "This document is a NOTE made available by the W3C for discussion only. Publication of this Note by W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members. W3C has had no editorial control over the preparation of this Note. This document is a work in progress and may be updated, replaced, or rendered obsolete by other documents at any time." Thus the phrase "WSDL is a widely standardized and adopted technology" in this I-D is not accurate, at least with regard to standarization. Furthermore, no published RFCs contain a normative reference to the WSDL document, which also is not in the downref registry. This will need to be called out during IETF Last Call. 3. Section 3 states "SOAP faults are not used by the SPPP SOAP mapping." It would be good to define how an application is supposed to handle SOAP faults if they occur for other reasons, or reference the SOAP specification on this point. 4. Transport security is a bit unclear to me. The spec says: All SOAP and HTTP SPPP Clients and Servers MUST support Transport Layer Security (TLS) as defined in [RFC5246] as the secure transport mechanism. Does that mean supporting HTTP Over TLS (RFC 2818) except using the most up-to-date version of TLS, or using TLS directly over TCP? 5. I am not a WSDL expert, but the definition looks fine to me (even if hard to read). This seems a bit odd: xmlns:sppps=3D"urn:ietf:params:xml:ns:sppp:soap:1" targetNamespace=3D"urn:ietf:params:xml:ns:sppp:soap:1" Why define the same namespace in two ways? 6. Section 7 says "The identity of the server should also be authenticated by the client." However, no guidance is provided about how to do that. A reference to RFC 2818 seems necessary. 7. Section 7.3 states: Some deployments of SPPP over SOAP may choose to use transports without encryption. This presents vulnerabilities but may be selected for deployments involving closed networks or debugging scenarios. Do you mean "MAY"? Is encryption truly optional? Please clarify that you mean MUST-implement and SHOULD-deploy or somesuch (where your "may" here really means "here's why a deployment might have a good reason to violate the SHOULD-deploy"). 8. The IANA considerations seem a bit thin. Please see RFC 3688 for the template. I know there are a few examples in Section 14 of RFC 6120, so feel free to borrow from there. :) Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_003_754963199212404AB8E9CFCA6C3D0CDA38DDB8C58DTNSMAILNAwin2_ Content-Type: text/xml; name="draft-ietf-drinks-sppp-over-soap-05.xml" Content-Description: draft-ietf-drinks-sppp-over-soap-05.xml Content-Disposition: attachment; filename="draft-ietf-drinks-sppp-over-soap-05.xml"; size=25651; creation-date="Fri, 19 Aug 2011 16:15:30 GMT"; modification-date="Tue, 23 Aug 2011 16:29:57 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4KCjwhRE9DVFlQRSByZmMgU1lT VEVNICJyZmMyNjI5LmR0ZCIgWwogICAgICAgIDwhRU5USVRZIHJmYzIxMTkgUFVCTElDICIiCiAg ICAgICAgICAiaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJl bmNlLlJGQy4yMTE5LnhtbCI+CiAgICAgICAgPCFFTlRJVFkgcmZjMzY4OCBQVUJMSUMgIiIKICAg ICAgICAgICJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVu Y2UuUkZDLjM2ODgueG1sIj4KICAgICAgICA8IUVOVElUWSByZmM1NDg2IFBVQkxJQyAiIgogICAg ICAgICAgImh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5j ZS5SRkMuNTQ4Ni54bWwiPgogICAgICAgICA8IUVOVElUWSByZmM1MjQ2IFBVQkxJQyAiIgogICAg ICAgICAgImh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5j ZS5SRkMuNTI0Ni54bWwiPgogICAgICAgIDwhRU5USVRZIHJmYzI2MTcgUFVCTElDICIiCiAgICAg ICAgICAiaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNl LlJGQy4yNjE3LnhtbCI+CiAgICAgICAgPCFFTlRJVFkgcmZjMjYxNiBQVUJMSUMgIiIKICAgICAg ICAgICJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2Uu UkZDLjI2MTYueG1sIj4KICAgICAgICA8IUVOVElUWSByZmMyODE4IFBVQkxJQyAiIgogICAgICAg ICAgImh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5jZS5S RkMuMjgxOC54bWwiPgoKXT4KCgo8cmZjIGNhdGVnb3J5PSJzdGQiIGRvY05hbWU9ImRyYWZ0LWll dGYtZHJpbmtzLXNwcHAtb3Zlci1zb2FwLTA1IiAgaXByPSJ0cnVzdDIwMDkwMiI+Cgo8P3htbC1z dHlsZXNoZWV0IHR5cGU9J3RleHQveHNsJyBocmVmPSdyZmMyNjI5LnhzbHQnID8+Cgo8P3JmYyB0 b2M9InllcyIgPz4KPD9yZmMgc3ltcmVmcz0ieWVzIiA/Pgo8P3JmYyBzb3J0cmVmcz0ieWVzIj8+ Cjw/cmZjIGlwcm5vdGlmaWVkPSJubyIgPz4KPD9yZmMgc3RyaWN0PSJ5ZXMiID8+Cgo8ZnJvbnQ+ CiAgICAgICAgPHRpdGxlIGFiYnJldj0iZHJhZnQtaWV0Zi1kcmlua3Mtc3BwcC1vdmVyLXNvYXAi PlNQUFAgT3ZlciBTT0FQIGFuZCBIVFRQPC90aXRsZT4KCiAgICAgICAgPGF1dGhvciBpbml0aWFs cz0nSy5DLicgc3VybmFtZT0iQ2FydHdyaWdodCIgZnVsbG5hbWU9J0tlbm5ldGggQ2FydHdyaWdo dCc+CiAgICAgICAgICAgICAgICA8b3JnYW5pemF0aW9uPlROUzwvb3JnYW5pemF0aW9uPgogICAg ICAgICAgICAgICAgPGFkZHJlc3M+CiAgICAgICAgICAgICAgICAgICAgICAgIDxwb3N0YWw+CiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHN0cmVldD4xOTM5IFJvbGFuZCBDbGFya2Ug UGxhY2U8L3N0cmVldD4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8Y2l0eT5SZXN0 b248L2NpdHk+IDxyZWdpb24+VkE8L3JlZ2lvbj4gCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPGNvZGU+MjAxOTE8L2NvZGU+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PGNvdW50cnk+VVNBPC9jb3VudHJ5PgogICAgICAgICAgICAgICAgICAgICAgICA8L3Bvc3RhbD4K ICAgICAgICAgICAgICAgICAgICAgICAgPGVtYWlsPmtjYXJ0d3JpZ2h0QHRuc2kuY29tPC9lbWFp bD4KICAgICAgICAgICAgICAgIDwvYWRkcmVzcz4KICAgICAgICA8L2F1dGhvcj4KCiAgICAgICAg PGRhdGUgeWVhcj0iMjAxMSIgbW9udGg9IkF1Z3VzdCIvPgoKICAgIDxhcmVhPlJlYWwtdGltZSBB cHBsaWNhdGlvbnMgYW5kIEluZnJhc3RydWN0dXJlIEFyZWE8L2FyZWE+CgogICAgPHdvcmtncm91 cD5EUklOS1M8L3dvcmtncm91cD4KICAgIAogICAgPGFic3RyYWN0PgogICAgICA8dD5UaGUgU2Vz c2lvbiBQZWVyaW5nIFByb3Zpc2lvbmluZyBQcm90b2NvbCAoU1BQUCkgaXMgYW4gWE1MIHByb3Rv Y29sIAoJICB0aGF0IGV4aXN0cyB0byBlbmFibGUgdGhlIHByb3Zpc2lvbmluZyBvZiBzZXNzaW9u IGVzdGFibGlzaG1lbnQgZGF0YSBpbnRvICAKCSAgU2Vzc2lvbiBEYXRhIFJlZ2lzdHJpZXMgb3Ig U0lQIFNlcnZpY2UgUHJvdmlkZXIgZGF0YSBzdG9yZXMuICBTZW5kaW5nIFhNTCAKCSAgZGF0YSBz dHJ1Y3R1cmVzIG92ZXIgU2ltcGxlIE9iamVjdCBBY2Nlc3MgUHJvdG9jb2wgKFNPQVApIGFuZCBI VFRQKHMpIGlzIAoJICBhIHdpZGVseSB1c2VkLCBkZS1mYWN0byBzdGFuZGFyZCBmb3IgbWVzc2Fn aW5nIGJldHdlZW4gZWxlbWVudHMgb2YgCgkgIHByb3Zpc2lvbmluZyBzeXN0ZW1zLiAgVGhlcmVm b3JlIHRoZSBjb21iaW5hdGlvbiBvZiBTT0FQIGFuZCBIVFRQKHMpIGFzIAoJICBhIHRyYW5zcG9y dCBmb3IgU1BQUCBpcyBhIG5hdHVyYWwgZml0LiAgVGhlIG9idmlvdXMgYmVuZWZpdHMgaW5jbHVk ZSAKCSAgbGV2ZXJhZ2luZyBleGlzdGluZyBpbmR1c3RyeSBleHBlcnRpc2UsIGxldmVyYWdpbmcg ZXhpc3Rpbmcgc3RhbmRhcmRzLCAKCSAgYW5kIGEgaGlnaGVyIHByb2JhYmlsaXR5IHRoYXQgZXhp c3RpbmcgcHJvdmlzaW9uaW5nIHN5c3RlbXMgY2FuIGJlIG1vcmUgCgkgIGVhc2lseSBpbnRlZ3Jh dGVkIHdpdGggdGhpcyBwcm90b2NvbC4gIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSAKCSAg c3BlY2lmaWNhdGlvbiBmb3IgdHJhbnNwb3J0aW5nIFNQUFAgWE1MIHN0cnVjdHVyZXMgb3ZlciBT T0FQIGFuZCBIVFRQKHMpLgoJICA8L3Q+CiAgICA8L2Fic3RyYWN0PgogIDwvZnJvbnQ+CgogIDxt aWRkbGU+CiAgICA8c2VjdGlvbiB0aXRsZT0iSW50cm9kdWN0aW9uIj4KICAgICAgPHQ+U1BQUCwg ZGVmaW5lZCBpbiA8eHJlZiB0YXJnZXQ9IkktRC5kcmFmdC1pZXRmLWRyaW5rcy1zcHByb3YiLz4s CiAgICAgIGlzIGJlc3Qgc3VwcG9ydGVkIGJ5IGEgdHJhbnNwb3J0IGFuZCBtZXNzYWdpbmcgaW5m cmFzdHJ1Y3R1cmUgCgkgIHRoYXQgaXMgY29ubmVjdGlvbiBvcmllbnRlZCwgcmVxdWVzdC1yZXNw b25zZSBvcmllbnRlZCwgZWFzaWx5IHNlY3VyZWQsIAoJICBzdXBwb3J0cyBwcm9wYWdhdGlvbiB0 aHJvdWdoIGZpcmV3YWxscyBpbiBhIHN0YW5kYXJkIGZhc2hpb24sIGFuZCB0aGF0IAoJICBpcyBl YXNpbHkgaW50ZWdyYXRlZCBpbnRvIGJhY2stb2ZmaWNlIHN5c3RlbXMuICBUaGlzIGlzIGR1ZSB0 byB0aGUgZmFjdCB0aGF0IAoJICB0aGUgY2xpZW50IHNpZGUgb2YgU1BQUCBpcyBsaWtlbHkgdG8g YmUgaW50ZWdyYXRlZCB3aXRoIG9yZ2FuaXphdGlvbnMnIAoJICBvcGVyYXRpb25hbCBzdXBwb3J0 IHN5c3RlbXMgdGhhdCBmYWNpbGl0YXRlIHRyYW5zYWN0aW9uYWwgcHJvdmlzaW9uaW5nIG9mIHVz ZXIgIAoJICBhZGRyZXNzZXMgYW5kIHRoZWlyIGFzc29jaWF0ZWQgc2Vzc2lvbiBlc3RhYmxpc2ht ZW50IGRhdGEuICBXaGlsZSB0aGUgc2VydmVyICAKCSAgc2lkZSBvZiBTUFBQIGlzIGxpa2VseSB0 byByZXNpZGUgaW4gYSBzZXBhcmF0ZSBvcmdhbml6YXRpb24ncyBuZXR3b3JrLCByZXN1bHRpbmcg IAoJICB0aGUgU1BQUCBwcm92aXNpb25pbmcgdHJhbnNhY3Rpb25zIHRyYXZlcnNpbmcgdGhlIElu dGVybmV0IGFzIAoJICB0aGV5IGFyZSBwcm9wYWdhdGVkIGZyb20gdGhlIFNQUFAgY2xpZW50IHRv IHRoZSBTUFBQIHNlcnZlci4gIEdpdmVuIHRoZSAKCSAgY3VycmVudCBzdGF0ZSBvZiBpbmR1c3Ry eSBwcmFjdGljZSBhbmQgdGVjaG5vbG9naWVzLCAKCSAgU09BUCBhbmQgSFRUUChzKSBhcmUgd2Vs bCBzdWl0ZWQgZm9yIHRoaXMgdHlwZSBvZiBlbnZpcm9ubWVudC4gVGhpcyBkb2N1bWVudCAKCSAg ZGVzY3JpYmVzIHRoZSBzcGVjaWZpY2F0aW9uIGZvciB0cmFuc3BvcnRpbmcgU1BQUCBYTUwgc3Ry dWN0dXJlcyBvdmVyIAoJICBTT0FQIGFuZCBIVFRQKHMpLjwvdD4KICAgICAgPHQ+VGhlIHNwZWNp ZmljYXRpb24gaW4gdGhpcyBkb2N1bWVudCBmb3IgdHJhbnNwb3J0aW5nIFNQUFAgWE1MIHN0cnVj dHVyZXMgCgkgIG92ZXIgU09BUCBhbmQgSFRUUChzKSBpcyBwcmltYXJpbHkgY29tcHJpc2VkIG9m IGZpdmUgc3ViamVjdHM6ICAoMSkgYSAKCSAgZGVzY3JpcHRpb24gb2YgYW55IGFwcGxpY2FibGUg U09BUCBmZWF0dXJlcywgKDIpIGFueSBhcHBsaWNhYmxlIEhUVFAgCgkgIGZlYXR1cmVzLCAoMykg c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMsIGFuZCBwZXJoYXBzIG1vc3QgaW1wb3J0YW50bHksIAoJ ICAoNSkgdGhlIFdlYiBTZXJ2aWNlcyBEZXNjcmlwdGlvbiBMYW5ndWFnZSAoV1NETCkgZGVmaW5p dGlvbiBmb3IgU1BQUCBvdmVyIAoJICBTT0FQLjwvdD4KCTwvc2VjdGlvbj4KICAKICAgIDxzZWN0 aW9uIGFuY2hvcj0iVGVybWlub2xvZ3kiIHRpdGxlPSJUZXJtaW5vbG9neSI+CiAgICAgIDx0PlRo ZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hB TEwgTk9UIiwKICAgICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1B WSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMKICAgICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVy cHJldGVkIGFzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9IlJGQzIxMTkiLz4uPC90PgogICAg PC9zZWN0aW9uPgoKICAgIDxzZWN0aW9uIGFuY2hvcj0iU09BUEZlYXR1cmVzIiB0aXRsZT0iU09B UCBGZWF0dXJlcyBhbmQgU1BQUCI+CiAgICAgIDx0PlRoZSBsaXN0IG9mIFNPQVAgZmVhdHVyZXMg dGhhdCBhcmUgZXhwbGljaXRseSB1c2VkIGFuZCByZXF1aXJlZCBmb3IgU1BQUCBhcmUgbGltaXRl ZC4gIE1vc3QgU09BUCBmZWF0dXJlcyBhcmUgbm90IG5lY2Vzc2FyeSBmb3IgU1BQUC4gIFNQUFAg cHJpbWFyaWx5IHVzZXMgU09BUCBzaW1wbHkgYXMgYSBzdGFuZGFyZCBtZXNzYWdlIGVudmVsb3Bl IHRlY2hub2xvZ3kuICBUaGUgU09BUCBtZXNzYWdlIGVudmVsb3BlIGlzIGNvbXByaXNlZCBvZiB0 aGUgU09BUCBoZWFkZXIgYW5kIGJvZHkuICBBcyBkZXNjcmliZWQgaW4gdGhlIFNPQVAgc3BlY2lm aWNhdGlvbnMsIHRoZSBTT0FQIGhlYWRlciBjYW4gY29udGFpbiBvcHRpb25hbCwgYXBwbGljYXRp b24gc3BlY2lmaWMsIGluZm9ybWF0aW9uIGFib3V0IHRoZSBtZXNzYWdlLiAgVGhlIFNPQVAgYm9k eSBjb250YWlucyB0aGUgU1BQUCBtZXNzYWdlIGl0c2VsZiwgd2hvc2Ugc3RydWN0dXJlIGlzIGRl ZmluZWQgYnkgdGhlIGNvbWJpbmF0aW9uIG9mIG9uZSBvZiB0aGUgV1NETCBvcGVyYXRpb25zIGRl ZmluZWQgaW4gdGhpcyBkb2N1bWVudCBhbmQgdGhlIFNQUFAgWE1MIGRhdGEgc3RydWN0dXJlcyBk ZWZpbmVkIGluIHRoZSBTUFBQIHByb3RvY29sIGRvY3VtZW50LiAgU1BQUCBkb2VzIG5vdCByZWx5 IG9uIGFueSBkYXRhIGVsZW1lbnRzIGluIHRoZSBTT0FQIGhlYWRlci4gIEFsbCByZWxldmFudCBk YXRhIGVsZW1lbnRzIGFyZSBkZWZpbmVkIGluIHRoZSBTUFBQIFhNTCBzY2hlbWEgZGVzY3JpYmVk IGluIDx4cmVmIHRhcmdldD0iSS1ELmRyYWZ0LWlldGYtZHJpbmtzLXNwcHJvdiIvPiBhbmQgdGhl IFNQUFAgV1NETCBzcGVjaWZpY2F0aW9uIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50LjwvdD4K CSAgPHQ+V1NETCBpcyBhIHdpZGVseSBzdGFuZGFyZGl6ZWQgYW5kIGFkb3B0ZWQgdGVjaG5vbG9n eSBmb3IgZGVmaW5pbmcgdGhlIHRvcC1sZXZlbCBzdHJ1Y3R1cmVzIG9mIHRoZSBtZXNzYWdlcyB0 aGF0IGFyZSB0cmFuc3BvcnRlZCB3aXRoaW4gdGhlIGJvZHkgb2YgYSBTT0FQIG1lc3NhZ2UuICBU aGUgV1NETCBkZWZpbml0aW9uIGZvciB0aGUgU1BQUCBTT0FQIG1lc3NhZ2VzIGlzIGRlZmluZWQg bGF0ZXIgaW4gdGhpcyBkb2N1bWVudCwgd2hpY2ggaW1wb3J0cyBieSByZWZlcmVuY2UgdGhlIFhN TCBkYXRhIHR5cGVzIGNvbnRhaW5lZCBpbiB0aGUgU1BQUCBzY2hlbWEuICBUaGUgSUFOQSByZWdp c3RyeSB3aGVyZSB0aGUgU1BQUCBzY2hlbWEgcmVzaWRlcyBpcyBkZXNjcmliZWQgaW4gVGhlIElF VEYgWE1MIFJlZ2lzdHJ5IDx4cmVmIHRhcmdldD0iUkZDMzY4OCIvPi48L3Q+CgkgIDx0PlRoZXJl IGFyZSBtdWx0aXBsZSBzdHJ1Y3R1cmFsIHN0eWxlcyB0aGF0IFNPQVAgV1NETCBhbGxvd3MuICBC dXQgdGhlIGJlc3QgcHJhY3RpY2UgZm9yIHRoaXMgdHlwZSBvZiBhcHBsaWNhdGlvbiBpcyB3aGF0 IGlzIHNvbWV0aW1lcyByZWZlcnJlZCB0byBhcyB0aGUgRG9jdW1lbnQgTGl0ZXJhbCBXcmFwcGVk IHN0eWxlIG9mIGRlc2lnbmluZyBTT0FQIFdTREwuICBUaGlzIHN0eWxlIGlzIGdlbmVyYWxseSBy ZWdhcmRlZCBhcyBhbiBvcHRpbWFsIGFwcHJvYWNoIHRoYXQgZW5oYW5jZXMgbWFpbnRhaW5hYmls aXR5LCBjb21wcmVoZW5zaW9uLCBwb3J0YWJpbGl0eSwgYW5kLCB0byBhIGNlcnRhaW4gZXh0ZW50 LCBwZXJmb3JtYW5jZS4gIEl0IGlzIGNoYXJhY3Rlcml6ZWQgYnkgc2V0dGluZyB0aGUgc29hcEFj dGlvbiBiaW5kaW5nIHN0eWxlIGFzIF9kb2N1bWVudF8sIHRoZSBzb2FwQWN0aW9uIGVuY29kaW5n IHN0eWxlIGFzIF9saXRlcmFsXywgYW5kIHRoZW4gZGVmaW5pbmcgdGhlIFNPQVAgbWVzc2FnZXMg dG8gc2ltcGx5IGNvbnRhaW4gYSBzaW5nbGUgZGF0YSBlbGVtZW50IHRoYXQgX3dyYXBzXyB0aGF0 IGlzIGEgZGF0YSBzdHJ1Y3R1cmUgY29udGFpbmluZyBhbGwgdGhlIHJlcXVpcmVkIGlucHV0IG9y IG91dHB1dCBkYXRhIGVsZW1lbnRzLiBUaGUgZmlndXJlIGJlbG93IGlsbHVzdHJhdGVzIHRoaXMg aGlnaCBsZXZlbCB0ZWNobmljYWwgc3RydWN0dXJlLjwvdD4KCSAgCgkgPGZpZ3VyZSBhbmNob3I9 IlRlY2huaWNhbFN0cnVjdHVyZW9mU1BQUCIgCgkgdGl0bGU9IlRlY2huaWNhbCBTdHJ1Y3R1cmUg b2YgdGhlIFNQUFAgU09BUCBNZXNzYWdlcyI+CiAgICAgICAgPGFydHdvcmsgYWxpZ249ImxlZnQi PjwhW0NEQVRBWwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0t LSsKICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLXwgICAgU09BUCAgICAgICB8LS0tLS0t KwogICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgfCAgT3BlcmF0aW9uICAgIHwgICAgICB8 CiAgICAgICAgICAgICAgQ29udGFpbnMgfCAgICAgICstLS0tLS0tLS0tLS0tLS0tKyAgICAgIHwg Q29udGFpbnMKICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgIEV4YW1wbGU6ICAgICAg ICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgIFYgICAgICBzdWJtaXRVcGRhdGVScXN0ICAg ICAgICBWCiAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLSsgICAgICAgICAgICstLS0tLS0t LS0tLS0tKwogICAgICAgICAgICAgICB8U09BUCBSZXF1ZXN0ICB8ICAgICAgICAgICB8U09BUCBS ZXNwb25zZXwKICAgICAgIEV4YW1wbGU6fCAgTWVzc2FnZSAgICAgfCAgICAgICAgICAgfCAgIE1l c3NhZ2UgICB8IEV4YW1wbGU6CiBzcHBwVXBkYXRlICAgIHwgKE9wZXJhdGlvbiAgIHwgICAgICAg ICAgIHwgKE9wZXJhdGlvbiAgfHNwcHBVcGRhdGUKICAgIFJlcXVlc3RNc2cgfCAgIElucHV0KSAg ICAgfCAgICAgICAgICAgfCAgT3V0cHV0KSAgICB8ICAgUmVzcG9uc2VNc2cKICAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgQ29u dGFpbnMgfCAgICAgICAgICAgICAgICAgICAgICAgfCBDb250YWlucwogICAgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAg IFYgICAgICAgICAgICAgICAgICAgICAgIFYKICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0t KyAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgICAgIEV4YW1wbGU6fCAgICBXcmFwcGVkICAg IHwgICAgICAgICB8ICBXcmFwcGVkICAgICAgfCBFeGFtcGxlOgogIHNwcHBVcGRhdGUgIHxSZXF1 ZXN0IE9iamVjdCB8ICAgICAgICAgfFJlc3BvbnNlIE9iamVjdHwgc3BwcFVwZGF0ZQogICAgICBS ZXF1ZXN0ICstLS0tLS0tLS0tLS0tLS0rICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsgICAgIFJl c3BvbnNlCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgICAgICAgICAgICAgQ29udGFpbnMgfCAgICAgICAgICAgICAgICAgICAgICAgfCBDb250YWlu cwogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAg ICAgICAgICAgICAgICAgICAgIFYgICAgICAgICAgICAgICAgICAgICAgIFYKICAgICAgICAgICAg ICArLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAg ICAgICAgICB8ICAgICAgU1BQUCAgICAgfCAgICAgICAgfCAgICAgICBTUFBQICAgICAgICAgIHwK ICAgICAgICAgICAgICB8ICAgWE1MIFR5cGVzICAgfCAgICAgICAgfCAgICAgWE1MIFR5cGVzICAg ICAgIHwKICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgKy0tLS0tLS0tLS0t LS0tLS0tLS0tLSsKICAgICAgICBdXT48L2FydHdvcms+CiAgICAgPC9maWd1cmU+CgkgIAoJICA8 dD5UaGUgU09BUCBvcGVyYXRpb25zIHN1cHBvcnRlZCBieSBTUFBQIGFyZSBub3JtYXRpdmVseSBk ZWZpbmVkIGxhdGVyIGluIHRoaXMgCgkgIGRvY3VtZW50LiAgRWFjaCBTT0FQIG9wZXJhdGlvbiBk ZWZpbmVzIGEgcmVxdWVzdC9pbnB1dCBtZXNzYWdlIGFuZCBhIAoJICByZXNwb25zZS9vdXRwdXQg bWVzc2FnZS4gIEVhY2ggc3VjaCByZXF1ZXN0IGFuZCByZXNwb25zZSBtZXNzYWdlIHRoZW4gCgkg IGNvbnRhaW5zIGEgc2luZ2xlIG9iamVjdCB0aGF0IHdyYXBzIHRoZSBTUFBQIFhNTCBkYXRhIHR5 cGVzIHRoYXQgY29tcHJpc2UgCgkgIHRoZSBpbnB1dHMgYW5kIHRoZSBvdXRwdXRzLCByZXNwZWN0 aXZlbHksIG9mIHRoZSBTT0FQIG9wZXJhdGlvbi48L3Q+CgkgIDx0PlNPQVAgZmF1bHRzIGFyZSBu b3QgdXNlZCBieSB0aGUgU1BQUCBTT0FQIG1hcHBpbmcuICBBbGwgU1BQUCBzdWNjZXNzIAoJICBh bmQgZXJyb3IgcmVzcG9uc2VzIGFyZSBzcGVjaWZpZWQgd2l0aGluIHRoZSBTUFBQIHByb3RvY29s IHNwZWNpZmljYXRpb24gCgkgIDx4cmVmIHRhcmdldD0iSS1ELmRyYWZ0LWlldGYtZHJpbmtzLXNw cHJvdiIvPi4gIEhvd2V2ZXIsIGlmIGEgU09BUCBmYXVsdCB3ZXJlIAoJICB0byBvY2N1ciwgcGVy aGFwcyBkdWUgdG8gZmFpbHVyZXMgaW4gdGhlIFNPQVAgbWVzc2FnZSBoYW5kbGluZyBsYXllciBv ZiBhIFNPQVAgCgkgIGxpYnJhcnksIHRoZSBjbGllbnQgYXBwbGljYXRpb24gc2hvdWxkIGNhcHR1 cmUgYW5kIGhhbmRsZSB0aGUgZmF1bHQuICBTcGVjaWZpY3MgCgkgIG9uIGhvdyB0byBoYW5kbGUg c3VjaCBTT0FQIGZhdWx0cywgaWYgdGhleSBzaG91bGQgb2NjdXIsIHdpbGwgYmUgc3BlY2lmaWMg dG8gCgkgIHRoZSBjaG9zZW4gU09BUCBpbXBsZW1lbnRhdGlvbi4gPC90PgoJICA8dD5TT0FQIDEu MiA8eHJlZiB0YXJnZXQ9IlNPQVBSRUYiLz4gb3IgaGlnaGVyIGFuZCBXU0RMIDEuMSA8eHJlZiB0 YXJnZXQ9IldTRExSRUYiLz4gb3IgaGlnaGVyIFNIT1VMRCBiZSB1c2VkLjwvdD4KCTwvc2VjdGlv bj4KCiAgICA8c2VjdGlvbiBhbmNob3I9IkhUVFBGZWF0dXJlcyIgdGl0bGU9IkhUVFAocykgRmVh dHVyZXMgYW5kIFNQUFAiPgogICAgICA8dD5TT0FQIGlzIG5vdCB0aWVkIHRvIEhUVFAocyksIGhv d2V2ZXIsIGZvciByZWFzb25zIGRlc2NyaWJlZCBpbiB0aGUgCgkgIGludHJvZHVjdGlvbiwgSFRU UChzKSBpcyBhIGdvb2QgY2hvaWNlIGFzIHRoZSB0cmFuc3BvcnQgbWVjaGFuaXNtIGZvciAKCSAg dGhlIFNQUFAgU09BUCBtZXNzYWdlcy4gIEhUVFAgMS4xIGluY2x1ZGVzIHRoZSAmcXVvdDtwZXJz aXN0ZW50IGNvbm5lY3Rpb24mcXVvdDsgCgkgIGZlYXR1cmUsIHdoaWNoIGFsbG93cyBtdWx0aXBs ZSBIVFRQIHJlcXVlc3QvcmVzcG9uc2UgcGFpcnMgdG8gYmUgdHJhbnNwb3J0ZWQgCgkgIGFjcm9z cyBhIHNpbmdsZSBIVFRQIGNvbm5lY3Rpb24uICBUaGlzIGlzIGFuIGltcG9ydGFudCBwZXJmb3Jt YW5jZSAKCSAgb3B0aW1pemF0aW9uIGZlYXR1cmUsIHBhcnRpY3VsYXJseSB3aGVuIHRoZSBjb25u ZWN0aW9ucyBpcyBhbiBIVFRQUyAKCSAgY29ubmVjdGlvbiB3aGVyZSB0aGUgcmVsYXRpdmVseSB0 aW1lIGNvbnN1bWluZyBTU0wgaGFuZHNoYWtlIGhhcyBvY2N1cnJlZC4gIAoJICBQZXJzaXN0ZW50 IGNvbm5lY3Rpb25zIFNIT1VMRCBiZSB1c2VkIGZvciB0aGUgU1BQUCBIVFRQIGNvbm5lY3Rpb25z LjwvdD4gCgkgIDx0PkhUVFAgMS4xIDx4cmVmIHRhcmdldD0iUkZDMjYxNiIvPiBvciBoaWdoZXIg U0hPVUxEIGJlIHVzZWQuPC90PgogICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gYW5jaG9yPSJB dXRoZW50aWNhdGlvblNlc3Npb25NYW5hZ2VtZW50IiB0aXRsZT0iQXV0aGVudGljYXRpb24gYW5k IFNlc3Npb24gTWFuYWdlbWVudCI+CiAgICAgIAogICAgICA8dD5UbyBhY2hpZXZlIGludGVncml0 eSBhbmRwcml2YWN5LCBjb25mb3JtaW5nIFNQUFAgU09BUCBDbGllbnRzIGFuZCBTZXJ2ZXJzIE1V U1Qgc3VwcG9ydCBTT0FQIG92ZXIgSFRUUCBvdmVyIFRMUyBbPHhyZWYgdGFyZ2V0PSJSRkM1MjQ2 Ii8+XSBhcyB0aGUgc2VjdXJlIHRyYW5zcG9ydCBtZWNoYW5pc20uICBUaGlzIGNvbWJpbmF0aW9u IG9mIEhUVFAgYW5kIFRMUyBpcyByZWZlcnJlZCB0byBhcyBIVFRQUy4gIEFuZCB0byBhY2NvbXBs aXNoIGF1dGhlbnRpY2F0aW9uIGNvbmZvcm1haW5nIFNPQVAgU1BQUCBDbGllbnRzIGFuZCBTZXJ2 ZXJzIE1VU1QgdXNlIEhUVFAgRGlnZXN0IEF1dGhlbnRpY2F0aW9uIGFzIGRlZmluZWQgaW4gPHhy ZWYgdGFyZ2V0PSJSRkMyNjE3Ii8+LiAgQXMgYSByZXN1bHQsIHRoZSBjb21tdW5pY2F0aW9uIHNl c3Npb24gaXMgZXN0YWJsaXNoZWQgdGhyb3VnaCB0aGUgaW5pdGlhbCBIVFRQIGNvbm5lY3Rpb24g c2V0dXAsIHRoZSBkaWdlc3QgYXV0aGVudGljYXRpb24sIGFuZCB0aGUgVExTIGhhbmRzaGFrZS4g IFdoZW4gdGhlIEhUVFAgY29ubmVjdGlvbiBpcyBicm9rZW4gZG93biwgdGhlIGNvbW11bmljYXRp b24gc2Vzc2lvbiBlbmRzLjwvdD4KICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlvbiBhbmNob3I9 IlNQUFBXU0RMIiB0aXRsZT0iU1BQUCBTT0FQIFdTREwgRGVmaW5pdGlvbiI+CiAgICAgIDx0PlRo ZSBTUFBQIFdTREwgaXMgZGVmaW5lZCBiZWxvdy4gIFRoZSBXU0RMIGRlc2lnbiBhcHByb2FjaCBp cyBjb21tb25seSByZWZlcnJlZCB0byBhcyBfR2VuZXJpYyBXU0RMXy4gIEl0IGlzIGdlbmVyaWMg aW4gdGhlIHNlbnNlIHRoYXQgdGhlcmUgaXMgbm90IGEgc3BlY2lmaWMgV1NETCBvcGVyYXRpb24g ZGVmaW5lZCBmb3IgZWFjaCBvYmplY3QgdHlwZSB0aGF0IGlzIHN1cHBvcnRlZCBieSB0aGUgU1BQ UCBwcm90b2NvbC4gIFRoZXJlIGlzIGEgc2luZ2xlIFdTREwgdXBkYXRlIG9wZXJhdGlvbiBjYWxs ZWQgc3VibWl0VXBkYXRlUnFzdCwgYW5kIGEgc2luZ2xlIFdTREwgcXVlcnkgb3BlcmF0aW9uIGNh bGxlZCBzdWJtaXRRdWVyeVJxc3QuICBUaGUgc3VibWl0VXBkYXRlUnFzdCBvcGVyYXRpb24gdGFr ZXMgYXMgaW5wdXQgYW4gc3BwcFVwZGF0ZVJlcXVlc3RNc2cgb2JqZWN0IGFuZCByZXR1cm5zIGFz IG91dHB1dCBhbiBzcHBwVXBkYXRlUmVzcG9uc2VNc2cgb2JqZWN0LiAgVGhlc2Ugb2JqZWN0cyBf d3JhcF8gdGhlIHNwcHBVcGRhdGVSZXF1ZXN0IGFuZCBzcHBwVXBkYXRlUmVzcG9uc2Ugb2JqZWN0 cyByZXNwZWN0aXZlbHkuICBUaGVzZSB0d28gb2JqZWN0IGRhdGEgc3RydWN0dXJlcyBhcmUgZGVz Y3JpYmVkIGluIHRoZSBTUFBQIHByb3RvY29sIHNwZWNpZmljYXRpb24gPHhyZWYgdGFyZ2V0PSJJ LUQuZHJhZnQtaWV0Zi1kcmlua3Mtc3Bwcm92Ii8+LiAgQW5kIGZpbmFsbHksIHRoZSBzcHBwU09B UEJpbmRpbmcgaW4gdGhlIFdTREwgZGVmaW5lcyB0aGUgYmluZGluZyBzdHlsZSBhcyBfZG9jdW1l bnRfIGFuZCB0aGUgZW5jb2RpbmcgYXMgX2xpdGVyYWxfLiAgSXQgaXMgdGhpcyBjb21iaW5hdGlv biBvZiBfd3JhcHBlZF8gaW5wdXQgYW5kIG91dHB1dCBkYXRhIHN0cnVjdHVyZXMsIF9kb2N1bWVu dF8gYmluZGluZyBzdHlsZSwgYW5kIF9saXRlcmFsXyBlbmNvZGluZyB0aGF0IGNoYXJhY3Rlcml6 ZSB0aGUgRG9jdW1lbnQgTGl0ZXJhbCBXcmFwcGVkIHN0eWxlIG9mIFdTREwgc3BlY2lmaWNhdGlv bnMuPC90Pgo8dD5UaGUgYWR2YW50YWdlIG9mIGdlbmVyaWMgV1NETCBpcyB0aGF0IHRoZSBXU0RM IGlzIG1vcmUgc3VjY2luY3QsIG11Y2ggc2ltcGxlciwgYW5kIHRoZXJmb3JlIG1vcmUgZWFzaWx5 IG1haW50YWluZWQuICBBcyBuZXcgdHlwZXMgb2YgcHJvdG9jb2wgb2JqZWN0cyBhbmQgYWN0aW9u cyBhcmUgYWRkZWQgaW50byBvciByZW1vdmVkIGZyb20gdGhlIFNQUFAgcHJvdG9jb2wsIHRoZSBX U0RMIGRvZXMgbm90IG5lZWQgdG8gY2hhbmdlLiAgVGhpcyBhcHByb2FjaCBpcyBtYWRlIHBvc3Np YmxlIGJ5IHRoZSBmYWN0IHRoYXQgdGhlIFNQUCBYTUwgZGF0YSB0eXBlcyBhbmQgc3VwcG9ydGVk IGFjdGlvbnMgYXJlIGRlZmluZWQgaW4gdGhlIFNQUFAgWE1MIHNjaGVtYSwgbm90IGluIHRoZSBX U0RMLiAgQXMgYSByZXN1bHQgdGhlIHN1cHBvcnRlZCBhY3Rpb25zIGRvIG5vdCBuZWVkIHRvIGJl IHJlLWRlZmluZWQgaGVyZSBpbnNpZGUgdGhlIFNQUFAgU09BUCBXU0RMLjwvdD4KCgk8dD4KCQlO b3RlOiBUaGUgZm9sbG93aW5nIFdTREwgaGFzIGJlZW4gZm9ybWF0dGVkIChlLmcuLCB0YWJzLCBz cGFjZXMpIHRvIG1lZXQgSS1EIHJlcXVpcmVtZW50cy4KCTwvdD4KCiAgICAgIDx0PgoJICAJIDxm aWd1cmUgYW5jaG9yPSJXU0RMIiB0aXRsZT0iV1NETCI+CiAgICAgICAgPGFydHdvcmsgYWxpZ249 ImxlZnQiPjwhW0NEQVRBWwoKPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4K PHdzZGw6ZGVmaW5pdGlvbnMgeG1sbnM6d3NkbD0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcv d3NkbC8iIAogeG1sbnM6c29hcD0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvd3NkbC9zb2Fw LyIgCiB4bWxuczp4c2Q9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hIiAKIHhtbG5z OnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIAogeG1sbnM6 c3BwcGI9InVybjppZXRmOnBhcmFtczp4bWw6bnM6c3BwcDpiYXNlOjEiIAogeG1sbnM6c3BwcHM9 InVybjppZXRmOnBhcmFtczp4bWw6bnM6c3BwcDpzb2FwOjEiIAogdGFyZ2V0TmFtZXNwYWNlPSJ1 cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnNwcHA6c29hcDoxIiAKIHhzaTpzY2hlbWFMb2NhdGlvbj0i c3BwcGJhc2UueHNkIj4KCTx3c2RsOnR5cGVzPgogPHhzZDpzY2hlbWE+CiAgICAgICAgICA8eHNk OmltcG9ydCBuYW1lc3BhY2U9InVybjppZXRmOnBhcmFtczp4bWw6bnM6c3BwcDpiYXNlOjEiIAog ICAgICAgICAgICAgICAgICAgICAgc2NoZW1hTG9jYXRpb249InNwcHBiYXNlLnhzZCIvPgogPC94 c2Q6c2NoZW1hPgogPC93c2RsOnR5cGVzPgogPHdzZGw6bWVzc2FnZSBuYW1lPSJzcHBwVXBkYXRl UmVxdWVzdE1zZyI+CiAgPHdzZGw6cGFydCBuYW1lPSJycXN0IiBlbGVtZW50PSJzcHBwYjpzcHBw VXBkYXRlUmVxdWVzdCIvPgogPC93c2RsOm1lc3NhZ2U+CiA8d3NkbDptZXNzYWdlIG5hbWU9InNw cHBVcGRhdGVSZXNwb25zZU1zZyI+CiAgPHdzZGw6cGFydCBuYW1lPSJyc3BucyIgZWxlbWVudD0i c3BwcGI6c3BwcFVwZGF0ZVJlc3BvbnNlIi8+CiA8L3dzZGw6bWVzc2FnZT4KIDx3c2RsOm1lc3Nh Z2UgbmFtZT0ic3BwcFF1ZXJ5UmVxdWVzdE1zZyI+CiAgPHdzZGw6cGFydCBuYW1lPSJycXN0IiBl bGVtZW50PSJzcHBwYjpzcHBwUXVlcnlSZXF1ZXN0Ii8+CiA8L3dzZGw6bWVzc2FnZT4KIDx3c2Rs Om1lc3NhZ2UgbmFtZT0ic3BwcFF1ZXJ5UmVzcG9uc2VNc2ciPgogIDx3c2RsOnBhcnQgbmFtZT0i cnNwbnMiIGVsZW1lbnQ9InNwcHBiOnNwcHBRdWVyeVJlc3BvbnNlIi8+CiA8L3dzZGw6bWVzc2Fn ZT4KIDx3c2RsOm1lc3NhZ2UgbmFtZT0ic3BwcFNlcnZlclN0YXR1c1JlcXVlc3RNc2ciPgogIDx3 c2RsOnBhcnQgbmFtZT0icnFzdCIgZWxlbWVudD0ic3BwcGI6c3BwcFNlcnZlclN0YXR1c1JlcXVl c3QiLz4KIDwvd3NkbDptZXNzYWdlPgogPHdzZGw6bWVzc2FnZSBuYW1lPSJzcHBwU2VydmVyU3Rh dHVzUmVzcG9uc2VNc2ciPgogIDx3c2RsOnBhcnQgbmFtZT0icnNwbnMiIGVsZW1lbnQ9InNwcHBi OnNwcHBTZXJ2ZXJTdGF0dXNSZXNwb25zZSIvPgogPC93c2RsOm1lc3NhZ2U+CiA8d3NkbDpwb3J0 VHlwZSBuYW1lPSJzcHBwUG9ydFR5cGUiPgogIDx3c2RsOm9wZXJhdGlvbiBuYW1lPSJzdWJtaXRV cGRhdGVScXN0Ij4KICAgPHdzZGw6aW5wdXQgbWVzc2FnZT0ic3BwcHM6c3BwcFVwZGF0ZVJlcXVl c3RNc2ciLz4KICAgPHdzZGw6b3V0cHV0IG1lc3NhZ2U9InNwcHBzOnNwcHBVcGRhdGVSZXNwb25z ZU1zZyIvPgogIDwvd3NkbDpvcGVyYXRpb24+CiAgPHdzZGw6b3BlcmF0aW9uIG5hbWU9InN1Ym1p dFF1ZXJ5UnFzdCI+CiAgIDx3c2RsOmlucHV0IG1lc3NhZ2U9InNwcHBzOnNwcHBRdWVyeVJlcXVl c3RNc2ciLz4KICAgPHdzZGw6b3V0cHV0IG1lc3NhZ2U9InNwcHBzOnNwcHBRdWVyeVJlc3BvbnNl TXNnIi8+CiAgPC93c2RsOm9wZXJhdGlvbj4KICA8d3NkbDpvcGVyYXRpb24gbmFtZT0ic3VibWl0 U2VydmVyU3RhdHVzUnFzdCI+CiAgIDx3c2RsOmlucHV0IG1lc3NhZ2U9InNwcHBzOnNwcHBTZXJ2 ZXJTdGF0dXNSZXF1ZXN0TXNnIi8+CiAgIDx3c2RsOm91dHB1dCBtZXNzYWdlPSJzcHBwczpzcHBw U2VydmVyU3RhdHVzUmVzcG9uc2VNc2ciLz4KICA8L3dzZGw6b3BlcmF0aW9uPgogPC93c2RsOnBv cnRUeXBlPgogPHdzZGw6YmluZGluZyBuYW1lPSJzcHBwU29hcEJpbmRpbmciIHR5cGU9InNwcHBz OnNwcHBQb3J0VHlwZSI+CiAgPHNvYXA6YmluZGluZyBzdHlsZT0iZG9jdW1lbnQiIAoJCXRyYW5z cG9ydD0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9odHRwIi8+CiAgPHdzZGw6b3Bl cmF0aW9uIG5hbWU9InN1Ym1pdFVwZGF0ZVJxc3QiPgogICA8c29hcDpvcGVyYXRpb24gc29hcEFj dGlvbj0ic3VibWl0VXBkYXRlUnFzdCIgc3R5bGU9ImRvY3VtZW50Ii8+CiAgIDx3c2RsOmlucHV0 PgogICAgPHNvYXA6Ym9keSB1c2U9ImxpdGVyYWwiLz4KICAgPC93c2RsOmlucHV0PgogICA8d3Nk bDpvdXRwdXQ+CiAgICA8c29hcDpib2R5IHVzZT0ibGl0ZXJhbCIvPgogICA8L3dzZGw6b3V0cHV0 PgogIDwvd3NkbDpvcGVyYXRpb24+CiAgPHdzZGw6b3BlcmF0aW9uIG5hbWU9InN1Ym1pdFF1ZXJ5 UnFzdCI+CiAgIDxzb2FwOm9wZXJhdGlvbiBzb2FwQWN0aW9uPSJzdWJtaXRRdWVyeVJxc3QiIHN0 eWxlPSJkb2N1bWVudCIvPgogICA8d3NkbDppbnB1dD4KICAgIDxzb2FwOmJvZHkgdXNlPSJsaXRl cmFsIi8+CiAgIDwvd3NkbDppbnB1dD4KICAgPHdzZGw6b3V0cHV0PgogICAgPHNvYXA6Ym9keSB1 c2U9ImxpdGVyYWwiLz4KICAgPC93c2RsOm91dHB1dD4KICA8L3dzZGw6b3BlcmF0aW9uPgogIDx3 c2RsOm9wZXJhdGlvbiBuYW1lPSJzdWJtaXRTZXJ2ZXJTdGF0dXNScXN0Ij4KICA8c29hcDpvcGVy YXRpb24gc29hcEFjdGlvbj0ic3VibWl0U2VydmVyU3RhdHVzUnFzdCIgc3R5bGU9ImRvY3VtZW50 Ii8+CiAgIDx3c2RsOmlucHV0PgogICAgPHNvYXA6Ym9keSB1c2U9ImxpdGVyYWwiLz4KICAgPC93 c2RsOmlucHV0PgogICA8d3NkbDpvdXRwdXQ+CiAgICA8c29hcDpib2R5IHVzZT0ibGl0ZXJhbCIv PgogICA8L3dzZGw6b3V0cHV0PgogIDwvd3NkbDpvcGVyYXRpb24+CiA8L3dzZGw6YmluZGluZz4K IDx3c2RsOnNlcnZpY2UgbmFtZT0ic3BwcFNlcnZpY2UiPgogIDx3c2RsOnBvcnQgbmFtZT0ic3Bw cFBvcnQiIGJpbmRpbmc9InNwcHBzOnNwcHBTb2FwQmluZGluZyI+CiAgIDxzb2FwOmFkZHJlc3Mg bG9jYXRpb249IlJFUExBQ0VfV0lUSF9BQ1RVQUxfVVJMIi8+CiAgPC93c2RsOnBvcnQ+CiA8L3dz ZGw6c2VydmljZT4KPC93c2RsOmRlZmluaXRpb25zPgoKICAgICAgIF1dPjwvYXJ0d29yaz4KICAg ICA8L2ZpZ3VyZT48L3Q+CiAgICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gYW5jaG9yPSJTUFBQ RXhhbXBsZXMiIHRpdGxlPSJTUFBQIFNPQVAgRXhhbXBsZXMiPgogICAgICA8dD5UaGlzIHNlY3Rp b24gcHJvdmlkZXMgYSBmZXcgZXhhbXBsZXMgb2YgU1BQUCBTT0FQIG1lc3NhZ2VzLiAgVGhpcyBz ZWN0aW9uIG9mIGNvdXJzZSAKICAgICAgcmVsaWVzIG9uIHRoZSBYTUwgZGF0YSBzdHJ1Y3R1cmVz IGRlZmluZWQgaW4gdGhlIFNQUFAgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiA8eHJlZiB0YXJnZXQ9 IkktRC5kcmFmdC1pZXRmLWRyaW5rcy1zcHByb3YiLz4uICBTbyByZWZlciB0byB0aGF0IGRvY3Vt ZW50IHRvIHVuZGVyc3RhbmQgWE1MIG9iamVjdCB0eXBlcyBlbWJlZGRlZCBpbiB0aGVzZSBleGFt cGxlIG1lc3NhZ2VzLjwvdD4KCgk8dD4KCQlOb3RlOiBUaGUgZm9sbG93aW5nIGV4YW1wbGVzIGhh dmUgYmVlbiBmb3JtYXR0ZWQgKGUuZy4sIHRhYnMsIHNwYWNlcykgdG8gbWVldCBJLUQgcmVxdWly ZW1lbnRzLgoJPC90PgogICAgPHQ+CgkgIAk8ZmlndXJlIGFuY2hvcj0iRXhhbXBsZTEiIHRpdGxl PSJFeGFtcGxlIDEgLSBTUFBQIFVwZGF0ZSBSZXF1ZXN0IC0gQWRkIERlc3RpbmF0aW9uIEdyb3Vw Ij4KICAgICAgICA8YXJ0d29yayBhbGlnbj0ibGVmdCI+CiAgICAgICAgPCFbQ0RBVEFbCjxzb2Fw ZW52OkVudmVsb3BlIAp4bWxuczpzb2FwZW52PSJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy9z b2FwL2VudmVsb3BlLyIgCnhtbG5zOnNwYj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzcHBwOmJh c2U6MSI+CiAgPHNvYXBlbnY6SGVhZGVyLz4KICA8c29hcGVudjpCb2R5PgogICAgICA8c3BiOnNw cHBVcGRhdGVSZXF1ZXN0IAogICAgICB4c2k6c2NoZW1hTG9jYXRpb249InVybjppZXRmOnBhcmFt czp4bWw6bnM6c3BwcDpiYXNlOjEgc3BwcC54c2QiIAogICAgICB4bWxucz0idXJuOmlldGY6cGFy YW1zOnhtbDpuczpzcHBwOmJhc2U6MSIgICAKICAgICAgeG1sbnM6eHNpPSJodHRwOi8vd3d3Lncz Lm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0YW5jZSI+CiAgICAgICAgICA8c3BiOmNsaWVudFRyYW5z SWQ+ODg4PC9zcGI6Y2xpZW50VHJhbnNJZD4KICAgICAgICAgIDxzcGI6bWlub3JWZXI+MTwvc3Bi Om1pbm9yVmVyPgogICAgICAgICAgPHNwYjpycXN0IHhzaTp0eXBlPSJzcGI6QWRkRGVzdEdycFJx c3RUeXBlIj4KICAgICAgICAgICAgPHNwYjpkZXN0R3JwPgogICAgICAgICAgICAgICA8c3BiOnJh bnQ+cmVnaXN0cmFudDI8L3NwYjpyYW50PgogCSAgICAgICAgICAgPHNwYjpkZ05hbWU+REVTVF9H UlBfU1BQUF81PC9zcGI6ZGdOYW1lPgogICAgICAgICAgICA8L3NwYjpkZXN0R3JwPgogICAgICAg ICAgPC9zcGI6cnFzdD4KICAgICAgIDwvc3BiOnNwcHBVcGRhdGVSZXF1ZXN0PgogIDwvc29hcGVu djpCb2R5Pgo8L3NvYXBlbnY6RW52ZWxvcGU+CiAgICAgICBdXT4KICAgICAgIDwvYXJ0d29yaz4K ICAgICAgIDwvZmlndXJlPgogICAgPC90PgogICAgPHQ+CgkgIAk8ZmlndXJlIGFuY2hvcj0iRXhh bXBsZTIiIHRpdGxlPSJFeGFtcGxlIDIgLSBTUFBQIFF1ZXJ5IFJlcXVlc3QgLSBHZXQgRGVzdGlu YXRpb24gR3JvdXAiPgogICAgICAgIDxhcnR3b3JrIGFsaWduPSJsZWZ0Ij4KICAgICAgICA8IVtD REFUQVsKPHNvYXBlbnY6RW52ZWxvcGUgCnhtbG5zOnNvYXBlbnY9Imh0dHA6Ly9zY2hlbWFzLnht bHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiAKeG1sbnM6c3BiPSJ1cm46aWV0ZjpwYXJhbXM6eG1s Om5zOnNwcHA6YmFzZToxIj4KICAgPHNvYXBlbnY6SGVhZGVyLz4KICAgPHNvYXBlbnY6Qm9keT4K ICAgICAgPHNwYjpzcHBwUXVlcnlSZXF1ZXN0IAogICAgICB4c2k6c2NoZW1hTG9jYXRpb249InVy bjppZXRmOnBhcmFtczp4bWw6bnM6c3BwcDpiYXNlOjEgc3BwcC54c2QiIAogICAgICB4bWxucz0i dXJuOmlldGY6cGFyYW1zOnhtbDpuczpzcHBwOmJhc2U6MSIgCiAgICAgIHhtbG5zOnhzaT0iaHR0 cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiPgogICAgICAgICAgPHNwYjpt aW5vclZlcj4xPC9zcGI6bWlub3JWZXI+CiAgICAgICAgICA8c3BiOnJxc3QgeHNpOnR5cGU9InNw YjpHZXREZXN0R3Jwc1Jxc3RUeXBlIj4KICAgICAgICAgICAgICA8c3BiOm9iaktleT4KICAgICAg ICAgICAgICAgICAgPHNwYjpyYW50PnJlZ2lzdHJhbnQyPC9zcGI6cmFudD4KICAgICAgICAgICAg ICAgICAgPHNwYjpuYW1lPkRFU1RfR1JQX1NQUFBfNTwvc3BiOm5hbWU+CiAgICAgICAgICAgICAg PC9zcGI6b2JqS2V5PgogICAgICAgICAgPC9zcGI6cnFzdD4KICAgICAgPC9zcGI6c3BwcFF1ZXJ5 UmVxdWVzdD4KICAgPC9zb2FwZW52OkJvZHk+Cjwvc29hcGVudjpFbnZlbG9wZT4KICAgICAgIF1d PgogICAgICAgPC9hcnR3b3JrPgogICAgICAgPC9maWd1cmU+CiAgICA8L3Q+CiAgICA8dD4KCSAg CTxmaWd1cmUgYW5jaG9yPSJFeGFtcGxlMyIgdGl0bGU9IkV4YW1wbGUgMiAtIFNQUFAgUXVlcnkg UmVxdWVzdCAtIERlbCBEZXN0aW5hdGlvbiBHcm91cCI+CiAgICAgICAgPGFydHdvcmsgYWxpZ249 ImxlZnQiPgogICAgICAgIDwhW0NEQVRBWwo8c29hcGVudjpFbnZlbG9wZSAKeG1sbnM6c29hcGVu dj0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iIAp4bWxuczpzcGI9 InVybjppZXRmOnBhcmFtczp4bWw6bnM6c3BwcDpiYXNlOjEiPgogICA8c29hcGVudjpIZWFkZXIv PgogICA8c29hcGVudjpCb2R5PgogICAgICA8c3BiOnNwcHBRdWVyeVJlcXVlc3QgCiAgICAgIHhz aTpzY2hlbWFMb2NhdGlvbj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzcHBwOmJhc2U6MSBzcHBw LnhzZCIgCiAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnNwcHA6YmFzZToxIiAK ICAgICAgeG1sbnM6eHNpPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0YW5j ZSI+CiAgICAgICAgICA8c3BiOmNsaWVudFRyYW5zSWQ+OTk5PC9zcGI6Y2xpZW50VHJhbnNJZD4K ICAgICAgICAgIDxzcGI6bWlub3JWZXI+MTwvc3BiOm1pbm9yVmVyPgogICAgICAgICAgPHNwYjpy cXN0IHhzaTp0eXBlPSJzcGI6RGVsRGVzdEdycFJxc3RUeXBlIj4KICAgICAgICAgICAgICA8c3Bi Om9iaktleT4KICAgICAgICAgICAgICAgICAgPHNwYjpyYW50PnJlZ2lzdHJhbnQyPC9zcGI6cmFu dD4KICAgICAgICAgICAgICAgICAgPHNwYjpuYW1lPkRFU1RfR1JQX1NQUFBfNTwvc3BiOm5hbWU+ CiAgICAgICAgICAgICAgPC9zcGI6b2JqS2V5PgogICAgICAgICAgPC9zcGI6cnFzdD4KICAgICAg PC9zcGI6c3BwcFF1ZXJ5UmVxdWVzdD4KICAgPC9zb2FwZW52OkJvZHk+Cjwvc29hcGVudjpFbnZl bG9wZT4KICAgICAgIF1dPgogICAgICAgPC9hcnR3b3JrPgogICAgICAgPC9maWd1cmU+CiAgICA8 L3Q+CgogICAgPC9zZWN0aW9uPgoKICAgIDxzZWN0aW9uIGFuY2hvcj0iU2VjdXJpdHlDb25zaWRl cmF0aW9ucyIgdGl0bGU9IlNlY3VyaXR5IENvbnNpZGVyYXRpb25zIj4KICAgICAgPHQ+U1BQUCBp cyB1c2VkIHRvIHF1ZXJ5IGFuZCB1cGRhdGUgc2Vzc2lvbiBwZWVyaW5nIGRhdGEgYW5kIGFkZHJl c3Nlcywgc28KICAgdGhlIGFiaWxpdHkgdG8gYWNjZXNzIHRoaXMgcHJvdG9jb2wgc2hvdWxkIGJl IGxpbWl0ZWQgdG8gdXNlcnMgYW5kCiAgIHN5c3RlbXMgdGhhdCBhcmUgYXV0aG9yaXplZCB0byBx dWVyeSBhbmQgdXBkYXRlIHRoaXMgZGF0YS4gIEJlY2F1c2UgdGhpcyAKICAgZGF0YSBpcyBzZW50 IGluIGJvdGggZGlyZWN0aW9ucywgaXQgbWF5IG5vdCBiZSBzdWZmaWNpZW50IGZvciBqdXN0IHRo ZSBjbGllbnQgCiAgIG9yIHVzZXIgdG8gYmUgYXV0aGVudGljYXRlZCB3aXRoIHRoZSBzZXJ2ZXIu ICBUaGUgaWRlbnRpdHkgb2YgdGhlIHNlcnZlciAKICAgc2hvdWxkIGFsc28gYmUgYXV0aGVudGlj YXRlZCBieSB0aGUgY2xpZW50LCB3aGljaCBpcyBvZnRlbiBhY2NvbXBsaXNoZWQgdXNpbmcgCiAg IHRoZSBUTFMgY2VydGlmaWNhdGUgZXhjaGFuZ2UgYW5kIHZhbGlkYXRpb24gZGVzY3JpYmVkIGlu IDx4cmVmIHRhcmdldD0iUkZDMjgxOCIvPi4gIAogICBTUFBQIGRhdGEgbWF5IGluY2x1ZGUgc2Vu c2l0aXZlIAogICBpbmZvcm1hdGlvbiwgcm91dGluZyBkYXRhLCBsaXN0cyBvZiByZXNvbHZhYmxl IGFkZHJlc3NlcywgZXRjLiAgU28gd2hlbiB1c2VkCiAgIGluIGEgcHJvZHVjdGlvbiBzZXR0aW5n IGFuZCBhY3Jvc3Mgbm9uLXNlY3VyZSBuZXR3b3JrcywgU1BQUCAKICAgc2hvdWxkIG9ubHkgYmUg dXNlZCBvdmVyIGNvbW11bmljYXRpb25zIGNoYW5uZWxzIHRoYXQgcHJvdmlkZSBzdHJvbmcgCiAg IGVuY3J5cHRpb24gZm9yIGRhdGEgcHJpdmFjeS48L3Q+CgogICAgICA8c2VjdGlvbiBhbmNob3I9 IkludGVncml0eVByaXZhY3lBdXRoZW50aWNhdGlvbiIgdGl0bGU9IkludGVncml0eSwgUHJpdmFj eSwgYW5kIEF1dGhlbnRpY2F0aW9uIj4KCiAgIDx0PlRoZSBTUFBQIFNPQVAgYmluZGluZyByZWxp ZXMgb24gYW4gdW5kZXJseWluZyBzZWN1cmUgdHJhbnNwb3J0IGZvcgogICBpbnRlZ3JpdHkgYW5k IHByaXZhY3kuICBTdWNoIHRyYW5zcG9ydHMgYXJlIGV4cGVjdGVkIHRvIGluY2x1ZGUgVExTL0hU VFBTLiAgCiAgIEluIGFkZGl0aW9uIHRvIHRoZSBhcHBsaWNhdGlvbiBsZXZlbCBhdXRoZW50aWNh dGlvbiBpbXBvc2VkIGJ5IGFuIFNQUFAgCiAgIHNlcnZlciwgdGhlcmUgYXJlIGEgbnVtYmVyIG9m IG9wdGlvbnMgZm9yIGF1dGhlbnRpY2F0aW9uIHdpdGhpbiB0aGUgdHJhbnNwb3J0IAogICBsYXll ciBhbmQgdGhlIG1lc3NhZ2luZyBlbnZlbG9wZS4gIFRoZXNlIGluY2x1ZGUgVExTIGNsaWVudCBj ZXJ0aWZpY2F0ZXMsIAogICBIVFRQIERpZ2VzdCBBY2Nlc3MgQXV0aGVudGljYXRpb24sIGFuZCBk aWdpdGFsIHNpZ25hdHVyZXMgd2l0aGluIFNPQVAgaGVhZGVycy4gPC90PgogICAKICAgPHQ+QXQg YSBtaW5pdW11bSwgYWxsIGNvbmZvcm1pbmcgU1BQUCBvdmVyIFNPQVAgaW1wbGVtZW50YXRpb25z IE1VU1QKICAgc3VwcG9ydCBIVFRQUy48L3Q+CiAgIAogICAgICA8L3NlY3Rpb24+CgogICAgICA8 c2VjdGlvbiBhbmNob3I9IlZ1bG5lcmFiaWxpdGllcyIgdGl0bGU9IlZ1bG5lcmFiaWxpdGllcyI+ CgogICA8dD5UaGUgYWJvdmUgcHJvdG9jb2xzIG1heSBoYXZlIHZhcmlvdXMgdnVsbmVyYWJpbGl0 aWVzLCBhbmQgdGhlc2UgbWF5CiAgIGJlIGluaGVyaXRlZCBieSBTUFBQIG92ZXIgU09BUC4gIEFu ZCBTUFBQIGl0c2VsZiBtYXkgaGF2ZSB2dWxuZXJhYmlsaXRpZXMgCiAgIGJlY2F1c2UgYW4gYXV0 aG9yaXphdGlvbiBtb2RlbCBpcyBub3QgZXhwbGljaXRseSBzcGVjaWZpZWQgaW4gdGhlIGN1cnJl bnQgCiAgIHNwZWNpZmljYXRpb24uCiAgIDwvdD4KICAgCiAgIDx0Pkl0IGlzIGltcG9ydGFudCB0 aGF0IFNQUFAgaW1wbGVtZW50YXRpb25zIGltcGxlbWVudCBhbiBhdXRob3JpemF0aW9uIAogICBt b2RlbCB0aGF0IGNvbnNpZGVycyB0aGUgc291cmNlIG9mIGVhY2ggU1BQUCBxdWVyeSBvciB1cGRh dGUgcmVxdWVzdCBhbmQgCiAgIGRldGVybWluZXMgd2hldGhlciBpdCBpcyByZWFzb25hYmxlIHRv IGF1dGhvcml6ZSB0aGF0IHNvdXJjZSB0byBwZXJmb3JtIHRoYXQKICAgc3BlY2lmaWMgcXVlcnkg b3IgdXBkYXRlLiA8L3Q+CiAgIAogICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiBhbmNo b3I9IkRlcGxveW1lbnRFbnZpcm9ubWVudFNwZWNpZmljcyIgdGl0bGU9IkRlcGxveW1lbnQgRW52 aXJvbm1lbnQgU3BlY2lmaWNzIj4KCiAgIDx0PlNvbWUgZGVwbG95bWVudHMgb2YgU1BQUCBvdmVy IFNPQVAgY291bGQgY2hvb3NlIHRvIHVzZSB0cmFuc3BvcnRzCiAgIHdpdGhvdXQgZW5jcnlwdGlv bi4gIFRoaXMgcHJlc2VudHMgdnVsbmVyYWJpbGl0aWVzIGJ1dCBjb3VsZCBiZQogICBzZWxlY3Rl ZCBmb3IgZGVwbG95bWVudHMgaW52b2x2aW5nIGNsb3NlZCBuZXR3b3JrcyBvciBkZWJ1Z2dpbmcK ICAgc2NlbmFyaW9zLiAgSG93ZXZlciwgdGhlIHZ1bG5lcmFiaWxpdGllcyBvZiBzdWNoIGEgZGVw bG95bWVudCBjb3VsZCBiZSBhIAogICBsYWNrIG9mIGludGVncml0eSBhbmQgcHJpdmFjeSBvZiB0 aGUgZGF0YSB0cmFuc3BvcnRlZCBvdmVyIFNQUFAgbWVzc2FnZXMgaW4gCiAgIHRoaXMgdHlwZSBv ZiBkZXBsb3ltZW50LjwvdD4KICAgCiAgICAgIDwvc2VjdGlvbj4KCiAgICA8L3NlY3Rpb24+CiAK ICAgIDxzZWN0aW9uIGFuY2hvcj0iSUFOQUNvbnNpZGVyYXRpb25zIiB0aXRsZT0iSUFOQSBDb25z aWRlcmF0aW9ucyI+CiAgICAgIDx0PlRoaXMgZG9jdW1lbnQgdXNlcyBVUk5zIHRvIGRlc2NyaWJl IFhNTCBuYW1lc3BhY2VzIGFuZCBYTUwgc2NoZW1hcwogICBjb25mb3JtaW5nIHRvIGEgcmVnaXN0 cnkgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9IlJGQzM2ODgiLz4uCiAgICA8 L3Q+CiAgIDx0PlVSTiBhc3NpZ25tZW50cyBhcmUgcmVxdWVzdGVkOiAgdXJuOmlldGY6cGFyYW1z OnhtbDpuczpzcHBwOnNvYXA8L3Q+CiAgICA8L3NlY3Rpb24+CiAKIDxzZWN0aW9uIGFuY2hvcj0i QWNrbm93bGVkZ2VtZW50cyIgdGl0bGU9IkFja25vd2xlZGdlbWVudHMiPgogICAgPHQ+CgkJVGhp cyBkb2N1bWVudCBpcyBhIHJlc3VsdCBvZiB2YXJpb3VzIGRpc2N1c3Npb25zIGhlbGQgYnkgdGhl IERSSU5LUyBkZXNpZ24gdGVhbSwgd2hpY2ggaXMgY29tcHJpc2VkIG9mIHRoZSBmb2xsb3dpbmcg aW5kaXZpZHVhbHMsIGluIG5vIHNwZWNpZmljIG9yZGVyOiBTeWVkIEFsaSAoTmV1U3RhciksIFN1 bWFudGggQ2hhbm5hYmFzYXBwYSAoQ2FibGUgTGFicyksIERhdmlkIFNjaHdhcnR6IChYQ29ubmVj dCksIEplYW4tRnJhbmNvaXMgTXVsZSAoQ2FibGVMYWJzKSwgS2VubmV0aCBDYXJ0d3JpZ2h0IChU TlMsIEluYy4pLCBNYW5qdWwgTWFoYXJpc2hpIChUTlMsIEluYy4pLCBBbGV4YW5kZXIgTWF5cmhv ZmVyIChlbnVtLmF0IEdtYkgpLgoJCTwvdD4KCiAgICA8L3NlY3Rpb24+CgogIDwvbWlkZGxlPgoK ICA8YmFjaz4KICAgIDxyZWZlcmVuY2VzIHRpdGxlPSJOb3JtYXRpdmUgUmVmZXJlbmNlcyI+CiAg ICAgICAgICAgICAgICAmcmZjMjExOTsKICAgICAgICAgICAgICAgICZyZmMzNjg4OwogICAgICAg ICAgICAgICAgJnJmYzUyNDY7CiAgICAgICAgICAgICAgICAmcmZjMjYxNzsKICAgICAgICAgICAg ICAgICZyZmMyNjE2OwogICAgICAgICAgICAgICAgJnJmYzI4MTg7CiAgICAgICAgICAgICAgICA8 cmVmZXJlbmNlIGFuY2hvcj0iSS1ELmRyYWZ0LWlldGYtZHJpbmtzLXNwcHJvdiI+CiAgICAgICAg ICAgICAgICAgICAgICAgIDxmcm9udD4KICAgICAgICAgICAgICAgICAgICAgICAgICA8dGl0bGU+ RFJJTktTIFVzZSBjYXNlcyBhbmQgUHJvdG9jb2wgUmVxdWlyZW1lbnRzPC90aXRsZT4KCiAgICAJ CQkJCSAgPGF1dGhvciBpbml0aWFscz0iSi1GLk0uIiBzdXJuYW1lPSJNdWxlIi8+CiAgICAJCQkJ CSAgPGF1dGhvciBpbml0aWFscz0iSy5DLiIgc3VybmFtZT0iQ2FydHdyaWdodCIvPgogICAgCQkJ CQkgIDxhdXRob3IgaW5pdGlhbHM9IlMuQS4iIHN1cm5hbWU9IkFsaSIvPgogICAgCQkJCQkgIDxh dXRob3IgaW5pdGlhbHM9IkEuTS4iIHN1cm5hbWU9Ik1heXJob2ZlciIvPgogICAgCQkJCQkKICAg ICAgICAgICAgICAgICAgICAgICAgICA8ZGF0ZSBtb250aD0iSnVuZSIgeWVhcj0iMjAxMSIgLz4K ICAgICAgICAgICAgICAgICAgICAgICAgPC9mcm9udD4KICAgICAgICAgICAgICAgICAgICAgICAg PHNlcmllc0luZm8gbmFtZT0iSW50ZXJuZXQtRHJhZnQiIHZhbHVlPSJkcmFmdC1pZXRmLWRyaW5r cy1zcHByb3YtMDciLz4KICAgICAgICAgICAgICAgICAgICAgICAgPGZvcm1hdCB0YXJnZXQ9Imh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZHJpbmtzLXNwcHJvdi0wNyIgdHlw ZT0iSFRNTCIgLz4KICAgICAgICAgICAgICAgIDwvcmVmZXJlbmNlPgoKICAgICAgICAgICAgICAg IDxyZWZlcmVuY2UgYW5jaG9yPSJTT0FQUkVGIj4KICAgICAgICAgICAgICAgICAgICAgICAgPGZy b250PgogICAgICAgICAgICAgICAgICAgICAgICAgIDx0aXRsZT5TT0FQIFZlcnNpb24gMS4yIFBh cnQgMTogTWVzc2FnaW5nIEZyYW1ld29yazwvdGl0bGU+CgogICAgCQkJCQkgICA8YXV0aG9yIGlu aXRpYWxzPSJNLiIgc3VybmFtZT0iR3VkZ2luIi8+CiAgICAJCQkJCSAgIDxhdXRob3IgaW5pdGlh bHM9Ik0uIiBzdXJuYW1lPSJIYWRsZXkiLz4KICAgIAkJCQkJICAgPGF1dGhvciBpbml0aWFscz0i Si4iIHN1cm5hbWU9Ik1vcmVhdSIvPgogICAgCQkJCQkgICA8YXV0aG9yIGluaXRpYWxzPSJILiIg c3VybmFtZT0iTmllbHNlbiIvPgoKICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRhdGUgbW9u dGg9Ikp1bmUiIHllYXI9IjIwMDIiIC8+CiAgICAgICAgICAgICAgICAgICAgICAgIDwvZnJvbnQ+ CiAgICAgICAgICAgICAgICAgICAgICAgIDxzZXJpZXNJbmZvIG5hbWU9IlczQyBSZWNvbW1lbmRh dGlvbiIgdmFsdWU9IlJFQy1TT0FQMTItcGFydDEtMjAwMzA2MjQiLz4KICAgICAgICAgICAgICAg ICAgICAgICAgPGZvcm1hdCB0YXJnZXQ9Imh0dHA6Ly93d3cudzMub3JnL1RSL3NvYXAxMi1wYXJ0 MS8iIHR5cGU9IkhUTUwiIC8+CiAgICAgICAgICAgICAgICA8L3JlZmVyZW5jZT4KCiAgICA8L3Jl ZmVyZW5jZXM+CiAgICAKICAgIDxyZWZlcmVuY2VzIHRpdGxlPSJJbmZvcm1hdGl2ZSBSZWZlcmVu Y2VzIj4gCiAgICAgICAgICAgICAgICA8cmVmZXJlbmNlIGFuY2hvcj0iV1NETFJFRiI+CiAgICAg ICAgICAgICAgICAgICAgICAgIDxmcm9udD4KICAgICAgICAgICAgICAgICAgICAgICAgICA8dGl0 bGU+V2ViIFNlcnZpY2VzIERlc2NyaXB0aW9uIExhbmd1YWdlIChXU0RMKSAxLjE8L3RpdGxlPgoK ICAgIAkJCQkJICAgPGF1dGhvciBpbml0aWFscz0iRS4iIHN1cm5hbWU9IkNocmlzdGVuc2VuIi8+ CiAgICAJCQkJCSAgIDxhdXRob3IgaW5pdGlhbHM9IkYuIiBzdXJuYW1lPSJDdXJiZXJhIi8+CiAg ICAJCQkJCSAgIDxhdXRob3IgaW5pdGlhbHM9IkcuIiBzdXJuYW1lPSJNZXJlZGl0aCIvPgogICAg CQkJCQkgICA8YXV0aG9yIGluaXRpYWxzPSJTLiIgc3VybmFtZT0iV2VlcmF3YXJhbmEiLz4KCiAg ICAgICAgICAgICAgICAgICAgICAgICAgIDxkYXRlIG1vbnRoPSJNYXJjaCIgeWVhcj0iMjAwMSIg Lz4KICAgICAgICAgICAgICAgICAgICAgICAgPC9mcm9udD4KICAgICAgICAgICAgICAgICAgICAg ICAgPHNlcmllc0luZm8gbmFtZT0iVzNDIE5vdGUiIHZhbHVlPSJOT1RFLXdzZGwtMjAwMTAzMTUi Lz4KICAgICAgICAgICAgICAgICAgICAgICAgPGZvcm1hdCB0YXJnZXQ9Imh0dHA6Ly93d3cudzMu b3JnL1RSLzIwMDEvTk9URS13c2RsLTIwMDEwMzE1IiB0eXBlPSJIVE1MIiAvPgogICAgICAgICAg ICAgICAgPC9yZWZlcmVuY2U+CiAgICA8L3JlZmVyZW5jZXM+CgogIDwvYmFjaz4KICAKPC9yZmM+ Cg== --_003_754963199212404AB8E9CFCA6C3D0CDA38DDB8C58DTNSMAILNAwin2_ Content-Type: text/plain; name="draft-ietf-drinks-sppp-over-soap-05.txt" Content-Description: draft-ietf-drinks-sppp-over-soap-05.txt Content-Disposition: attachment; filename="draft-ietf-drinks-sppp-over-soap-05.txt"; size=27590; creation-date="Tue, 23 Aug 2011 16:30:27 GMT"; modification-date="Tue, 23 Aug 2011 16:30:27 GMT" Content-Transfer-Encoding: base64 CgoKRFJJTktTICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBLLiBDYXJ0d3JpZ2h0CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFROUwpJbnRlbmRlZCBzdGF0dXM6IFN0YW5k YXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjMsIDIwMTEKRXhwaXJl czogRmVicnVhcnkgMjQsIDIwMTIKCgogICAgICAgICAgICAgICAgICAgICAgICBTUFBQIE92ZXIg U09BUCBhbmQgSFRUUAogICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLWRyaW5rcy1zcHBwLW92 ZXItc29hcC0wNQoKQWJzdHJhY3QKCiAgIFRoZSBTZXNzaW9uIFBlZXJpbmcgUHJvdmlzaW9uaW5n IFByb3RvY29sIChTUFBQKSBpcyBhbiBYTUwgcHJvdG9jb2wKICAgdGhhdCBleGlzdHMgdG8gZW5h YmxlIHRoZSBwcm92aXNpb25pbmcgb2Ygc2Vzc2lvbiBlc3RhYmxpc2htZW50IGRhdGEKICAgaW50 byBTZXNzaW9uIERhdGEgUmVnaXN0cmllcyBvciBTSVAgU2VydmljZSBQcm92aWRlciBkYXRhIHN0 b3Jlcy4KICAgU2VuZGluZyBYTUwgZGF0YSBzdHJ1Y3R1cmVzIG92ZXIgU2ltcGxlIE9iamVjdCBB Y2Nlc3MgUHJvdG9jb2wgKFNPQVApCiAgIGFuZCBIVFRQKHMpIGlzIGEgd2lkZWx5IHVzZWQsIGRl LWZhY3RvIHN0YW5kYXJkIGZvciBtZXNzYWdpbmcgYmV0d2VlbgogICBlbGVtZW50cyBvZiBwcm92 aXNpb25pbmcgc3lzdGVtcy4gIFRoZXJlZm9yZSB0aGUgY29tYmluYXRpb24gb2YgU09BUAogICBh bmQgSFRUUChzKSBhcyBhIHRyYW5zcG9ydCBmb3IgU1BQUCBpcyBhIG5hdHVyYWwgZml0LiAgVGhl IG9idmlvdXMKICAgYmVuZWZpdHMgaW5jbHVkZSBsZXZlcmFnaW5nIGV4aXN0aW5nIGluZHVzdHJ5 IGV4cGVydGlzZSwgbGV2ZXJhZ2luZwogICBleGlzdGluZyBzdGFuZGFyZHMsIGFuZCBhIGhpZ2hl ciBwcm9iYWJpbGl0eSB0aGF0IGV4aXN0aW5nCiAgIHByb3Zpc2lvbmluZyBzeXN0ZW1zIGNhbiBi ZSBtb3JlIGVhc2lseSBpbnRlZ3JhdGVkIHdpdGggdGhpcwogICBwcm90b2NvbC4gIFRoaXMgZG9j dW1lbnQgZGVzY3JpYmVzIHRoZSBzcGVjaWZpY2F0aW9uIGZvciB0cmFuc3BvcnRpbmcKICAgU1BQ UCBYTUwgc3RydWN0dXJlcyBvdmVyIFNPQVAgYW5kIEhUVFAocykuCgpTdGF0dXMgb2YgdGhpcyBN ZW1vCgogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1h bmNlIHdpdGggdGhlCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuCgogICBJbnRl cm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVl cmluZwogICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFs c28gZGlzdHJpYnV0ZQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBU aGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LQogICBEcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUg ZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQg bWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRz IGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJh ZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBh cyAid29yayBpbiBwcm9ncmVzcy4iCgogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJl IG9uIEZlYnJ1YXJ5IDI0LCAyMDEyLgoKQ29weXJpZ2h0IE5vdGljZQoKICAgQ29weXJpZ2h0IChj KSAyMDExIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlCiAgIGRv Y3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLgoKICAgVGhpcyBkb2N1bWVudCBp cyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbAogICBQcm92aXNp b25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzCgoKCkNhcnR3cmlnaHQgICAgICAgICAgICAg IEV4cGlyZXMgRmVicnVhcnkgMjQsIDIwMTIgICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVy bmV0LURyYWZ0ICAgICAgZHJhZnQtaWV0Zi1kcmlua3Mtc3BwcC1vdmVyLXNvYXAgICAgICAgICBB dWd1c3QgMjAxMQoKCiAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGlu IGVmZmVjdCBvbiB0aGUgZGF0ZSBvZgogICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAg UGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMKICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2Ny aWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0CiAgIHRvIHRoaXMg ZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBt dXN0CiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBp biBTZWN0aW9uIDQuZSBvZgogICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHBy b3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMKICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVk IEJTRCBMaWNlbnNlLgoKClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgSW50cm9kdWN0aW9uIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMKICAgMi4g IFRlcm1pbm9sb2d5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICA0CiAgIDMuICBTT0FQIEZlYXR1cmVzIGFuZCBTUFBQIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQogICA0LiAgSFRUUChzKSBGZWF0dXJlcyBhbmQgU1BQ UCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgKICAgNS4gIEF1dGhlbnRp Y2F0aW9uIGFuZCBTZXNzaW9uIE1hbmFnZW1lbnQgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5 CiAgIDYuICBTUFBQIFNPQVAgV1NETCBEZWZpbml0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAxMAogICA3LiAgU1BQUCBTT0FQIEV4YW1wbGVzIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMKICAgOC4gIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE1CiAgICAgOC4x LiAgSW50ZWdyaXR5LCBQcml2YWN5LCBhbmQgQXV0aGVudGljYXRpb24gLiAuIC4gLiAuIC4gLiAu IC4gLiAxNQogICAgIDguMi4gIFZ1bG5lcmFiaWxpdGllcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMTUKICAgICA4LjMuICBEZXBsb3ltZW50IEVudmlyb25tZW50 IFNwZWNpZmljcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE1CiAgIDkuICBJQU5BIENvbnNp ZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNgog ICAxMC4gQWNrbm93bGVkZ2VtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMTcKICAgMTEuIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE4CiAgICAgMTEuMS4gTm9ybWF0aXZlIFJlZmVy ZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOAogICAgIDExLjIu IEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMTgKICAgQXV0aG9yJ3MgQWRkcmVzcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDE5CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKQ2FydHdyaWdodCAg ICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNCwgMjAxMiAgICAgICAgICAgICAgIFtQYWdl IDJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICBkcmFmdC1pZXRmLWRyaW5rcy1zcHBwLW92ZXItc29h cCAgICAgICAgIEF1Z3VzdCAyMDExCgoKMS4gIEludHJvZHVjdGlvbgoKICAgU1BQUCwgZGVmaW5l ZCBpbiBbSS1ELmRyYWZ0LWlldGYtZHJpbmtzLXNwcHJvdl0sIGlzIGJlc3Qgc3VwcG9ydGVkIGJ5 CiAgIGEgdHJhbnNwb3J0IGFuZCBtZXNzYWdpbmcgaW5mcmFzdHJ1Y3R1cmUgdGhhdCBpcyBjb25u ZWN0aW9uIG9yaWVudGVkLAogICByZXF1ZXN0LXJlc3BvbnNlIG9yaWVudGVkLCBlYXNpbHkgc2Vj dXJlZCwgc3VwcG9ydHMgcHJvcGFnYXRpb24KICAgdGhyb3VnaCBmaXJld2FsbHMgaW4gYSBzdGFu ZGFyZCBmYXNoaW9uLCBhbmQgdGhhdCBpcyBlYXNpbHkKICAgaW50ZWdyYXRlZCBpbnRvIGJhY2st b2ZmaWNlIHN5c3RlbXMuICBUaGlzIGlzIGR1ZSB0byB0aGUgZmFjdCB0aGF0CiAgIHRoZSBjbGll bnQgc2lkZSBvZiBTUFBQIGlzIGxpa2VseSB0byBiZSBpbnRlZ3JhdGVkIHdpdGgKICAgb3JnYW5p emF0aW9ucycgb3BlcmF0aW9uYWwgc3VwcG9ydCBzeXN0ZW1zIHRoYXQgZmFjaWxpdGF0ZQogICB0 cmFuc2FjdGlvbmFsIHByb3Zpc2lvbmluZyBvZiB1c2VyIGFkZHJlc3NlcyBhbmQgdGhlaXIgYXNz b2NpYXRlZAogICBzZXNzaW9uIGVzdGFibGlzaG1lbnQgZGF0YS4gIFdoaWxlIHRoZSBzZXJ2ZXIg c2lkZSBvZiBTUFBQIGlzIGxpa2VseQogICB0byByZXNpZGUgaW4gYSBzZXBhcmF0ZSBvcmdhbml6 YXRpb24ncyBuZXR3b3JrLCByZXN1bHRpbmcgdGhlIFNQUFAKICAgcHJvdmlzaW9uaW5nIHRyYW5z YWN0aW9ucyB0cmF2ZXJzaW5nIHRoZSBJbnRlcm5ldCBhcyB0aGV5IGFyZQogICBwcm9wYWdhdGVk IGZyb20gdGhlIFNQUFAgY2xpZW50IHRvIHRoZSBTUFBQIHNlcnZlci4gIEdpdmVuIHRoZQogICBj dXJyZW50IHN0YXRlIG9mIGluZHVzdHJ5IHByYWN0aWNlIGFuZCB0ZWNobm9sb2dpZXMsIFNPQVAg YW5kIEhUVFAocykKICAgYXJlIHdlbGwgc3VpdGVkIGZvciB0aGlzIHR5cGUgb2YgZW52aXJvbm1l bnQuICBUaGlzIGRvY3VtZW50CiAgIGRlc2NyaWJlcyB0aGUgc3BlY2lmaWNhdGlvbiBmb3IgdHJh bnNwb3J0aW5nIFNQUFAgWE1MIHN0cnVjdHVyZXMgb3ZlcgogICBTT0FQIGFuZCBIVFRQKHMpLgoK ICAgVGhlIHNwZWNpZmljYXRpb24gaW4gdGhpcyBkb2N1bWVudCBmb3IgdHJhbnNwb3J0aW5nIFNQ UFAgWE1MCiAgIHN0cnVjdHVyZXMgb3ZlciBTT0FQIGFuZCBIVFRQKHMpIGlzIHByaW1hcmlseSBj b21wcmlzZWQgb2YgZml2ZQogICBzdWJqZWN0czogKDEpIGEgZGVzY3JpcHRpb24gb2YgYW55IGFw cGxpY2FibGUgU09BUCBmZWF0dXJlcywgKDIpIGFueQogICBhcHBsaWNhYmxlIEhUVFAgZmVhdHVy ZXMsICgzKSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucywgYW5kIHBlcmhhcHMKICAgbW9zdCBpbXBv cnRhbnRseSwgKDUpIHRoZSBXZWIgU2VydmljZXMgRGVzY3JpcHRpb24gTGFuZ3VhZ2UgKFdTREwp CiAgIGRlZmluaXRpb24gZm9yIFNQUFAgb3ZlciBTT0FQLgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCkNhcnR3cmlnaHQgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjQsIDIwMTIgICAg ICAgICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAgICAgZHJhZnQtaWV0Zi1kcmlu a3Mtc3BwcC1vdmVyLXNvYXAgICAgICAgICBBdWd1c3QgMjAxMQoKCjIuICBUZXJtaW5vbG9neQoK ICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIs ICJTSEFMTCBOT1QiLAogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAi TUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcwogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJw cmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XS4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCkNhcnR3cmlnaHQgICAgICAgICAgICAgIEV4cGlyZXMgRmVi cnVhcnkgMjQsIDIwMTIgICAgICAgICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0LURyYWZ0ICAg ICAgZHJhZnQtaWV0Zi1kcmlua3Mtc3BwcC1vdmVyLXNvYXAgICAgICAgICBBdWd1c3QgMjAxMQoK CjMuICBTT0FQIEZlYXR1cmVzIGFuZCBTUFBQCgogICBUaGUgbGlzdCBvZiBTT0FQIGZlYXR1cmVz IHRoYXQgYXJlIGV4cGxpY2l0bHkgdXNlZCBhbmQgcmVxdWlyZWQgZm9yCiAgIFNQUFAgYXJlIGxp bWl0ZWQuICBNb3N0IFNPQVAgZmVhdHVyZXMgYXJlIG5vdCBuZWNlc3NhcnkgZm9yIFNQUFAuCiAg IFNQUFAgcHJpbWFyaWx5IHVzZXMgU09BUCBzaW1wbHkgYXMgYSBzdGFuZGFyZCBtZXNzYWdlIGVu dmVsb3BlCiAgIHRlY2hub2xvZ3kuICBUaGUgU09BUCBtZXNzYWdlIGVudmVsb3BlIGlzIGNvbXBy aXNlZCBvZiB0aGUgU09BUAogICBoZWFkZXIgYW5kIGJvZHkuICBBcyBkZXNjcmliZWQgaW4gdGhl IFNPQVAgc3BlY2lmaWNhdGlvbnMsIHRoZSBTT0FQCiAgIGhlYWRlciBjYW4gY29udGFpbiBvcHRp b25hbCwgYXBwbGljYXRpb24gc3BlY2lmaWMsIGluZm9ybWF0aW9uIGFib3V0CiAgIHRoZSBtZXNz YWdlLiAgVGhlIFNPQVAgYm9keSBjb250YWlucyB0aGUgU1BQUCBtZXNzYWdlIGl0c2VsZiwgd2hv c2UKICAgc3RydWN0dXJlIGlzIGRlZmluZWQgYnkgdGhlIGNvbWJpbmF0aW9uIG9mIG9uZSBvZiB0 aGUgV1NETCBvcGVyYXRpb25zCiAgIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBhbmQgdGhlIFNQ UFAgWE1MIGRhdGEgc3RydWN0dXJlcyBkZWZpbmVkIGluCiAgIHRoZSBTUFBQIHByb3RvY29sIGRv Y3VtZW50LiAgU1BQUCBkb2VzIG5vdCByZWx5IG9uIGFueSBkYXRhIGVsZW1lbnRzCiAgIGluIHRo ZSBTT0FQIGhlYWRlci4gIEFsbCByZWxldmFudCBkYXRhIGVsZW1lbnRzIGFyZSBkZWZpbmVkIGlu IHRoZQogICBTUFBQIFhNTCBzY2hlbWEgZGVzY3JpYmVkIGluIFtJLUQuZHJhZnQtaWV0Zi1kcmlu a3Mtc3Bwcm92XSBhbmQgdGhlCiAgIFNQUFAgV1NETCBzcGVjaWZpY2F0aW9uIGRlc2NyaWJlZCBp biB0aGlzIGRvY3VtZW50LgoKICAgV1NETCBpcyBhIHdpZGVseSBzdGFuZGFyZGl6ZWQgYW5kIGFk b3B0ZWQgdGVjaG5vbG9neSBmb3IgZGVmaW5pbmcgdGhlCiAgIHRvcC1sZXZlbCBzdHJ1Y3R1cmVz IG9mIHRoZSBtZXNzYWdlcyB0aGF0IGFyZSB0cmFuc3BvcnRlZCB3aXRoaW4gdGhlCiAgIGJvZHkg b2YgYSBTT0FQIG1lc3NhZ2UuICBUaGUgV1NETCBkZWZpbml0aW9uIGZvciB0aGUgU1BQUCBTT0FQ CiAgIG1lc3NhZ2VzIGlzIGRlZmluZWQgbGF0ZXIgaW4gdGhpcyBkb2N1bWVudCwgd2hpY2ggaW1w b3J0cyBieQogICByZWZlcmVuY2UgdGhlIFhNTCBkYXRhIHR5cGVzIGNvbnRhaW5lZCBpbiB0aGUg U1BQUCBzY2hlbWEuICBUaGUgSUFOQQogICByZWdpc3RyeSB3aGVyZSB0aGUgU1BQUCBzY2hlbWEg cmVzaWRlcyBpcyBkZXNjcmliZWQgaW4gVGhlIElFVEYgWE1MCiAgIFJlZ2lzdHJ5IFtSRkMzNjg4 XS4KCiAgIFRoZXJlIGFyZSBtdWx0aXBsZSBzdHJ1Y3R1cmFsIHN0eWxlcyB0aGF0IFNPQVAgV1NE TCBhbGxvd3MuICBCdXQgdGhlCiAgIGJlc3QgcHJhY3RpY2UgZm9yIHRoaXMgdHlwZSBvZiBhcHBs aWNhdGlvbiBpcyB3aGF0IGlzIHNvbWV0aW1lcwogICByZWZlcnJlZCB0byBhcyB0aGUgRG9jdW1l bnQgTGl0ZXJhbCBXcmFwcGVkIHN0eWxlIG9mIGRlc2lnbmluZyBTT0FQCiAgIFdTREwuICBUaGlz IHN0eWxlIGlzIGdlbmVyYWxseSByZWdhcmRlZCBhcyBhbiBvcHRpbWFsIGFwcHJvYWNoIHRoYXQK ICAgZW5oYW5jZXMgbWFpbnRhaW5hYmlsaXR5LCBjb21wcmVoZW5zaW9uLCBwb3J0YWJpbGl0eSwg YW5kLCB0byBhCiAgIGNlcnRhaW4gZXh0ZW50LCBwZXJmb3JtYW5jZS4gIEl0IGlzIGNoYXJhY3Rl cml6ZWQgYnkgc2V0dGluZyB0aGUKICAgc29hcEFjdGlvbiBiaW5kaW5nIHN0eWxlIGFzIF9kb2N1 bWVudF8sIHRoZSBzb2FwQWN0aW9uIGVuY29kaW5nIHN0eWxlCiAgIGFzIF9saXRlcmFsXywgYW5k IHRoZW4gZGVmaW5pbmcgdGhlIFNPQVAgbWVzc2FnZXMgdG8gc2ltcGx5IGNvbnRhaW4gYQogICBz aW5nbGUgZGF0YSBlbGVtZW50IHRoYXQgX3dyYXBzXyB0aGF0IGlzIGEgZGF0YSBzdHJ1Y3R1cmUg Y29udGFpbmluZwogICBhbGwgdGhlIHJlcXVpcmVkIGlucHV0IG9yIG91dHB1dCBkYXRhIGVsZW1l bnRzLiAgVGhlIGZpZ3VyZSBiZWxvdwogICBpbGx1c3RyYXRlcyB0aGlzIGhpZ2ggbGV2ZWwgdGVj aG5pY2FsIHN0cnVjdHVyZS4KCgoKCgoKCgoKCgoKCgoKCkNhcnR3cmlnaHQgICAgICAgICAgICAg IEV4cGlyZXMgRmVicnVhcnkgMjQsIDIwMTIgICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVy bmV0LURyYWZ0ICAgICAgZHJhZnQtaWV0Zi1kcmlua3Mtc3BwcC1vdmVyLXNvYXAgICAgICAgICBB dWd1c3QgMjAxMQoKCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0t LS0tLSsKICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS18ICAgIFNPQVAgICAgICAgfC0t LS0tLSsKICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8ICBPcGVyYXRpb24gICAgfCAg ICAgIHwKICAgICAgICAgICAgICAgQ29udGFpbnMgfCAgICAgICstLS0tLS0tLS0tLS0tLS0tKyAg ICAgIHwgQ29udGFpbnMKICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICBFeGFtcGxl OiAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgViAgICAgIHN1Ym1pdFVwZGF0 ZVJxc3QgICAgICAgIFYKICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLSsgICAgICAgICAg ICstLS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICAgfFNPQVAgUmVxdWVzdCAgfCAgICAgICAg ICAgfFNPQVAgUmVzcG9uc2V8CiAgICAgICAgRXhhbXBsZTp8ICBNZXNzYWdlICAgICB8ICAgICAg ICAgICB8ICAgTWVzc2FnZSAgIHwgRXhhbXBsZToKICBzcHBwVXBkYXRlICAgIHwgKE9wZXJhdGlv biAgIHwgICAgICAgICAgIHwgKE9wZXJhdGlvbiAgfHNwcHBVcGRhdGUKICAgICBSZXF1ZXN0TXNn IHwgICBJbnB1dCkgICAgIHwgICAgICAgICAgIHwgIE91dHB1dCkgICAgfCAgIFJlc3BvbnNlTXNn CiAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICArLS0tLS0tLS0tLS0t LSsKICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwKICAg ICAgICAgICAgICAgIENvbnRhaW5zIHwgICAgICAgICAgICAgICAgICAgICAgIHwgQ29udGFpbnMK ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAg ICAgICAgICAgICAgICAgICAgIFYgICAgICAgICAgICAgICAgICAgICAgIFYKICAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tLSsgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwogICAgICAgRXhh bXBsZTp8ICAgIFdyYXBwZWQgICAgfCAgICAgICAgIHwgIFdyYXBwZWQgICAgICB8IEV4YW1wbGU6 CiAgIHNwcHBVcGRhdGUgIHxSZXF1ZXN0IE9iamVjdCB8ICAgICAgICAgfFJlc3BvbnNlIE9iamVj dHwgc3BwcFVwZGF0ZQogICAgICAgUmVxdWVzdCArLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICst LS0tLS0tLS0tLS0tLS0rICAgICBSZXNwb25zZQogICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgQ29udGFpbnMgfCAgICAgICAg ICAgICAgICAgICAgICAgfCBDb250YWlucwogICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICAgViAgICAgICAgICAg ICAgICAgICAgICAgVgogICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgKy0t LS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgfCAgICAgIFNQUFAgICAgIHwgICAg ICAgIHwgICAgICAgU1BQUCAgICAgICAgICB8CiAgICAgICAgICAgICAgIHwgICBYTUwgVHlwZXMg ICB8ICAgICAgICB8ICAgICBYTUwgVHlwZXMgICAgICAgfAogICAgICAgICAgICAgICArLS0tLS0t LS0tLS0tLS0tKyAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKCiAgICAgICAgICBGaWd1 cmUgMTogVGVjaG5pY2FsIFN0cnVjdHVyZSBvZiB0aGUgU1BQUCBTT0FQIE1lc3NhZ2VzCgogICBU aGUgU09BUCBvcGVyYXRpb25zIHN1cHBvcnRlZCBieSBTUFBQIGFyZSBub3JtYXRpdmVseSBkZWZp bmVkIGxhdGVyCiAgIGluIHRoaXMgZG9jdW1lbnQuICBFYWNoIFNPQVAgb3BlcmF0aW9uIGRlZmlu ZXMgYSByZXF1ZXN0L2lucHV0CiAgIG1lc3NhZ2UgYW5kIGEgcmVzcG9uc2Uvb3V0cHV0IG1lc3Nh Z2UuICBFYWNoIHN1Y2ggcmVxdWVzdCBhbmQKICAgcmVzcG9uc2UgbWVzc2FnZSB0aGVuIGNvbnRh aW5zIGEgc2luZ2xlIG9iamVjdCB0aGF0IHdyYXBzIHRoZSBTUFBQCiAgIFhNTCBkYXRhIHR5cGVz IHRoYXQgY29tcHJpc2UgdGhlIGlucHV0cyBhbmQgdGhlIG91dHB1dHMsCiAgIHJlc3BlY3RpdmVs eSwgb2YgdGhlIFNPQVAgb3BlcmF0aW9uLgoKICAgU09BUCBmYXVsdHMgYXJlIG5vdCB1c2VkIGJ5 IHRoZSBTUFBQIFNPQVAgbWFwcGluZy4gIEFsbCBTUFBQIHN1Y2Nlc3MKICAgYW5kIGVycm9yIHJl c3BvbnNlcyBhcmUgc3BlY2lmaWVkIHdpdGhpbiB0aGUgU1BQUCBwcm90b2NvbAogICBzcGVjaWZp Y2F0aW9uIFtJLUQuZHJhZnQtaWV0Zi1kcmlua3Mtc3Bwcm92XS4gIEhvd2V2ZXIsIGlmIGEgU09B UAogICBmYXVsdCB3ZXJlIHRvIG9jY3VyLCBwZXJoYXBzIGR1ZSB0byBmYWlsdXJlcyBpbiB0aGUg U09BUCBtZXNzYWdlCiAgIGhhbmRsaW5nIGxheWVyIG9mIGEgU09BUCBsaWJyYXJ5LCB0aGUgY2xp ZW50IGFwcGxpY2F0aW9uIHNob3VsZAogICBjYXB0dXJlIGFuZCBoYW5kbGUgdGhlIGZhdWx0LiAg U3BlY2lmaWNzIG9uIGhvdyB0byBoYW5kbGUgc3VjaCBTT0FQCiAgIGZhdWx0cywgaWYgdGhleSBz aG91bGQgb2NjdXIsIHdpbGwgYmUgc3BlY2lmaWMgdG8gdGhlIGNob3NlbiBTT0FQCiAgIGltcGxl bWVudGF0aW9uLgoKICAgU09BUCAxLjIgW1NPQVBSRUZdIG9yIGhpZ2hlciBhbmQgV1NETCAxLjEg W1dTRExSRUZdIG9yIGhpZ2hlciBTSE9VTEQKCgoKQ2FydHdyaWdodCAgICAgICAgICAgICAgRXhw aXJlcyBGZWJydWFyeSAyNCwgMjAxMiAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQt RHJhZnQgICAgICBkcmFmdC1pZXRmLWRyaW5rcy1zcHBwLW92ZXItc29hcCAgICAgICAgIEF1Z3Vz dCAyMDExCgoKICAgYmUgdXNlZC4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgpDYXJ0d3JpZ2h0ICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI0 LCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgN10KDApJbnRlcm5ldC1EcmFmdCAgICAgIGRyYWZ0 LWlldGYtZHJpbmtzLXNwcHAtb3Zlci1zb2FwICAgICAgICAgQXVndXN0IDIwMTEKCgo0LiAgSFRU UChzKSBGZWF0dXJlcyBhbmQgU1BQUAoKICAgU09BUCBpcyBub3QgdGllZCB0byBIVFRQKHMpLCBo b3dldmVyLCBmb3IgcmVhc29ucyBkZXNjcmliZWQgaW4gdGhlCiAgIGludHJvZHVjdGlvbiwgSFRU UChzKSBpcyBhIGdvb2QgY2hvaWNlIGFzIHRoZSB0cmFuc3BvcnQgbWVjaGFuaXNtIGZvcgogICB0 aGUgU1BQUCBTT0FQIG1lc3NhZ2VzLiAgSFRUUCAxLjEgaW5jbHVkZXMgdGhlICJwZXJzaXN0ZW50 CiAgIGNvbm5lY3Rpb24iIGZlYXR1cmUsIHdoaWNoIGFsbG93cyBtdWx0aXBsZSBIVFRQIHJlcXVl c3QvcmVzcG9uc2UKICAgcGFpcnMgdG8gYmUgdHJhbnNwb3J0ZWQgYWNyb3NzIGEgc2luZ2xlIEhU VFAgY29ubmVjdGlvbi4gIFRoaXMgaXMgYW4KICAgaW1wb3J0YW50IHBlcmZvcm1hbmNlIG9wdGlt aXphdGlvbiBmZWF0dXJlLCBwYXJ0aWN1bGFybHkgd2hlbiB0aGUKICAgY29ubmVjdGlvbnMgaXMg YW4gSFRUUFMgY29ubmVjdGlvbiB3aGVyZSB0aGUgcmVsYXRpdmVseSB0aW1lCiAgIGNvbnN1bWlu ZyBTU0wgaGFuZHNoYWtlIGhhcyBvY2N1cnJlZC4gIFBlcnNpc3RlbnQgY29ubmVjdGlvbnMgU0hP VUxECiAgIGJlIHVzZWQgZm9yIHRoZSBTUFBQIEhUVFAgY29ubmVjdGlvbnMuCgogICBIVFRQIDEu MSBbUkZDMjYxNl0gb3IgaGlnaGVyIFNIT1VMRCBiZSB1c2VkLgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCkNhcnR3cmlnaHQgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVh cnkgMjQsIDIwMTIgICAgICAgICAgICAgICBbUGFnZSA4XQoMCkludGVybmV0LURyYWZ0ICAgICAg ZHJhZnQtaWV0Zi1kcmlua3Mtc3BwcC1vdmVyLXNvYXAgICAgICAgICBBdWd1c3QgMjAxMQoKCjUu ICBBdXRoZW50aWNhdGlvbiBhbmQgU2Vzc2lvbiBNYW5hZ2VtZW50CgogICBUbyBhY2hpZXZlIGlu dGVncml0eSBhbmRwcml2YWN5LCBjb25mb3JtaW5nIFNQUFAgU09BUCBDbGllbnRzIGFuZAogICBT ZXJ2ZXJzIE1VU1Qgc3VwcG9ydCBTT0FQIG92ZXIgSFRUUCBvdmVyIFRMUyBbW1JGQzUyNDZdXSBh cyB0aGUKICAgc2VjdXJlIHRyYW5zcG9ydCBtZWNoYW5pc20uICBUaGlzIGNvbWJpbmF0aW9uIG9m IEhUVFAgYW5kIFRMUyBpcwogICByZWZlcnJlZCB0byBhcyBIVFRQUy4gIEFuZCB0byBhY2NvbXBs aXNoIGF1dGhlbnRpY2F0aW9uIGNvbmZvcm1haW5nCiAgIFNPQVAgU1BQUCBDbGllbnRzIGFuZCBT ZXJ2ZXJzIE1VU1QgdXNlIEhUVFAgRGlnZXN0IEF1dGhlbnRpY2F0aW9uIGFzCiAgIGRlZmluZWQg aW4gW1JGQzI2MTddLiAgQXMgYSByZXN1bHQsIHRoZSBjb21tdW5pY2F0aW9uIHNlc3Npb24gaXMK ICAgZXN0YWJsaXNoZWQgdGhyb3VnaCB0aGUgaW5pdGlhbCBIVFRQIGNvbm5lY3Rpb24gc2V0dXAs IHRoZSBkaWdlc3QKICAgYXV0aGVudGljYXRpb24sIGFuZCB0aGUgVExTIGhhbmRzaGFrZS4gIFdo ZW4gdGhlIEhUVFAgY29ubmVjdGlvbiBpcwogICBicm9rZW4gZG93biwgdGhlIGNvbW11bmljYXRp b24gc2Vzc2lvbiBlbmRzLgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK Q2FydHdyaWdodCAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNCwgMjAxMiAgICAgICAg ICAgICAgIFtQYWdlIDldCgwKSW50ZXJuZXQtRHJhZnQgICAgICBkcmFmdC1pZXRmLWRyaW5rcy1z cHBwLW92ZXItc29hcCAgICAgICAgIEF1Z3VzdCAyMDExCgoKNi4gIFNQUFAgU09BUCBXU0RMIERl ZmluaXRpb24KCiAgIFRoZSBTUFBQIFdTREwgaXMgZGVmaW5lZCBiZWxvdy4gIFRoZSBXU0RMIGRl c2lnbiBhcHByb2FjaCBpcyBjb21tb25seQogICByZWZlcnJlZCB0byBhcyBfR2VuZXJpYyBXU0RM Xy4gIEl0IGlzIGdlbmVyaWMgaW4gdGhlIHNlbnNlIHRoYXQgdGhlcmUKICAgaXMgbm90IGEgc3Bl Y2lmaWMgV1NETCBvcGVyYXRpb24gZGVmaW5lZCBmb3IgZWFjaCBvYmplY3QgdHlwZSB0aGF0IGlz CiAgIHN1cHBvcnRlZCBieSB0aGUgU1BQUCBwcm90b2NvbC4gIFRoZXJlIGlzIGEgc2luZ2xlIFdT REwgdXBkYXRlCiAgIG9wZXJhdGlvbiBjYWxsZWQgc3VibWl0VXBkYXRlUnFzdCwgYW5kIGEgc2lu Z2xlIFdTREwgcXVlcnkgb3BlcmF0aW9uCiAgIGNhbGxlZCBzdWJtaXRRdWVyeVJxc3QuICBUaGUg c3VibWl0VXBkYXRlUnFzdCBvcGVyYXRpb24gdGFrZXMgYXMKICAgaW5wdXQgYW4gc3BwcFVwZGF0 ZVJlcXVlc3RNc2cgb2JqZWN0IGFuZCByZXR1cm5zIGFzIG91dHB1dCBhbgogICBzcHBwVXBkYXRl UmVzcG9uc2VNc2cgb2JqZWN0LiAgVGhlc2Ugb2JqZWN0cyBfd3JhcF8gdGhlCiAgIHNwcHBVcGRh dGVSZXF1ZXN0IGFuZCBzcHBwVXBkYXRlUmVzcG9uc2Ugb2JqZWN0cyByZXNwZWN0aXZlbHkuICBU aGVzZQogICB0d28gb2JqZWN0IGRhdGEgc3RydWN0dXJlcyBhcmUgZGVzY3JpYmVkIGluIHRoZSBT UFBQIHByb3RvY29sCiAgIHNwZWNpZmljYXRpb24gW0ktRC5kcmFmdC1pZXRmLWRyaW5rcy1zcHBy b3ZdLiAgQW5kIGZpbmFsbHksIHRoZQogICBzcHBwU09BUEJpbmRpbmcgaW4gdGhlIFdTREwgZGVm aW5lcyB0aGUgYmluZGluZyBzdHlsZSBhcyBfZG9jdW1lbnRfCiAgIGFuZCB0aGUgZW5jb2Rpbmcg YXMgX2xpdGVyYWxfLiAgSXQgaXMgdGhpcyBjb21iaW5hdGlvbiBvZiBfd3JhcHBlZF8KICAgaW5w dXQgYW5kIG91dHB1dCBkYXRhIHN0cnVjdHVyZXMsIF9kb2N1bWVudF8gYmluZGluZyBzdHlsZSwg YW5kCiAgIF9saXRlcmFsXyBlbmNvZGluZyB0aGF0IGNoYXJhY3Rlcml6ZSB0aGUgRG9jdW1lbnQg TGl0ZXJhbCBXcmFwcGVkCiAgIHN0eWxlIG9mIFdTREwgc3BlY2lmaWNhdGlvbnMuCgogICBUaGUg YWR2YW50YWdlIG9mIGdlbmVyaWMgV1NETCBpcyB0aGF0IHRoZSBXU0RMIGlzIG1vcmUgc3VjY2lu Y3QsIG11Y2gKICAgc2ltcGxlciwgYW5kIHRoZXJmb3JlIG1vcmUgZWFzaWx5IG1haW50YWluZWQu ICBBcyBuZXcgdHlwZXMgb2YKICAgcHJvdG9jb2wgb2JqZWN0cyBhbmQgYWN0aW9ucyBhcmUgYWRk ZWQgaW50byBvciByZW1vdmVkIGZyb20gdGhlIFNQUFAKICAgcHJvdG9jb2wsIHRoZSBXU0RMIGRv ZXMgbm90IG5lZWQgdG8gY2hhbmdlLiAgVGhpcyBhcHByb2FjaCBpcyBtYWRlCiAgIHBvc3NpYmxl IGJ5IHRoZSBmYWN0IHRoYXQgdGhlIFNQUCBYTUwgZGF0YSB0eXBlcyBhbmQgc3VwcG9ydGVkCiAg IGFjdGlvbnMgYXJlIGRlZmluZWQgaW4gdGhlIFNQUFAgWE1MIHNjaGVtYSwgbm90IGluIHRoZSBX U0RMLiAgQXMgYQogICByZXN1bHQgdGhlIHN1cHBvcnRlZCBhY3Rpb25zIGRvIG5vdCBuZWVkIHRv IGJlIHJlLWRlZmluZWQgaGVyZSBpbnNpZGUKICAgdGhlIFNQUFAgU09BUCBXU0RMLgoKICAgTm90 ZTogVGhlIGZvbGxvd2luZyBXU0RMIGhhcyBiZWVuIGZvcm1hdHRlZCAoZS5nLiwgdGFicywgc3Bh Y2VzKSB0bwogICBtZWV0IEktRCByZXF1aXJlbWVudHMuCgoKCjw/eG1sIHZlcnNpb249IjEuMCIg ZW5jb2Rpbmc9IlVURi04Ij8+Cjx3c2RsOmRlZmluaXRpb25zIHhtbG5zOndzZGw9Imh0dHA6Ly9z Y2hlbWFzLnhtbHNvYXAub3JnL3dzZGwvIgogeG1sbnM6c29hcD0iaHR0cDovL3NjaGVtYXMueG1s c29hcC5vcmcvd3NkbC9zb2FwLyIKIHhtbG5zOnhzZD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9Y TUxTY2hlbWEiCiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWlu c3RhbmNlIgogeG1sbnM6c3BwcGI9InVybjppZXRmOnBhcmFtczp4bWw6bnM6c3BwcDpiYXNlOjEi CiB4bWxuczpzcHBwcz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzcHBwOnNvYXA6MSIKIHRhcmdl dE5hbWVzcGFjZT0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzcHBwOnNvYXA6MSIKIHhzaTpzY2hl bWFMb2NhdGlvbj0ic3BwcGJhc2UueHNkIj4KICAgICAgICA8d3NkbDp0eXBlcz4KIDx4c2Q6c2No ZW1hPgogICAgICAgICAgPHhzZDppbXBvcnQgbmFtZXNwYWNlPSJ1cm46aWV0ZjpwYXJhbXM6eG1s Om5zOnNwcHA6YmFzZToxIgogICAgICAgICAgICAgICAgICAgICAgc2NoZW1hTG9jYXRpb249InNw cHBiYXNlLnhzZCIvPgogPC94c2Q6c2NoZW1hPgogPC93c2RsOnR5cGVzPgoKCgpDYXJ0d3JpZ2h0 ICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI0LCAyMDEyICAgICAgICAgICAgICBbUGFn ZSAxMF0KDApJbnRlcm5ldC1EcmFmdCAgICAgIGRyYWZ0LWlldGYtZHJpbmtzLXNwcHAtb3Zlci1z b2FwICAgICAgICAgQXVndXN0IDIwMTEKCgogPHdzZGw6bWVzc2FnZSBuYW1lPSJzcHBwVXBkYXRl UmVxdWVzdE1zZyI+CiAgPHdzZGw6cGFydCBuYW1lPSJycXN0IiBlbGVtZW50PSJzcHBwYjpzcHBw VXBkYXRlUmVxdWVzdCIvPgogPC93c2RsOm1lc3NhZ2U+CiA8d3NkbDptZXNzYWdlIG5hbWU9InNw cHBVcGRhdGVSZXNwb25zZU1zZyI+CiAgPHdzZGw6cGFydCBuYW1lPSJyc3BucyIgZWxlbWVudD0i c3BwcGI6c3BwcFVwZGF0ZVJlc3BvbnNlIi8+CiA8L3dzZGw6bWVzc2FnZT4KIDx3c2RsOm1lc3Nh Z2UgbmFtZT0ic3BwcFF1ZXJ5UmVxdWVzdE1zZyI+CiAgPHdzZGw6cGFydCBuYW1lPSJycXN0IiBl bGVtZW50PSJzcHBwYjpzcHBwUXVlcnlSZXF1ZXN0Ii8+CiA8L3dzZGw6bWVzc2FnZT4KIDx3c2Rs Om1lc3NhZ2UgbmFtZT0ic3BwcFF1ZXJ5UmVzcG9uc2VNc2ciPgogIDx3c2RsOnBhcnQgbmFtZT0i cnNwbnMiIGVsZW1lbnQ9InNwcHBiOnNwcHBRdWVyeVJlc3BvbnNlIi8+CiA8L3dzZGw6bWVzc2Fn ZT4KIDx3c2RsOm1lc3NhZ2UgbmFtZT0ic3BwcFNlcnZlclN0YXR1c1JlcXVlc3RNc2ciPgogIDx3 c2RsOnBhcnQgbmFtZT0icnFzdCIgZWxlbWVudD0ic3BwcGI6c3BwcFNlcnZlclN0YXR1c1JlcXVl c3QiLz4KIDwvd3NkbDptZXNzYWdlPgogPHdzZGw6bWVzc2FnZSBuYW1lPSJzcHBwU2VydmVyU3Rh dHVzUmVzcG9uc2VNc2ciPgogIDx3c2RsOnBhcnQgbmFtZT0icnNwbnMiIGVsZW1lbnQ9InNwcHBi OnNwcHBTZXJ2ZXJTdGF0dXNSZXNwb25zZSIvPgogPC93c2RsOm1lc3NhZ2U+CiA8d3NkbDpwb3J0 VHlwZSBuYW1lPSJzcHBwUG9ydFR5cGUiPgogIDx3c2RsOm9wZXJhdGlvbiBuYW1lPSJzdWJtaXRV cGRhdGVScXN0Ij4KICAgPHdzZGw6aW5wdXQgbWVzc2FnZT0ic3BwcHM6c3BwcFVwZGF0ZVJlcXVl c3RNc2ciLz4KICAgPHdzZGw6b3V0cHV0IG1lc3NhZ2U9InNwcHBzOnNwcHBVcGRhdGVSZXNwb25z ZU1zZyIvPgogIDwvd3NkbDpvcGVyYXRpb24+CiAgPHdzZGw6b3BlcmF0aW9uIG5hbWU9InN1Ym1p dFF1ZXJ5UnFzdCI+CiAgIDx3c2RsOmlucHV0IG1lc3NhZ2U9InNwcHBzOnNwcHBRdWVyeVJlcXVl c3RNc2ciLz4KICAgPHdzZGw6b3V0cHV0IG1lc3NhZ2U9InNwcHBzOnNwcHBRdWVyeVJlc3BvbnNl TXNnIi8+CiAgPC93c2RsOm9wZXJhdGlvbj4KICA8d3NkbDpvcGVyYXRpb24gbmFtZT0ic3VibWl0 U2VydmVyU3RhdHVzUnFzdCI+CiAgIDx3c2RsOmlucHV0IG1lc3NhZ2U9InNwcHBzOnNwcHBTZXJ2 ZXJTdGF0dXNSZXF1ZXN0TXNnIi8+CiAgIDx3c2RsOm91dHB1dCBtZXNzYWdlPSJzcHBwczpzcHBw U2VydmVyU3RhdHVzUmVzcG9uc2VNc2ciLz4KICA8L3dzZGw6b3BlcmF0aW9uPgogPC93c2RsOnBv cnRUeXBlPgogPHdzZGw6YmluZGluZyBuYW1lPSJzcHBwU29hcEJpbmRpbmciIHR5cGU9InNwcHBz OnNwcHBQb3J0VHlwZSI+CiAgPHNvYXA6YmluZGluZyBzdHlsZT0iZG9jdW1lbnQiCiAgICAgICAg ICAgICAgICB0cmFuc3BvcnQ9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvaHR0cCIv PgogIDx3c2RsOm9wZXJhdGlvbiBuYW1lPSJzdWJtaXRVcGRhdGVScXN0Ij4KICAgPHNvYXA6b3Bl cmF0aW9uIHNvYXBBY3Rpb249InN1Ym1pdFVwZGF0ZVJxc3QiIHN0eWxlPSJkb2N1bWVudCIvPgog ICA8d3NkbDppbnB1dD4KICAgIDxzb2FwOmJvZHkgdXNlPSJsaXRlcmFsIi8+CiAgIDwvd3NkbDpp bnB1dD4KICAgPHdzZGw6b3V0cHV0PgogICAgPHNvYXA6Ym9keSB1c2U9ImxpdGVyYWwiLz4KICAg PC93c2RsOm91dHB1dD4KICA8L3dzZGw6b3BlcmF0aW9uPgogIDx3c2RsOm9wZXJhdGlvbiBuYW1l PSJzdWJtaXRRdWVyeVJxc3QiPgogICA8c29hcDpvcGVyYXRpb24gc29hcEFjdGlvbj0ic3VibWl0 UXVlcnlScXN0IiBzdHlsZT0iZG9jdW1lbnQiLz4KICAgPHdzZGw6aW5wdXQ+CiAgICA8c29hcDpi b2R5IHVzZT0ibGl0ZXJhbCIvPgoKCgpDYXJ0d3JpZ2h0ICAgICAgICAgICAgICBFeHBpcmVzIEZl YnJ1YXJ5IDI0LCAyMDEyICAgICAgICAgICAgICBbUGFnZSAxMV0KDApJbnRlcm5ldC1EcmFmdCAg ICAgIGRyYWZ0LWlldGYtZHJpbmtzLXNwcHAtb3Zlci1zb2FwICAgICAgICAgQXVndXN0IDIwMTEK CgogICA8L3dzZGw6aW5wdXQ+CiAgIDx3c2RsOm91dHB1dD4KICAgIDxzb2FwOmJvZHkgdXNlPSJs aXRlcmFsIi8+CiAgIDwvd3NkbDpvdXRwdXQ+CiAgPC93c2RsOm9wZXJhdGlvbj4KICA8d3NkbDpv cGVyYXRpb24gbmFtZT0ic3VibWl0U2VydmVyU3RhdHVzUnFzdCI+CiAgPHNvYXA6b3BlcmF0aW9u IHNvYXBBY3Rpb249InN1Ym1pdFNlcnZlclN0YXR1c1Jxc3QiIHN0eWxlPSJkb2N1bWVudCIvPgog ICA8d3NkbDppbnB1dD4KICAgIDxzb2FwOmJvZHkgdXNlPSJsaXRlcmFsIi8+CiAgIDwvd3NkbDpp bnB1dD4KICAgPHdzZGw6b3V0cHV0PgogICAgPHNvYXA6Ym9keSB1c2U9ImxpdGVyYWwiLz4KICAg PC93c2RsOm91dHB1dD4KICA8L3dzZGw6b3BlcmF0aW9uPgogPC93c2RsOmJpbmRpbmc+CiA8d3Nk bDpzZXJ2aWNlIG5hbWU9InNwcHBTZXJ2aWNlIj4KICA8d3NkbDpwb3J0IG5hbWU9InNwcHBQb3J0 IiBiaW5kaW5nPSJzcHBwczpzcHBwU29hcEJpbmRpbmciPgogICA8c29hcDphZGRyZXNzIGxvY2F0 aW9uPSJSRVBMQUNFX1dJVEhfQUNUVUFMX1VSTCIvPgogIDwvd3NkbDpwb3J0PgogPC93c2RsOnNl cnZpY2U+Cjwvd3NkbDpkZWZpbml0aW9ucz4KCgogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBGaWd1cmUgMjogV1NETAoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpDYXJ0d3JpZ2h0ICAg ICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI0LCAyMDEyICAgICAgICAgICAgICBbUGFnZSAx Ml0KDApJbnRlcm5ldC1EcmFmdCAgICAgIGRyYWZ0LWlldGYtZHJpbmtzLXNwcHAtb3Zlci1zb2Fw ICAgICAgICAgQXVndXN0IDIwMTEKCgo3LiAgU1BQUCBTT0FQIEV4YW1wbGVzCgogICBUaGlzIHNl Y3Rpb24gcHJvdmlkZXMgYSBmZXcgZXhhbXBsZXMgb2YgU1BQUCBTT0FQIG1lc3NhZ2VzLiAgVGhp cwogICBzZWN0aW9uIG9mIGNvdXJzZSByZWxpZXMgb24gdGhlIFhNTCBkYXRhIHN0cnVjdHVyZXMg ZGVmaW5lZCBpbiB0aGUKICAgU1BQUCBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIFtJLUQuZHJhZnQt aWV0Zi1kcmlua3Mtc3Bwcm92XS4gIFNvIHJlZmVyCiAgIHRvIHRoYXQgZG9jdW1lbnQgdG8gdW5k ZXJzdGFuZCBYTUwgb2JqZWN0IHR5cGVzIGVtYmVkZGVkIGluIHRoZXNlCiAgIGV4YW1wbGUgbWVz c2FnZXMuCgogICBOb3RlOiBUaGUgZm9sbG93aW5nIGV4YW1wbGVzIGhhdmUgYmVlbiBmb3JtYXR0 ZWQgKGUuZy4sIHRhYnMsIHNwYWNlcykKICAgdG8gbWVldCBJLUQgcmVxdWlyZW1lbnRzLgoKCgog IDxzb2FwZW52OkVudmVsb3BlCiAgeG1sbnM6c29hcGVudj0iaHR0cDovL3NjaGVtYXMueG1sc29h cC5vcmcvc29hcC9lbnZlbG9wZS8iCiAgeG1sbnM6c3BiPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5z OnNwcHA6YmFzZToxIj4KICAgIDxzb2FwZW52OkhlYWRlci8+CiAgICA8c29hcGVudjpCb2R5Pgog ICAgICAgIDxzcGI6c3BwcFVwZGF0ZVJlcXVlc3QKICAgICAgICB4c2k6c2NoZW1hTG9jYXRpb249 InVybjppZXRmOnBhcmFtczp4bWw6bnM6c3BwcDpiYXNlOjEgc3BwcC54c2QiCiAgICAgICAgeG1s bnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6c3BwcDpiYXNlOjEiCiAgICAgICAgeG1sbnM6eHNp PSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0YW5jZSI+CiAgICAgICAgICAg IDxzcGI6Y2xpZW50VHJhbnNJZD44ODg8L3NwYjpjbGllbnRUcmFuc0lkPgogICAgICAgICAgICA8 c3BiOm1pbm9yVmVyPjE8L3NwYjptaW5vclZlcj4KICAgICAgICAgICAgPHNwYjpycXN0IHhzaTp0 eXBlPSJzcGI6QWRkRGVzdEdycFJxc3RUeXBlIj4KICAgICAgICAgICAgICA8c3BiOmRlc3RHcnA+ CiAgICAgICAgICAgICAgICAgPHNwYjpyYW50PnJlZ2lzdHJhbnQyPC9zcGI6cmFudD4KICAgICAg ICAgICAgICAgICAgICAgPHNwYjpkZ05hbWU+REVTVF9HUlBfU1BQUF81PC9zcGI6ZGdOYW1lPgog ICAgICAgICAgICAgIDwvc3BiOmRlc3RHcnA+CiAgICAgICAgICAgIDwvc3BiOnJxc3Q+CiAgICAg ICAgIDwvc3BiOnNwcHBVcGRhdGVSZXF1ZXN0PgogICAgPC9zb2FwZW52OkJvZHk+CiAgPC9zb2Fw ZW52OkVudmVsb3BlPgoKCiAgICAgRmlndXJlIDM6IEV4YW1wbGUgMSAtIFNQUFAgVXBkYXRlIFJl cXVlc3QgLSBBZGQgRGVzdGluYXRpb24gR3JvdXAKCgoKCgoKCgoKCgoKCgoKQ2FydHdyaWdodCAg ICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2Ug MTNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICBkcmFmdC1pZXRmLWRyaW5rcy1zcHBwLW92ZXItc29h cCAgICAgICAgIEF1Z3VzdCAyMDExCgoKICA8c29hcGVudjpFbnZlbG9wZQogIHhtbG5zOnNvYXBl bnY9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIgogIHhtbG5zOnNw Yj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzcHBwOmJhc2U6MSI+CiAgICAgPHNvYXBlbnY6SGVh ZGVyLz4KICAgICA8c29hcGVudjpCb2R5PgogICAgICAgIDxzcGI6c3BwcFF1ZXJ5UmVxdWVzdAog ICAgICAgIHhzaTpzY2hlbWFMb2NhdGlvbj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzcHBwOmJh c2U6MSBzcHBwLnhzZCIKICAgICAgICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzcHBw OmJhc2U6MSIKICAgICAgICB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2No ZW1hLWluc3RhbmNlIj4KICAgICAgICAgICAgPHNwYjptaW5vclZlcj4xPC9zcGI6bWlub3JWZXI+ CiAgICAgICAgICAgIDxzcGI6cnFzdCB4c2k6dHlwZT0ic3BiOkdldERlc3RHcnBzUnFzdFR5cGUi PgogICAgICAgICAgICAgICAgPHNwYjpvYmpLZXk+CiAgICAgICAgICAgICAgICAgICAgPHNwYjpy YW50PnJlZ2lzdHJhbnQyPC9zcGI6cmFudD4KICAgICAgICAgICAgICAgICAgICA8c3BiOm5hbWU+ REVTVF9HUlBfU1BQUF81PC9zcGI6bmFtZT4KICAgICAgICAgICAgICAgIDwvc3BiOm9iaktleT4K ICAgICAgICAgICAgPC9zcGI6cnFzdD4KICAgICAgICA8L3NwYjpzcHBwUXVlcnlSZXF1ZXN0Pgog ICAgIDwvc29hcGVudjpCb2R5PgogIDwvc29hcGVudjpFbnZlbG9wZT4KCgogICAgIEZpZ3VyZSA0 OiBFeGFtcGxlIDIgLSBTUFBQIFF1ZXJ5IFJlcXVlc3QgLSBHZXQgRGVzdGluYXRpb24gR3JvdXAK CgoKICA8c29hcGVudjpFbnZlbG9wZQogIHhtbG5zOnNvYXBlbnY9Imh0dHA6Ly9zY2hlbWFzLnht bHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIgogIHhtbG5zOnNwYj0idXJuOmlldGY6cGFyYW1zOnht bDpuczpzcHBwOmJhc2U6MSI+CiAgICAgPHNvYXBlbnY6SGVhZGVyLz4KICAgICA8c29hcGVudjpC b2R5PgogICAgICAgIDxzcGI6c3BwcFF1ZXJ5UmVxdWVzdAogICAgICAgIHhzaTpzY2hlbWFMb2Nh dGlvbj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzcHBwOmJhc2U6MSBzcHBwLnhzZCIKICAgICAg ICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzcHBwOmJhc2U6MSIKICAgICAgICB4bWxu czp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIj4KICAgICAg ICAgICAgPHNwYjpjbGllbnRUcmFuc0lkPjk5OTwvc3BiOmNsaWVudFRyYW5zSWQ+CiAgICAgICAg ICAgIDxzcGI6bWlub3JWZXI+MTwvc3BiOm1pbm9yVmVyPgogICAgICAgICAgICA8c3BiOnJxc3Qg eHNpOnR5cGU9InNwYjpEZWxEZXN0R3JwUnFzdFR5cGUiPgogICAgICAgICAgICAgICAgPHNwYjpv YmpLZXk+CiAgICAgICAgICAgICAgICAgICAgPHNwYjpyYW50PnJlZ2lzdHJhbnQyPC9zcGI6cmFu dD4KICAgICAgICAgICAgICAgICAgICA8c3BiOm5hbWU+REVTVF9HUlBfU1BQUF81PC9zcGI6bmFt ZT4KICAgICAgICAgICAgICAgIDwvc3BiOm9iaktleT4KICAgICAgICAgICAgPC9zcGI6cnFzdD4K ICAgICAgICA8L3NwYjpzcHBwUXVlcnlSZXF1ZXN0PgogICAgIDwvc29hcGVudjpCb2R5PgogIDwv c29hcGVudjpFbnZlbG9wZT4KCgogICAgIEZpZ3VyZSA1OiBFeGFtcGxlIDIgLSBTUFBQIFF1ZXJ5 IFJlcXVlc3QgLSBEZWwgRGVzdGluYXRpb24gR3JvdXAKCgoKQ2FydHdyaWdodCAgICAgICAgICAg ICAgRXhwaXJlcyBGZWJydWFyeSAyNCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgMTRdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICBkcmFmdC1pZXRmLWRyaW5rcy1zcHBwLW92ZXItc29hcCAgICAgICAg IEF1Z3VzdCAyMDExCgoKOC4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zCgogICBTUFBQIGlzIHVz ZWQgdG8gcXVlcnkgYW5kIHVwZGF0ZSBzZXNzaW9uIHBlZXJpbmcgZGF0YSBhbmQgYWRkcmVzc2Vz LAogICBzbyB0aGUgYWJpbGl0eSB0byBhY2Nlc3MgdGhpcyBwcm90b2NvbCBzaG91bGQgYmUgbGlt aXRlZCB0byB1c2VycyBhbmQKICAgc3lzdGVtcyB0aGF0IGFyZSBhdXRob3JpemVkIHRvIHF1ZXJ5 IGFuZCB1cGRhdGUgdGhpcyBkYXRhLiAgQmVjYXVzZQogICB0aGlzIGRhdGEgaXMgc2VudCBpbiBi b3RoIGRpcmVjdGlvbnMsIGl0IG1heSBub3QgYmUgc3VmZmljaWVudCBmb3IKICAganVzdCB0aGUg Y2xpZW50IG9yIHVzZXIgdG8gYmUgYXV0aGVudGljYXRlZCB3aXRoIHRoZSBzZXJ2ZXIuICBUaGUK ICAgaWRlbnRpdHkgb2YgdGhlIHNlcnZlciBzaG91bGQgYWxzbyBiZSBhdXRoZW50aWNhdGVkIGJ5 IHRoZSBjbGllbnQsCiAgIHdoaWNoIGlzIG9mdGVuIGFjY29tcGxpc2hlZCB1c2luZyB0aGUgVExT IGNlcnRpZmljYXRlIGV4Y2hhbmdlIGFuZAogICB2YWxpZGF0aW9uIGRlc2NyaWJlZCBpbiBbUkZD MjgxOF0uICBTUFBQIGRhdGEgbWF5IGluY2x1ZGUgc2Vuc2l0aXZlCiAgIGluZm9ybWF0aW9uLCBy b3V0aW5nIGRhdGEsIGxpc3RzIG9mIHJlc29sdmFibGUgYWRkcmVzc2VzLCBldGMuICBTbwogICB3 aGVuIHVzZWQgaW4gYSBwcm9kdWN0aW9uIHNldHRpbmcgYW5kIGFjcm9zcyBub24tc2VjdXJlIG5l dHdvcmtzLAogICBTUFBQIHNob3VsZCBvbmx5IGJlIHVzZWQgb3ZlciBjb21tdW5pY2F0aW9ucyBj aGFubmVscyB0aGF0IHByb3ZpZGUKICAgc3Ryb25nIGVuY3J5cHRpb24gZm9yIGRhdGEgcHJpdmFj eS4KCjguMS4gIEludGVncml0eSwgUHJpdmFjeSwgYW5kIEF1dGhlbnRpY2F0aW9uCgogICBUaGUg U1BQUCBTT0FQIGJpbmRpbmcgcmVsaWVzIG9uIGFuIHVuZGVybHlpbmcgc2VjdXJlIHRyYW5zcG9y dCBmb3IKICAgaW50ZWdyaXR5IGFuZCBwcml2YWN5LiAgU3VjaCB0cmFuc3BvcnRzIGFyZSBleHBl Y3RlZCB0byBpbmNsdWRlIFRMUy8KICAgSFRUUFMuICBJbiBhZGRpdGlvbiB0byB0aGUgYXBwbGlj YXRpb24gbGV2ZWwgYXV0aGVudGljYXRpb24gaW1wb3NlZAogICBieSBhbiBTUFBQIHNlcnZlciwg dGhlcmUgYXJlIGEgbnVtYmVyIG9mIG9wdGlvbnMgZm9yIGF1dGhlbnRpY2F0aW9uCiAgIHdpdGhp biB0aGUgdHJhbnNwb3J0IGxheWVyIGFuZCB0aGUgbWVzc2FnaW5nIGVudmVsb3BlLiAgVGhlc2Ug aW5jbHVkZQogICBUTFMgY2xpZW50IGNlcnRpZmljYXRlcywgSFRUUCBEaWdlc3QgQWNjZXNzIEF1 dGhlbnRpY2F0aW9uLCBhbmQKICAgZGlnaXRhbCBzaWduYXR1cmVzIHdpdGhpbiBTT0FQIGhlYWRl cnMuCgogICBBdCBhIG1pbml1bXVtLCBhbGwgY29uZm9ybWluZyBTUFBQIG92ZXIgU09BUCBpbXBs ZW1lbnRhdGlvbnMgTVVTVAogICBzdXBwb3J0IEhUVFBTLgoKOC4yLiAgVnVsbmVyYWJpbGl0aWVz CgogICBUaGUgYWJvdmUgcHJvdG9jb2xzIG1heSBoYXZlIHZhcmlvdXMgdnVsbmVyYWJpbGl0aWVz LCBhbmQgdGhlc2UgbWF5CiAgIGJlIGluaGVyaXRlZCBieSBTUFBQIG92ZXIgU09BUC4gIEFuZCBT UFBQIGl0c2VsZiBtYXkgaGF2ZQogICB2dWxuZXJhYmlsaXRpZXMgYmVjYXVzZSBhbiBhdXRob3Jp emF0aW9uIG1vZGVsIGlzIG5vdCBleHBsaWNpdGx5CiAgIHNwZWNpZmllZCBpbiB0aGUgY3VycmVu dCBzcGVjaWZpY2F0aW9uLgoKICAgSXQgaXMgaW1wb3J0YW50IHRoYXQgU1BQUCBpbXBsZW1lbnRh dGlvbnMgaW1wbGVtZW50IGFuIGF1dGhvcml6YXRpb24KICAgbW9kZWwgdGhhdCBjb25zaWRlcnMg dGhlIHNvdXJjZSBvZiBlYWNoIFNQUFAgcXVlcnkgb3IgdXBkYXRlIHJlcXVlc3QKICAgYW5kIGRl dGVybWluZXMgd2hldGhlciBpdCBpcyByZWFzb25hYmxlIHRvIGF1dGhvcml6ZSB0aGF0IHNvdXJj ZSB0bwogICBwZXJmb3JtIHRoYXQgc3BlY2lmaWMgcXVlcnkgb3IgdXBkYXRlLgoKOC4zLiAgRGVw bG95bWVudCBFbnZpcm9ubWVudCBTcGVjaWZpY3MKCiAgIFNvbWUgZGVwbG95bWVudHMgb2YgU1BQ UCBvdmVyIFNPQVAgY291bGQgY2hvb3NlIHRvIHVzZSB0cmFuc3BvcnRzCiAgIHdpdGhvdXQgZW5j cnlwdGlvbi4gIFRoaXMgcHJlc2VudHMgdnVsbmVyYWJpbGl0aWVzIGJ1dCBjb3VsZCBiZQogICBz ZWxlY3RlZCBmb3IgZGVwbG95bWVudHMgaW52b2x2aW5nIGNsb3NlZCBuZXR3b3JrcyBvciBkZWJ1 Z2dpbmcKICAgc2NlbmFyaW9zLiAgSG93ZXZlciwgdGhlIHZ1bG5lcmFiaWxpdGllcyBvZiBzdWNo IGEgZGVwbG95bWVudCBjb3VsZAogICBiZSBhIGxhY2sgb2YgaW50ZWdyaXR5IGFuZCBwcml2YWN5 IG9mIHRoZSBkYXRhIHRyYW5zcG9ydGVkIG92ZXIgU1BQUAogICBtZXNzYWdlcyBpbiB0aGlzIHR5 cGUgb2YgZGVwbG95bWVudC4KCgoKQ2FydHdyaWdodCAgICAgICAgICAgICAgRXhwaXJlcyBGZWJy dWFyeSAyNCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgMTVdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICBkcmFmdC1pZXRmLWRyaW5rcy1zcHBwLW92ZXItc29hcCAgICAgICAgIEF1Z3VzdCAyMDExCgoK OS4gIElBTkEgQ29uc2lkZXJhdGlvbnMKCiAgIFRoaXMgZG9jdW1lbnQgdXNlcyBVUk5zIHRvIGRl c2NyaWJlIFhNTCBuYW1lc3BhY2VzIGFuZCBYTUwgc2NoZW1hcwogICBjb25mb3JtaW5nIHRvIGEg cmVnaXN0cnkgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiBbUkZDMzY4OF0uCgogICBVUk4gYXNzaWdu bWVudHMgYXJlIHJlcXVlc3RlZDogdXJuOmlldGY6cGFyYW1zOnhtbDpuczpzcHBwOnNvYXAKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKQ2FydHdyaWdodCAgICAg ICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgMTZd CgwKSW50ZXJuZXQtRHJhZnQgICAgICBkcmFmdC1pZXRmLWRyaW5rcy1zcHBwLW92ZXItc29hcCAg ICAgICAgIEF1Z3VzdCAyMDExCgoKMTAuICBBY2tub3dsZWRnZW1lbnRzCgogICBUaGlzIGRvY3Vt ZW50IGlzIGEgcmVzdWx0IG9mIHZhcmlvdXMgZGlzY3Vzc2lvbnMgaGVsZCBieSB0aGUgRFJJTktT CiAgIGRlc2lnbiB0ZWFtLCB3aGljaCBpcyBjb21wcmlzZWQgb2YgdGhlIGZvbGxvd2luZyBpbmRp dmlkdWFscywgaW4gbm8KICAgc3BlY2lmaWMgb3JkZXI6IFN5ZWQgQWxpIChOZXVTdGFyKSwgU3Vt YW50aCBDaGFubmFiYXNhcHBhIChDYWJsZQogICBMYWJzKSwgRGF2aWQgU2Nod2FydHogKFhDb25u ZWN0KSwgSmVhbi1GcmFuY29pcyBNdWxlIChDYWJsZUxhYnMpLAogICBLZW5uZXRoIENhcnR3cmln aHQgKFROUywgSW5jLiksIE1hbmp1bCBNYWhhcmlzaGkgKFROUywgSW5jLiksCiAgIEFsZXhhbmRl ciBNYXlyaG9mZXIgKGVudW0uYXQgR21iSCkuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgpDYXJ0d3JpZ2h0ICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI0 LCAyMDEyICAgICAgICAgICAgICBbUGFnZSAxN10KDApJbnRlcm5ldC1EcmFmdCAgICAgIGRyYWZ0 LWlldGYtZHJpbmtzLXNwcHAtb3Zlci1zb2FwICAgICAgICAgQXVndXN0IDIwMTEKCgoxMS4gIFJl ZmVyZW5jZXMKCjExLjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW0ktRC5kcmFmdC1pZXRm LWRyaW5rcy1zcHByb3ZdCiAgICAgICAgICAgICAgTXVsZSwgSi1GLiwgQ2FydHdyaWdodCwgSy4s IEFsaSwgUy4sIGFuZCBBLiBNYXlyaG9mZXIsCiAgICAgICAgICAgICAgIkRSSU5LUyBVc2UgY2Fz ZXMgYW5kIFByb3RvY29sIFJlcXVpcmVtZW50cyIsCiAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1k cmlua3Mtc3Bwcm92LTA3ICh3b3JrIGluIHByb2dyZXNzKSwgSnVuZSAyMDExLgoKICAgW1JGQzIx MTldICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUK ICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJj aCAxOTk3LgoKICAgW1JGQzI2MTZdICBGaWVsZGluZywgUi4sIEdldHR5cywgSi4sIE1vZ3VsLCBK LiwgRnJ5c3R5aywgSC4sCiAgICAgICAgICAgICAgTWFzaW50ZXIsIEwuLCBMZWFjaCwgUC4sIGFu ZCBULiBCZXJuZXJzLUxlZSwgIkh5cGVydGV4dAogICAgICAgICAgICAgIFRyYW5zZmVyIFByb3Rv Y29sIC0tIEhUVFAvMS4xIiwgUkZDIDI2MTYsIEp1bmUgMTk5OS4KCiAgIFtSRkMyNjE3XSAgRnJh bmtzLCBKLiwgSGFsbGFtLUJha2VyLCBQLiwgSG9zdGV0bGVyLCBKLiwgTGF3cmVuY2UsIFMuLAog ICAgICAgICAgICAgIExlYWNoLCBQLiwgTHVvdG9uZW4sIEEuLCBhbmQgTC4gU3Rld2FydCwgIkhU VFAKICAgICAgICAgICAgICBBdXRoZW50aWNhdGlvbjogQmFzaWMgYW5kIERpZ2VzdCBBY2Nlc3Mg QXV0aGVudGljYXRpb24iLAogICAgICAgICAgICAgIFJGQyAyNjE3LCBKdW5lIDE5OTkuCgogICBb UkZDMjgxOF0gIFJlc2NvcmxhLCBFLiwgIkhUVFAgT3ZlciBUTFMiLCBSRkMgMjgxOCwgTWF5IDIw MDAuCgogICBbUkZDMzY4OF0gIE1lYWxsaW5nLCBNLiwgIlRoZSBJRVRGIFhNTCBSZWdpc3RyeSIs IEJDUCA4MSwgUkZDIDM2ODgsCiAgICAgICAgICAgICAgSmFudWFyeSAyMDA0LgoKICAgW1JGQzUy NDZdICBEaWVya3MsIFQuIGFuZCBFLiBSZXNjb3JsYSwgIlRoZSBUcmFuc3BvcnQgTGF5ZXIgU2Vj dXJpdHkKICAgICAgICAgICAgICAoVExTKSBQcm90b2NvbCBWZXJzaW9uIDEuMiIsIFJGQyA1MjQ2 LCBBdWd1c3QgMjAwOC4KCiAgIFtTT0FQUkVGXSAgR3VkZ2luLCBNLiwgSGFkbGV5LCBNLiwgTW9y ZWF1LCBKLiwgYW5kIEguIE5pZWxzZW4sICJTT0FQCiAgICAgICAgICAgICAgVmVyc2lvbiAxLjIg UGFydCAxOiBNZXNzYWdpbmcgRnJhbWV3b3JrIiwgVzNDCiAgICAgICAgICAgICAgUmVjb21tZW5k YXRpb24gUkVDLVNPQVAxMi1wYXJ0MS0yMDAzMDYyNCwgSnVuZSAyMDAyLgoKMTEuMi4gIEluZm9y bWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtXU0RMUkVGXSAgQ2hyaXN0ZW5zZW4sIEUuLCBDdXJiZXJh LCBGLiwgTWVyZWRpdGgsIEcuLCBhbmQgUy4KICAgICAgICAgICAgICBXZWVyYXdhcmFuYSwgIldl YiBTZXJ2aWNlcyBEZXNjcmlwdGlvbiBMYW5ndWFnZSAoV1NETCkKICAgICAgICAgICAgICAxLjEi LCBXM0MgTm90ZSBOT1RFLXdzZGwtMjAwMTAzMTUsIE1hcmNoIDIwMDEuCgoKCgoKCgoKCgoKCgpD YXJ0d3JpZ2h0ICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI0LCAyMDEyICAgICAgICAg ICAgICBbUGFnZSAxOF0KDApJbnRlcm5ldC1EcmFmdCAgICAgIGRyYWZ0LWlldGYtZHJpbmtzLXNw cHAtb3Zlci1zb2FwICAgICAgICAgQXVndXN0IDIwMTEKCgpBdXRob3IncyBBZGRyZXNzCgogICBL ZW5uZXRoIENhcnR3cmlnaHQKICAgVE5TCiAgIDE5MzkgUm9sYW5kIENsYXJrZSBQbGFjZQogICBS ZXN0b24sIFZBICAyMDE5MQogICBVU0EKCiAgIEVtYWlsOiBrY2FydHdyaWdodEB0bnNpLmNvbQoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpDYXJ0d3JpZ2h0ICAgICAg ICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI0LCAyMDEyICAgICAgICAgICAgICBbUGFnZSAxOV0K DAo= --_003_754963199212404AB8E9CFCA6C3D0CDA38DDB8C58DTNSMAILNAwin2_-- From dean.willis@softarmor.com Tue Aug 23 14:04:29 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48FB021F8D3B for ; Tue, 23 Aug 2011 14:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.356 X-Spam-Level: X-Spam-Status: No, score=-103.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDEtU2gJpeOn for ; Tue, 23 Aug 2011 14:04:28 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 969A821F8D3A for ; Tue, 23 Aug 2011 14:04:28 -0700 (PDT) Received: by gwb20 with SMTP id 20so499824gwb.31 for ; Tue, 23 Aug 2011 14:05:37 -0700 (PDT) Received: by 10.90.19.10 with SMTP id 10mr4244699ags.133.1314133537076; Tue, 23 Aug 2011 14:05:37 -0700 (PDT) Received: from [192.168.2.143] (cpe-66-25-15-110.tx.res.rr.com [66.25.15.110]) by mx.google.com with ESMTPS id s62sm176514yhn.19.2011.08.23.14.05.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Aug 2011 14:05:36 -0700 (PDT) From: Dean Willis Content-Type: text/plain; charset=us-ascii Message-Id: Date: Tue, 23 Aug 2011 16:05:34 -0500 To: drinks@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [drinks] Thoughts on "Organization" in draft-ietf-drinks-spprov-09 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 21:04:29 -0000 The spprov draft uses Organization as a sort of owner-and-association ID = for registry objects. Current text defines it thusly: o Organization: An Organization is an entity that may fulfill the role of a registrant or a peering organization. All SPPP objects are associated with an organization identifier to identify each object's registrant, while tracking the identity of the registrar that provisioned each SPPP object is left as a matter of policy for an SPPP implementation. A Route Group object is also associated with a set of zero or more organization identifiers that identify the peering organization(s) whose resolution query responses may include the routing information (SED) defined in the Route Records within that Route Group. A peering organization is an entity that the registrant intends to share the SED data with. A route group SPPP object is associated with a set of zero or more organization identifiers that identify the peering organizations whose resolution query responses may include the routing information (SED) defined in the route records within that route group. So, Organization is a very important thing. It controls 1) who "owns" = an object, possibly for the purpose (it's not clear to me) of = controlling write access to that object. Some objects contain a list of = Organizations with read access to the object. It's also used in = controlling offer-and-acceptance in peering operations. So, sometimes = "Organization" also controls read access to an object. Would using Organization as an authentication ID (or auth-ID key) and = subsequently using the requester's authenticated Organization as a data = access mask be okay? Or do we need to have another table that relates = user-IDs and organizations for access control purposes, on the = assumption that some organizations have multiple authenticated users and = that some authenticated users have access to multiple Organizations? Furthermore, the protocol defines no mechanism of adding, querying. or = changing Organizations. Such operations are outside of the scope of the = protocol. For the OpenSPP project work, we've just manually shoved test = records into an Organization table. I've "broken" my test environment a = dozen times by dropping the database, reinitializing the schema, and = then forgetting to manually insert the Organization records needed to = run our test cases. If those test cases started with a bunch of = "AddOrganization" use cases, I probably wouldn't forget. Point 1: A more concise explanation of the utility of Organization in = both authentication and authorization is required. This doesn't need to = be overly complex: A brief discourse on the relationship between = "authenticated user" and Organization at the top level and the addition = of an "Authorization" discussion in each access method would suffice. Point 2: Given that the protocol does not include manipulation of = Organization, it's impossible to actually initialize a registry using = the protocol functions. Something external has to initialize the = Organization records. Is this how we want it to be? If yes, then we need = to document this in the protocol specifications (probably 1 added = paragraph). If no, then we need to add some protocol primitives to = address it (GetOrg, UpdateOrg, DelOrg) -- Dean From kcartwright@tnsi.com Wed Aug 24 06:45:50 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A8121F86EA for ; Wed, 24 Aug 2011 06:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgOT+8oSnY8o for ; Wed, 24 Aug 2011 06:45:49 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1FD21F86DD for ; Wed, 24 Aug 2011 06:45:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkAAML/VE6sEQfn/2dsb2JhbAA4AQmYHpBQgUABAQEBAwEBATc0BBcCAQgRBAEBHxAnCx0IAQEEARACCIdtu1+DJwGCQl8EpDAg X-IronPort-AV: E=Sophos;i="4.68,275,1312153200"; d="scan'208";a="136720" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 24 Aug 2011 14:46:56 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Wed, 24 Aug 2011 09:46:55 -0400 From: "Cartwright, Ken" To: Dean Willis , "drinks@ietf.org" Date: Wed, 24 Aug 2011 09:43:24 -0400 Thread-Topic: [drinks] Thoughts on "Organization" in draft-ietf-drinks-spprov-09 Thread-Index: Acxh2HAOs44bG5/jRhOgTfr37h2+uAAi1uTZ Message-ID: <754963199212404AB8E9CFCA6C3D0CDA38DD5F2E9E@TNS-MAIL-NA.win2k.corp.tnsi.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [drinks] Thoughts on "Organization" in draft-ietf-drinks-spprov-09 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 13:45:50 -0000 Point 1: Maybe. On the other hand it is not the purpose of the spec to de= scribe how to implement a protocol server. Imo, this discussion would get = into that realm. Point 2: As we've discussed the creation of organizations happens outside = the protocol. The job of setting up organization identifiers and their ass= ociated authentication credentials and their authorization roles is not the= purpose of this protocol, not should it be. Ken ________________________________________ From: drinks-bounces@ietf.org [drinks-bounces@ietf.org] On Behalf Of Dean W= illis [dean.willis@softarmor.com] Sent: Tuesday, August 23, 2011 5:05 PM To: drinks@ietf.org Subject: [drinks] Thoughts on "Organization" in draft-ietf-drinks-spprov-09 The spprov draft uses Organization as a sort of owner-and-association ID fo= r registry objects. Current text defines it thusly: o Organization: An Organization is an entity that may fulfill the role of a registrant or a peering organization. All SPPP objects are associated with an organization identifier to identify each object's registrant, while tracking the identity of the registrar that provisioned each SPPP object is left as a matter of policy for an SPPP implementation. A Route Group object is also associated with a set of zero or more organization identifiers that identify the peering organization(s) whose resolution query responses may include the routing information (SED) defined in the Route Records within that Route Group. A peering organization is an entity that the registrant intends to share the SED data with. A route group SPPP object is associated with a set of zero or more organization identifiers that identify the peering organizations whose resolution query responses may include the routing information (SED) defined in the route records within that route group. So, Organization is a very important thing. It controls 1) who "owns" an o= bject, possibly for the purpose (it's not clear to me) of controlling write= access to that object. Some objects contain a list of Organizations with r= ead access to the object. It's also used in controlling offer-and-acceptan= ce in peering operations. So, sometimes "Organization" also controls read a= ccess to an object. Would using Organization as an authentication ID (or auth-ID key) and subse= quently using the requester's authenticated Organization as a data access m= ask be okay? Or do we need to have another table that relates user-IDs and = organizations for access control purposes, on the assumption that some orga= nizations have multiple authenticated users and that some authenticated use= rs have access to multiple Organizations? Furthermore, the protocol defines no mechanism of adding, querying. or chan= ging Organizations. Such operations are outside of the scope of the protoc= ol. For the OpenSPP project work, we've just manually shoved test records i= nto an Organization table. I've "broken" my test environment a dozen times = by dropping the database, reinitializing the schema, and then forgetting to= manually insert the Organization records needed to run our test cases. If = those test cases started with a bunch of "AddOrganization" use cases, I pro= bably wouldn't forget. Point 1: A more concise explanation of the utility of Organization in both = authentication and authorization is required. This doesn't need to be overl= y complex: A brief discourse on the relationship between "authenticated use= r" and Organization at the top level and the addition of an "Authorization= " discussion in each access method would suffice. Point 2: Given that the protocol does not include manipulation of Organizat= ion, it's impossible to actually initialize a registry using the protocol f= unctions. Something external has to initialize the Organization records. I= s this how we want it to be? If yes, then we need to document this in the p= rotocol specifications (probably 1 added paragraph). If no, then we need to= add some protocol primitives to address it (GetOrg, UpdateOrg, DelOrg) -- Dean _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From sumanth@cablelabs.com Wed Aug 24 09:46:57 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F91A21F8C52 for ; Wed, 24 Aug 2011 09:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.388 X-Spam-Level: X-Spam-Status: No, score=-0.388 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ym7ueoveI8sJ for ; Wed, 24 Aug 2011 09:46:56 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC1C21F8C4E for ; Wed, 24 Aug 2011 09:46:53 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id p7OGm3E5008110 for ; Wed, 24 Aug 2011 10:48:03 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 24 Aug 2011 10:48:03 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 24 Aug 2011 10:48:03 -0600 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Wed, 24 Aug 2011 10:48:01 -0600 Thread-Topic: INTERIM meeting is a week away! Thread-Index: AcxifYN2dY9xH7UhQ9KZgDt+oFQIbA== Message-ID: <76AC5FEF83F1E64491446437EA81A61F81908058D0@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] INTERIM meeting is a week away! X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 16:46:57 -0000 Folks, A reminder that the DRINKS interim meeting will be held on Aug 31st, 2011 (= next Wednesday). Here are the details and the proposed agenda. Please send = any comments or request for agenda time asap. Date and Time =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Wed, Aug 31 2011 - 01:00 PM - 05:00 PM (Eastern)/ 17:00 - 21:00 (UTC) -- use http://www.tim= ezoneconverter.com or equivalent to check local times Location =3D=3D=3D=3D=3D=3D - Virtual; via GoToMeeting and a teleconference bridge (you can use the bui= lt-in VoIP or use the call-in number) - Link:=20 https://www1.gotomeeting.com/join/259806864=20 - Call-in Dial : +1 (636) 277-0134 Access Code: 259-806-864 AGENDA =3D=3D=3D=3D=3D=3D=3D 0/ Administrivia (note well, scribes) -- ~10 mts 1/ Review and resolve open items related to the following=20 a) protocol document (draft-ietf-drinks-spprov) -- ~= 120 mts b) transport document (draft-ietf-drinks-sppp-over-soap) -- ~45 mts 2/ Discuss and respond to the ITU liaison -- ~15 mts 3/ Open Discussion -- ~30 mts 4/ Next Steps -- ~15 mts - Sumanth & Alex=20 From dean.willis@softarmor.com Thu Aug 25 06:53:15 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B258421F8797 for ; Thu, 25 Aug 2011 06:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.374 X-Spam-Level: X-Spam-Status: No, score=-103.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eBfMR6W8jHX for ; Thu, 25 Aug 2011 06:53:15 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 26F5B21F877B for ; Thu, 25 Aug 2011 06:53:15 -0700 (PDT) Received: by gwb20 with SMTP id 20so2093877gwb.31 for ; Thu, 25 Aug 2011 06:54:28 -0700 (PDT) Received: by 10.90.16.10 with SMTP id 10mr5666783agp.190.1314280468044; Thu, 25 Aug 2011 06:54:28 -0700 (PDT) Received: from dwillis-mb1.local (cpe-66-25-15-110.tx.res.rr.com [66.25.15.110]) by mx.google.com with ESMTPS id n15sm546607anm.31.2011.08.25.06.54.26 (version=SSLv3 cipher=OTHER); Thu, 25 Aug 2011 06:54:27 -0700 (PDT) Message-ID: <4E5651F2.2090307@softarmor.com> Date: Thu, 25 Aug 2011 08:45:22 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "Cartwright, Ken" References: <754963199212404AB8E9CFCA6C3D0CDA38DD5F2E9E@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA38DD5F2E9E@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "drinks@ietf.org" Subject: Re: [drinks] Thoughts on "Organization" in draft-ietf-drinks-spprov-09 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 13:53:15 -0000 On 8/24/11 8:43 AM, Cartwright, Ken wrote: > Point 1: Maybe. On the other hand it is not the purpose of the spec > to describe how to implement a protocol server. Imo, this discussion > would get into that realm. Many at the IETF feel that the purpose of an IETF protocol specification is to allow for multiple interoperable implementations of a protocol. I suspect that without making the relationships between Owner and other things clear, we won't get interoperability. > Point 2: As we've discussed the creation of organizations happens > outside the protocol. The job of setting up organization > identifiers and their associated authentication credentials and > their authorization roles is not the purpose of this protocol, not > should it be. From the Abstract: This document describes the Session Peering Provisioning Protocol used by clients to provision registries. We can't use the protocol to provision a registry without (somehow) provisioning Owner objects. As defined, the protocol doesn't manipulate Owner objects. Given this constraint, does the protocol meet the goals laid out in the Abstract? Perhaps this could be addressed in the protocol specification by declaring Owner "out of scope" and stating that some other protocol is required for manipulating Owner? -- Dean From sumanth@cablelabs.com Thu Aug 25 08:41:06 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3DD921F8561 for ; Thu, 25 Aug 2011 08:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.395 X-Spam-Level: X-Spam-Status: No, score=-0.395 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ybnKqccFflp for ; Thu, 25 Aug 2011 08:41:06 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE0C21F852C for ; Thu, 25 Aug 2011 08:41:06 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id p7PFgIqa025755 for ; Thu, 25 Aug 2011 09:42:19 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Thu, 25 Aug 2011 09:42:18 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 25 Aug 2011 09:42:19 -0600 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Thu, 25 Aug 2011 09:42:17 -0600 Thread-Topic: Rough Notes and AI list from the design team call on 8/25 (and note about call on 8/17) Thread-Index: AcxjPTVe+6R6xiZ7R3G+6ONeXmuNcA== Message-ID: <76AC5FEF83F1E64491446437EA81A61F81908059B4@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] Rough Notes and AI list from the design team call on 8/25 (and note about call on 8/17) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 15:41:06 -0000 Folks, I am enclosing some brief notes and the AI list from the call today. FYI, w= e did hold a call on 8/17 and I did not get a chance to send the notes, sor= ry. The attendees were: Ken, Syed, Sumanth; and Dean Willis who spoke on be= half of the implementation team. The discussions were a prelude to the disc= ussion on the mailing list (refer to Dean's email to the list) and the ones= we had today. Given that these discussions are expected to carry over to t= he mailing list, I am not noting them separately.=20 - S IETF DRINKS DESIGN TEAM CALL=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D 8/25/2011, 10:00a-11:05a (Eastern)/8:00a-9:05a (Mountain) =20 Participants =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Alex Mayrhofer - Dean Willis - Syed Ali - Ken Cartwright - Jeremy Barkan - Sumanth Channabasappa=20 ACTION ITEMS=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Revised - [Syed, 8/25] Update the security considerations section New - [Alex, 8/29] Provide any changes around internationalization Completed: [Ken] Complete remaining updates to the transport document (sent this week) [Sumanth] Check with Dean Willis and the OpenSPPP implementors if they have= any issues or questions to report AGENDA =3D=3D=3D=3D=3D=3D 1. General Updates related to the WG documents 2. Feedback and questions from developers, based on implementation experien= ce 3. Next Steps NOTES =3D=3D=3D=3D=3D 1. General Updates related to the WG documents + Protocol Document - [Syed] Still working on the security considerations section and will p= rovide an update today.=20 - [Alex] is going to take a look at any pending items around internation= alization=20 - Pending Items > Data validation requirements (topic for the interim F2F) > Any feedback from the OpenSPPP implementers? (see below) + Transport Document - Ken sent across an update to the transport document earlier this week =20 2. Feedback and questions from developers, based on implementation experien= ce + Dean and Jeremy represented the team working on OpenSPPP implementatio= n + They raised a few questions and suggestions around > The need for data validation > The peer offer/answer and whether this should be separate from the p= rotocol > Whether the authorization model should be left to policy, or if it s= hould be specified for reasons of interoperability etc. + Given the lack of time and to better document the points, Sumanth requ= ested Jeremy and Dean to share these thoughts on the mailing list so that w= e can discuss as a WG and come to a common understanding. 3. Next Steps + Discuss the comments from the implementation team + Hold the interim meeting next week From sumanth@cablelabs.com Thu Aug 25 08:46:06 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC37321F861A for ; Thu, 25 Aug 2011 08:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.401 X-Spam-Level: X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3KJiwUjKl+7 for ; Thu, 25 Aug 2011 08:46:06 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7151021F85C0 for ; Thu, 25 Aug 2011 08:46:06 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id p7PFlG2n026363 for ; Thu, 25 Aug 2011 09:47:19 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Thu, 25 Aug 2011 09:47:16 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 25 Aug 2011 09:47:16 -0600 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Thu, 25 Aug 2011 09:47:15 -0600 Thread-Topic: [drinks] Rough Notes and AI list from the design team call on 8/25 (and note about call on 8/18**) Thread-Index: AcxjPjZF0YITVZGzRNW619kS0RFFfQ== Message-ID: <76AC5FEF83F1E64491446437EA81A61F81908059B8@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [drinks] Rough Notes and AI list from the design team call on 8/25 (and note about call on 8/18**) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 15:46:07 -0000 Oops - I meant 8/18 (Thursday) not 8/17... ---- Folks, I am enclosing some brief notes and the AI list from the call today. FYI, w= e did hold a call on 8/18** and I did not get a chance to send the notes, s= orry. The attendees were: Ken, Syed, Sumanth; and Dean Willis who spoke on = behalf of the implementation team. The discussions were a prelude to the di= scussion on the mailing list (refer to Dean's email to the list) and the on= es we had today. Given that these discussions are expected to carry over to= the mailing list, I am not noting them separately.=20 - S IETF DRINKS DESIGN TEAM CALL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D 8/25/2011, 10:00a-11:05a (Eastern)/8:00a-9:05a (Mountain) =20 Participants =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Alex Mayrhofer - Dean Willis - Syed Ali - Ken Cartwright - Jeremy Barkan - Sumanth Channabasappa=20 ACTION ITEMS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Revised - [Syed, 8/25] Update the security considerations section New - [Alex, 8/29] Provide any changes around internationalization Completed: [Ken] Complete remaining updates to the transport document (sent this week)= [Sumanth] Check with Dean Willis and the OpenSPPP implementors if they hav= e any issues or questions to report AGENDA =3D=3D=3D=3D=3D=3D 1. General Updates related to the WG documents 2. Feedback and questions fr= om developers, based on implementation experience 3. Next Steps NOTES =3D=3D=3D=3D=3D 1. General Updates related to the WG documents + Protocol Document - [Syed] Still working on the security considerations section and will p= rovide an update today.=20 - [Alex] is going to take a look at any pending items around internation= alization=20 - Pending Items > Data validation requirements (topic for the interim F2F) > Any feedback from the OpenSPPP implementers? (see below) + Transport Document - Ken sent across an update to the transport document earlier this week =20 2. Feedback and questions from developers, based on implementation experien= ce + Dean and Jeremy represented the team working on OpenSPPP implementatio= n + They raised a few questions and suggestions around > The need for data validation > The peer offer/answer and whether this should be separate from the p= rotocol > Whether the authorization model should be left to policy, or if it s= hould be specified for reasons of interoperability etc. + Given the lack of time and to better document the points, Sumanth requ= ested Jeremy and Dean to share these thoughts on the mailing list so that w= e can discuss as a WG and come to a common understanding. 3. Next Steps + Discuss the comments from the implementation team + Hold the interim meeting next week _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks From kcartwright@tnsi.com Thu Aug 25 09:17:59 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4813421F8593 for ; Thu, 25 Aug 2011 09:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7nhtdR3irHu for ; Thu, 25 Aug 2011 09:17:58 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8FF21F851A for ; Thu, 25 Aug 2011 09:17:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAAAEJ1Vk6sEQfn/2dsb2JhbABCmCqQT4FAAQEEATo4BwUHBAIBCBEEAQEBHgkHMhQJCAEBBA4FCIdquyuFbGAEpDA X-IronPort-AV: E=Sophos;i="4.68,281,1312153200"; d="scan'208";a="142258" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 25 Aug 2011 17:19:08 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Thu, 25 Aug 2011 12:19:07 -0400 From: "Cartwright, Ken" To: Dean Willis Date: Thu, 25 Aug 2011 12:19:57 -0400 Thread-Topic: [drinks] Thoughts on "Organization" in draft-ietf-drinks-spprov-09 Thread-Index: AcxjLoO6RFwhq4MjRkeg9GuDQsKmegAEcmEA Message-ID: <754963199212404AB8E9CFCA6C3D0CDA38DDB8CDE8@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <754963199212404AB8E9CFCA6C3D0CDA38DD5F2E9E@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E5651F2.2090307@softarmor.com> In-Reply-To: <4E5651F2.2090307@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] Thoughts on "Organization" in draft-ietf-drinks-spprov-09 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 16:17:59 -0000 See comments in line. Ken -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Thursday, August 25, 2011 9:45 AM To: Cartwright, Ken Cc: drinks@ietf.org Subject: Re: [drinks] Thoughts on "Organization" in draft-ietf-drinks-sppro= v-09 On 8/24/11 8:43 AM, Cartwright, Ken wrote: > Point 1: Maybe. On the other hand it is not the purpose of the spec > to describe how to implement a protocol server. Imo, this discussion > would get into that realm. Many at the IETF feel that the purpose of an IETF protocol specification is to allow for multiple interoperable implementations of a protocol. I suspect that without making the relationships between Owner and other things clear, we won't get interoperability. KJC: Sorry, but I do not know what you mean by "making the relationships b= etween Owner and other things clear". Each object already contains the reg= istrantID of the "owner". What do you mean by "things"? > Point 2: As we've discussed the creation of organizations happens > outside the protocol. The job of setting up organization > identifiers and their associated authentication credentials and > their authorization roles is not the purpose of this protocol, not > should it be. From the Abstract: This document describes the Session Peering Provisioning Protocol used by clients to provision registries. We can't use the protocol to provision a registry without (somehow) provisioning Owner objects. As defined, the protocol doesn't manipulate Owner objects. Given this constraint, does the protocol meet the goals laid out in the Abstract? Perhaps this could be addressed in the protocol specification by declaring Owner "out of scope" and stating that some other protocol is required for manipulating Owner? KJC: Your use of the term "Owner object" is not clear to me. Are you just= talking about the Registrant (technically speaking it is the "Registrant" = that owns each object)? If that is the case then, you are correct that the= protocol does not provide the ability to create new Registrant IDs. Manag= ing registrant organizations and registrar organizations with their authent= ication credentials was not in scope for this protocol. I guess we can cer= tainly add in a statement stating that the protocol does _not_ have that fe= ature. However, it is not necessarily true that "some other protocol is re= quired for that purpose". Most registries that work at an organizational l= evel have something like an administration portal that is used to create ne= w organizations, rather than a standardized protocol. This is because (1) = allowing a protocol client to create _itself_ does not make sense, and (2) = there are contractual and legal activities involved in setting up organizat= ional relationships (that result in authorization privileges) between regis= trars and registrants. -- Dean This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From dean.willis@softarmor.com Thu Aug 25 11:43:27 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0514A21F8C18 for ; Thu, 25 Aug 2011 11:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.389 X-Spam-Level: X-Spam-Status: No, score=-103.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBGweZZMvrFw for ; Thu, 25 Aug 2011 11:43:26 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5E821F8C16 for ; Thu, 25 Aug 2011 11:43:26 -0700 (PDT) Received: by gxk19 with SMTP id 19so2354524gxk.31 for ; Thu, 25 Aug 2011 11:44:36 -0700 (PDT) Received: by 10.90.247.40 with SMTP id u40mr77082agh.171.1314297876240; Thu, 25 Aug 2011 11:44:36 -0700 (PDT) Received: from dwillis-mb1.local (cpe-66-25-15-110.tx.res.rr.com [66.25.15.110]) by mx.google.com with ESMTPS id e4sm746038anb.15.2011.08.25.11.44.34 (version=SSLv3 cipher=OTHER); Thu, 25 Aug 2011 11:44:35 -0700 (PDT) Message-ID: <4E569811.3090503@softarmor.com> Date: Thu, 25 Aug 2011 13:44:33 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "drinks@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [drinks] Policy vs. Protocol X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 18:43:27 -0000 One of the things we've done so far in DRINKS is leave a lot of implementation decisions to "local policy", in the hopes that it would reduce the detail of the specifications we're writing, while preserving the flexibility of the resulting implementation to do needful things that we haven't thought about. I think this is a misunderstanding of "local policy". Local policy is not "the part of the specification we didn't write". Rather, it is the "locally-determined settings for configurable elements of the protocol." In other words, it's how the operator tweaks the knobs of the system. The knobs, however, still have to be defined. We need to know what they are, how they work, and what they can be made to do. Then local policy can decide how they're going to be adjusted, thereby driving the behavior of the system. If we don't know what the configurable aspects of a protocol are, we can't fully implement that protocol. At best, we can implement the specified subset of the protocol, and leave it to implementations to guess at the rest. This is not, in my opinion, a recipe for a protocol in which we can expect two different teams working from the same specification to produce implementations that will correctly work with each other. Let's take an example of authentication within IMAP, the Internet Mail Access protocol. IMAP's specs do not say how an IMAP server is configured to add authorized user accounts. However, it does say where the username will be carried in a request and how authentication alternatives are negotiated and selected. And it gives us a baseline set of options that all implementations are expected to support. Whether the operator turns on those options is "local policy", but the options themselves, incorporated in the base protocol spec or an extension thereto, are "protocol". From kcartwright@tnsi.com Thu Aug 25 12:26:54 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506BF21F8BFB for ; Thu, 25 Aug 2011 12:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-lCSKprgpfz for ; Thu, 25 Aug 2011 12:26:53 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9139521F8BF8 for ; Thu, 25 Aug 2011 12:26:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAAAMGhVk6sEQfn/2dsb2JhbABDmCyQT4FAAQEBAQMBAQE3LQcXBAIBCBEEAQEfCQcnCxQJCAEBBAESCIduumyFbGAEpDA X-IronPort-AV: E=Sophos;i="4.68,282,1312153200"; d="scan'208";a="143122" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 25 Aug 2011 20:28:05 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Thu, 25 Aug 2011 15:28:05 -0400 From: "Cartwright, Ken" To: Dean Willis , "drinks@ietf.org" Date: Thu, 25 Aug 2011 15:28:54 -0400 Thread-Topic: [drinks] Policy vs. Protocol Thread-Index: AcxjVxGeUj2OLvcdQf6HkyX2b8HO/AAAlPFA Message-ID: <754963199212404AB8E9CFCA6C3D0CDA38DDB8CF82@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4E569811.3090503@softarmor.com> In-Reply-To: <4E569811.3090503@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [drinks] Policy vs. Protocol X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 19:26:54 -0000 Hi Dean, Sorry, this statement is just too vague. Can you help me understand what y= ou mean by "a lot"? Even your example is not an SPP example, but rather an= IMAP analogy. And that analogy is not accurate with respect to SPPP, if I= understand what you mean by "how authentication alternatives are negotiate= d and selected". SPPP does specify how to do authentication (Digest Authent= ication) and SSL certs. Now if you do not agree with the use of the Digest= Authentication then that is another matter. If my memory serves me, the SPPP document lists the following as matters of= policy: 1) Route Group Priority for Resolution: How/if the resolution serves will = use the "priority" value on the Route Group object when answering resolutio= n queries. 2) Data Authorization Rules: What data objects will be "gettable" and "mod= ifiable" by a given registrar/registrant. Ken -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Dean Willis Sent: Thursday, August 25, 2011 2:45 PM To: drinks@ietf.org Subject: [drinks] Policy vs. Protocol One of the things we've done so far in DRINKS is leave a lot of implementation decisions to "local policy", in the hopes that it would reduce the detail of the specifications we're writing, while preserving the flexibility of the resulting implementation to do needful things that we haven't thought about. I think this is a misunderstanding of "local policy". Local policy is not "the part of the specification we didn't write". Rather, it is the "locally-determined settings for configurable elements of the protocol." In other words, it's how the operator tweaks the knobs of the system. The knobs, however, still have to be defined. We need to know what they are, how they work, and what they can be made to do. Then local policy can decide how they're going to be adjusted, thereby driving the behavior of the system. If we don't know what the configurable aspects of a protocol are, we can't fully implement that protocol. At best, we can implement the specified subset of the protocol, and leave it to implementations to guess at the rest. This is not, in my opinion, a recipe for a protocol in which we can expect two different teams working from the same specification to produce implementations that will correctly work with each other. Let's take an example of authentication within IMAP, the Internet Mail Access protocol. IMAP's specs do not say how an IMAP server is configured to add authorized user accounts. However, it does say where the username will be carried in a request and how authentication alternatives are negotiated and selected. And it gives us a baseline set of options that all implementations are expected to support. Whether the operator turns on those options is "local policy", but the options themselves, incorporated in the base protocol spec or an extension thereto, are "protocol". _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From dean.willis@softarmor.com Thu Aug 25 12:27:26 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF5B21F8BF8 for ; Thu, 25 Aug 2011 12:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.402 X-Spam-Level: X-Spam-Status: No, score=-103.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvakE3nxgOZS for ; Thu, 25 Aug 2011 12:27:25 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEA221F8BFB for ; Thu, 25 Aug 2011 12:27:25 -0700 (PDT) Received: by yxj17 with SMTP id 17so2386516yxj.31 for ; Thu, 25 Aug 2011 12:28:39 -0700 (PDT) Received: by 10.91.215.16 with SMTP id s16mr139754agq.138.1314300519046; Thu, 25 Aug 2011 12:28:39 -0700 (PDT) Received: from dwillis-mb1.local (cpe-66-25-15-110.tx.res.rr.com [66.25.15.110]) by mx.google.com with ESMTPS id c5sm772865anh.27.2011.08.25.12.28.37 (version=SSLv3 cipher=OTHER); Thu, 25 Aug 2011 12:28:38 -0700 (PDT) Message-ID: <4E56A264.50703@softarmor.com> Date: Thu, 25 Aug 2011 14:28:36 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "Cartwright, Ken" References: <754963199212404AB8E9CFCA6C3D0CDA38DD5F2E9E@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E5651F2.2090307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8CDE8@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA38DDB8CDE8@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "drinks@ietf.org" Subject: [drinks] Long Followup to Thoughts on "Organization" in draft-ietf-drinks-spprov-09 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 19:27:26 -0000 On 8/25/11 11:19 AM, Cartwright, Ken wrote: > > KJC: Sorry, but I do not know what you mean by "making the > relationships between Owner and other things clear". Each object > already contains the registrantID of the "owner". What do you mean > by "things"? OpenSPP maps the SPPP schema to SQL. In doing so, we ended up with another table called "Organization". This is supported in or DataAccessObjects layer by another Java class, "OrganizationDAO.java" The Organizaton schema is: CREATE TABLE IF NOT EXISTS `openspp`.`Organization` ( `OrgId` INT NOT NULL AUTO_INCREMENT , `OrgName` VARCHAR(255) NOT NULL , `Cdate` DATETIME NULL , `MDate` DATETIME NULL , PRIMARY KEY (`OrgId`) , UNIQUE INDEX `UK_Organization_OrgName` (`OrgName` ASC) ) ENGINE = InnoDB; In the WSD, the protocol defines an OrgIdType as a simple unbounded string (in practice, this needs validation constraints). Registrant, as encoded in the "rant" member of "objKey" and "BasicObjType" is related to Organization. In practice, the "rant" member of objKey relates to the Organization table, in that values of "rant" in objKey and "BasicObjType" MUST appear as "OrgName" columns in rows of the Organization table. I think that "Registrant" as you use the term isa "Organization" as defined in the OpenSPP database schema. Are there other sorts of "Organization" needed? Maybe, maybe not, depending on the AAA model, and on whether an implementation needs other "owned" objects that are not owned by Registrants. More below ... > KJC: Your use of the term "Owner object" is not clear to me. Are > you just talking about the Registrant (technically speaking it is the > "Registrant" that owns each object)? Is the authoritative owner actually the "Registrant" (aka "Organization")? Or is it the "Registrar" (currently undefined in our schema) who interfaces with our database (the Registry) on behalf of the Registrant? Assume a mapping of authentication identities (Auth_ID for short, and currently undefined in our schemae). In a minimal model, each Auth-ID has a name (username) and authentication credentials (password, cert, private key, whatever). Is there a one-to-one mapping between Auth_ID and Registrant? I'd argue strongly "no". Analysis of Auth_ID per Registrant ---------------------------------- Registrant "Alice" registers some routes with registrar "Reg1" and some with "Reg2". We add an Organization/Registrant table entry with an OrgId/RantID of "Alice". If we issue a single Auth_ID for Alice, both Reg1 and Reg2 get a copy of the credentials. Either can then access or delete routes registered by Alice with their competitor. Is this acceptable Alternate: One Auth_ID per Registrar-Registrant Relationship: ------------------------------------------------------------- One alternative is to issue two Auth_ID, one for Reg1 and another for Reg2. Both have the name "Alice", but they have different credentials. So when Alice registers a route with Reg1, Reg1 uses its Auth_ID to put the route in the registry, and the route record has a RantId of "Alice". But now when Reg2 queries for all of Alice's routes (assuming we lack something else to indicate which of Alice's routes Reg2 can see or edit), Reg2 will see the route added via Reg1. Reg2 can even retract the route or alter it to point through another path more favorable to Reg2. Is this acceptable? Would it be better to consider the Registrar as the "owner" of the record? Of course, that raises other questions: Alternate: One Auth_ID per Registar-Registrant Relationship plus one per Registrant: -------------------------------------------------------------------- Alice might want to check the routes registered for her by Reg1 and Reg2. Alice now needs yet another Auth_ID. This doesn't have the same cross-visibility problems as do the Auth_IDs for Reg1 and Reg2, but it gets interesting in that there are now three different passwords per username Alice, and we don't know which record was created by whom. Alice queries her route records, but cannot by examination tell which were inserted by Reg1 and which wee inserted by Reg2. Related case: The registry operator might want to audit routes. Assume Alice calls up the registry and says "Check on what these guys are doing to me." They fire up an admin console with the intent of using SPPP to query the registry. They now either need Alice's, Reg1, or Reg2's Auth-ID for Alice. Or they need a fourth Auth_ID -- and another such for every additional registrant. It would be a lot better to have the registry operator only need one Auth-ID with administrative rights, no? The same probably applies to the registrars. What if we added a new Auth_ID table? ------------------------------------- We could add Yet Another Table (or object, depending on your worldview). Call it for now the Auth_ID table. Minimally each Auth_ID has columns for name, credential, cDate, mDate, and the other usual things (expiry?). How do we relate Auth_ID to other things in our database? Otherwise said, what can a given Auth_ID read or write in the database? A simple approach might be to build yet another table that relates Auth_ID to Registrant (or Organization, the in the OpenSPP schema). The first column might be the Auth_ID, the second the RantId (or OrgId), and the third the capability flag , like "read", "write", or "both". This makes it easy to determine which records a requester can access: We use the Auth-ID to authenticate, then select records from the database which 1) match the request parameters, and 2) have an OrgId for which the Auth_ID has the appropriate access rights. BUT: Remember the use case where registrant Alice sends some route records through registrar Reg1 and some through Reg2 and we don't want Reg1 messing with Reg2's records? We don't have enough information in the database to know which records came from Reg1 and which came from Reg2. And our auth model gave both Reg1 and Reg2 access to all of Alice's records. What if we Add the Registrar's Name to Each Record? --------------------------------------------------- We could add a RegistrarId to each BasicObjType and to objKey. This gives us the information to make decisions about whether Reg1 can see all of Alice's routes, or just those routes that Alice published through Reg1. To do this, we need a place to store RegistrarIDs. We could add yet another table. And another for AdministratorIDs, and every other sort of owner-ID we may come up with. Or we could simply say that both Registrant and Registrar are Organizations. Registry operators themselves (and their admin support) are also probably Organizations. This lets us use the Organization tables (as defined in OpenSPP) to store them all. So, RantId isa OrgId, RegisId isa OrgId, and so on. We Still Need to Deal With Roles and Rights ------------------------------------------- With the above changes, we can by examination tell who the Registrant and Registrar are for each object. We can also identify the actor making a request. What we don't know is whether or not the actor making a request should be allowed to do it. This is a complex topic, and since the protocol doesn't care (it just needs to know "who" and reply "yes/no" in response), it really CAN be left to the implementation. For the sake of discussion, I hereby propose an example solution that might work for a reference implementation such as OpenSPP. First, we need to add an "administrator" flag to the Auth-ID table. Organizations flagged with this are by definition administrators. Second, we need a way to authorize registrars to act on behalf of registrants. The easiest approach is to add a new table "rant-regis" relating rant to regis; a row containing a binding of rant and regis says that that the indicated registrar can act on behalf of the registrant except when in conflict with another registrar. 1) If the Auth_ID of a request is an Administrator, the request is authorized. 2) If the Auth_ID of a request affecting an existing object is the same as the "rant" of that object the request is authorized. 3) If the Auth_ID of a request affecting an existing object is the same as the "regis" of that object the request is authorized. 4) If the Auth_ID of a request creating a new object is an Administrator, the request is authorized. 5) If the Auth_ID of a request creating a new object is the same as the rant of the new object, the request is authorized. 6) If the Auth_ID of a request creating a new object is the same as the regis of the new object, AND the regis is an authorized registrar for the registrant specified by the rant in the request (see the rant-regis table), the request is authorized. Proposed PROTOCOL solution: 1) Add the concept of an Authenticated Identity (what I above called an Auth_ID) to the protocol. How Auth_IDs are added to the system is outside the scope of the protocol. How they are USED, however, is within the scope. What we know is that there is an Auth_ID presented for each transaction, and this this Auth_ID is used to a) identify the actor making the request, b) authenticate that the request is validly from that actor, and c) decide, along with other information, whether or not that actor is authorized to execute the given request. 2) Understand that roles such as Registrant, Registrar, Administrator, are all Organizations, each of which has a a unique name within the schema (of OrgIdType). 3) Extend BasicObjType to track the Registrar as well as the Registrant of each object: From dean.willis@softarmor.com Thu Aug 25 12:43:26 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDDD421F8C11 for ; Thu, 25 Aug 2011 12:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.413 X-Spam-Level: X-Spam-Status: No, score=-103.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njpLv2Y7nFz3 for ; Thu, 25 Aug 2011 12:43:26 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C034221F8B18 for ; Thu, 25 Aug 2011 12:43:25 -0700 (PDT) Received: by ywe9 with SMTP id 9so2392488ywe.31 for ; Thu, 25 Aug 2011 12:44:39 -0700 (PDT) Received: by 10.91.144.7 with SMTP id w7mr190166agn.48.1314301479381; Thu, 25 Aug 2011 12:44:39 -0700 (PDT) Received: from dwillis-mb1.local (cpe-66-25-15-110.tx.res.rr.com [66.25.15.110]) by mx.google.com with ESMTPS id h15sm786828ank.13.2011.08.25.12.44.38 (version=SSLv3 cipher=OTHER); Thu, 25 Aug 2011 12:44:38 -0700 (PDT) Message-ID: <4E56A625.4040104@softarmor.com> Date: Thu, 25 Aug 2011 14:44:37 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "Cartwright, Ken" References: <4E569811.3090503@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8CF82@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA38DDB8CF82@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "drinks@ietf.org" Subject: Re: [drinks] Policy vs. Protocol X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 19:43:27 -0000 On 8/25/11 2:28 PM, Cartwright, Ken wrote: > Hi Dean, > > Sorry, this statement is just too vague. Can you help me understand > what you mean by "a lot"? Even your example is not an SPP example, > but rather an IMAP analogy. And that analogy is not accurate with > respect to SPPP, if I understand what you mean by "how > authentication alternatives are negotiated and selected". SPPP does > specify how to do authentication (Digest Authentication) and SSL > certs. Now if you do not agree with the use of the Digest > Authentication then that is another matter. Ok, you've done authentication in SPPP. What did you get out of it? How do you use that information? based on this information, how do you decide which records are visible? In IMAP, the authentication produces an authenticated username, which can be string-compared to the names of individual IMAP accounts. If the authenticated user name == an account user name, the access is authorized (possibly subject to other restraints in shared folders and where quotes are in use, but those are different error codes). > > If my memory serves me, the SPPP document lists the following as > matters of policy: ... > 2) Data Authorization Rules: What data objects will be "gettable" > and "modifiable" by a given registrar/registrant. How does the user name returned by the digest authentication relate to the registrar or registrant name as specified in the schema especially given that the current schema says nothing about registrar names? That's not a policy question. It's a protocol binding. -- Dean From kcartwright@tnsi.com Thu Aug 25 13:05:13 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3669321F8C83 for ; Thu, 25 Aug 2011 13:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDl+xRh64sA0 for ; Thu, 25 Aug 2011 13:05:12 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id A457C21F8C7D for ; Thu, 25 Aug 2011 13:05:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAAAO+pVk6sEQfn/2dsb2JhbAA5AQmYLZBPgUABAQQBOjgHDAQCAQgRBAEBGQYJBzIUCQgBAQQOAwIIE4dXunODKAEfgiRgBKQwIA X-IronPort-AV: E=Sophos;i="4.68,282,1312153200"; d="scan'208";a="143284" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 25 Aug 2011 21:06:22 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Thu, 25 Aug 2011 16:06:22 -0400 From: "Cartwright, Ken" To: Dean Willis Date: Thu, 25 Aug 2011 16:07:11 -0400 Thread-Topic: Long Followup to Thoughts on "Organization" in draft-ietf-drinks-spprov-09 Thread-Index: AcxjXTPTSHx0Rf6nSfKDNitQ/k64ngAAEm9w Message-ID: <754963199212404AB8E9CFCA6C3D0CDA38DDB8CFC5@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <754963199212404AB8E9CFCA6C3D0CDA38DD5F2E9E@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E5651F2.2090307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8CDE8@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E56A264.50703@softarmor.com> In-Reply-To: <4E56A264.50703@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] Long Followup to Thoughts on "Organization" in draft-ietf-drinks-spprov-09 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 20:05:13 -0000 Hi Dean, 1) The spec does not specify how to implement a DB or code that manages cre= dentials or roles, nor should it. There are multiple internal design appro= aches/decisions to be made. 2) The internal design of the OpenSPP Organization table you have below loo= ks just fine to me, as a bare bones implementation (which I think is what y= ou are going for). I guess it holds the list of the registrants that exist= in the system. And since I do not see a "hash" or "passkey" column in tha= t table, there must be another table that holds the "registrars" and their = IDs and authentication credential in some form, which is what would be used= when evaluating/handling the Digest Authentication sequence required by th= e spec. 3) There is no password or cert associated with a "registrant". A registra= nt never authenticates itself to the SPPP server. It is the "registrar" th= at authenticates itself to the SPPP server. 3) As discussed on today's call, we did have the "rarId" (registrar ID) in = the protocol. It was an attribute of each object. However, as the final c= hange to the protocol we removed it at the request of a couple of the work = group participants because they felt it got in the way of the local policie= s that drive their local implementations of authentication and authorizatio= n. We all agreed to do this because we saw that it is not _strictly_ neces= sary to have the "rarId" data element exist within the context of the SPPP = messages going between the client and the server. But it _is_ certainly ne= cessary within the internal server side implementation DB to keep the ID of= the registrar that created each object. Ken -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Thursday, August 25, 2011 3:29 PM To: Cartwright, Ken Cc: drinks@ietf.org Subject: Long Followup to Thoughts on "Organization" in draft-ietf-drinks-s= pprov-09 On 8/25/11 11:19 AM, Cartwright, Ken wrote: > > KJC: Sorry, but I do not know what you mean by "making the > relationships between Owner and other things clear". Each object > already contains the registrantID of the "owner". What do you mean > by "things"? OpenSPP maps the SPPP schema to SQL. In doing so, we ended up with another table called "Organization". This is supported in or DataAccessObjects layer by another Java class, "OrganizationDAO.java" The Organizaton schema is: CREATE TABLE IF NOT EXISTS `openspp`.`Organization` ( `OrgId` INT NOT NULL AUTO_INCREMENT , `OrgName` VARCHAR(255) NOT NULL , `Cdate` DATETIME NULL , `MDate` DATETIME NULL , PRIMARY KEY (`OrgId`) , UNIQUE INDEX `UK_Organization_OrgName` (`OrgName` ASC) ) ENGINE =3D InnoDB; In the WSD, the protocol defines an OrgIdType as a simple unbounded string (in practice, this needs validation constraints). Registrant, as encoded in the "rant" member of "objKey" and "BasicObjType" is related to Organization. In practice, the "rant" member of objKey relates to the Organization table, in that values of "rant" in objKey and "BasicObjType" MUST appear as "OrgName" columns in rows of the Organization table. I think that "Registrant" as you use the term isa "Organization" as defined in the OpenSPP database schema. Are there other sorts of "Organization" needed? Maybe, maybe not, depending on the AAA model, and on whether an implementation needs other "owned" objects that are not owned by Registrants. More below ... > KJC: Your use of the term "Owner object" is not clear to me. Are > you just talking about the Registrant (technically speaking it is the > "Registrant" that owns each object)? Is the authoritative owner actually the "Registrant" (aka "Organization")? Or is it the "Registrar" (currently undefined in our schema) who interfaces with our database (the Registry) on behalf of the Registrant? Assume a mapping of authentication identities (Auth_ID for short, and currently undefined in our schemae). In a minimal model, each Auth-ID has a name (username) and authentication credentials (password, cert, private key, whatever). Is there a one-to-one mapping between Auth_ID and Registrant? I'd argue strongly "no". Analysis of Auth_ID per Registrant ---------------------------------- Registrant "Alice" registers some routes with registrar "Reg1" and some with "Reg2". We add an Organization/Registrant table entry with an OrgId/RantID of "Alice". If we issue a single Auth_ID for Alice, both Reg1 and Reg2 get a copy of the credentials. Either can then access or delete routes registered by Alice with their competitor. Is this acceptable Alternate: One Auth_ID per Registrar-Registrant Relationship: ------------------------------------------------------------- One alternative is to issue two Auth_ID, one for Reg1 and another for Reg2. Both have the name "Alice", but they have different credentials. So when Alice registers a route with Reg1, Reg1 uses its Auth_ID to put the route in the registry, and the route record has a RantId of "Alice". But now when Reg2 queries for all of Alice's routes (assuming we lack something else to indicate which of Alice's routes Reg2 can see or edit), Reg2 will see the route added via Reg1. Reg2 can even retract the route or alter it to point through another path more favorable to Reg2. Is this acceptable? Would it be better to consider the Registrar as the "owner" of the record? Of course, that raises other questions: Alternate: One Auth_ID per Registar-Registrant Relationship plus one per Registrant: -------------------------------------------------------------------- Alice might want to check the routes registered for her by Reg1 and Reg2. Alice now needs yet another Auth_ID. This doesn't have the same cross-visibility problems as do the Auth_IDs for Reg1 and Reg2, but it gets interesting in that there are now three different passwords per username Alice, and we don't know which record was created by whom. Alice queries her route records, but cannot by examination tell which were inserted by Reg1 and which wee inserted by Reg2. Related case: The registry operator might want to audit routes. Assume Alice calls up the registry and says "Check on what these guys are doing to me." They fire up an admin console with the intent of using SPPP to query the registry. They now either need Alice's, Reg1, or Reg2's Auth-ID for Alice. Or they need a fourth Auth_ID -- and another such for every additional registrant. It would be a lot better to have the registry operator only need one Auth-ID with administrative rights, no? The same probably applies to the registrars. What if we added a new Auth_ID table? ------------------------------------- We could add Yet Another Table (or object, depending on your worldview). Call it for now the Auth_ID table. Minimally each Auth_ID has columns for name, credential, cDate, mDate, and the other usual things (expiry?). How do we relate Auth_ID to other things in our database? Otherwise said, what can a given Auth_ID read or write in the database? A simple approach might be to build yet another table that relates Auth_ID to Registrant (or Organization, the in the OpenSPP schema). The first column might be the Auth_ID, the second the RantId (or OrgId), and the third the capability flag , like "read", "write", or "both". This makes it easy to determine which records a requester can access: We use the Auth-ID to authenticate, then select records from the database which 1) match the request parameters, and 2) have an OrgId for which the Auth_ID has the appropriate access rights. BUT: Remember the use case where registrant Alice sends some route records through registrar Reg1 and some through Reg2 and we don't want Reg1 messing with Reg2's records? We don't have enough information in the database to know which records came from Reg1 and which came from Reg2. And our auth model gave both Reg1 and Reg2 access to all of Alice's records. What if we Add the Registrar's Name to Each Record? --------------------------------------------------- We could add a RegistrarId to each BasicObjType and to objKey. This gives us the information to make decisions about whether Reg1 can see all of Alice's routes, or just those routes that Alice published through Reg1. To do this, we need a place to store RegistrarIDs. We could add yet another table. And another for AdministratorIDs, and every other sort of owner-ID we may come up with. Or we could simply say that both Registrant and Registrar are Organizations. Registry operators themselves (and their admin support) are also probably Organizations. This lets us use the Organization tables (as defined in OpenSPP) to store them all. So, RantId isa OrgId, RegisId isa OrgId, and so on. We Still Need to Deal With Roles and Rights ------------------------------------------- With the above changes, we can by examination tell who the Registrant and Registrar are for each object. We can also identify the actor making a request. What we don't know is whether or not the actor making a request should be allowed to do it. This is a complex topic, and since the protocol doesn't care (it just needs to know "who" and reply "yes/no" in response), it really CAN be left to the implementation. For the sake of discussion, I hereby propose an example solution that might work for a reference implementation such as OpenSPP. First, we need to add an "administrator" flag to the Auth-ID table. Organizations flagged with this are by definition administrators. Second, we need a way to authorize registrars to act on behalf of registrants. The easiest approach is to add a new table "rant-regis" relating rant to regis; a row containing a binding of rant and regis says that that the indicated registrar can act on behalf of the registrant except when in conflict with another registrar. 1) If the Auth_ID of a request is an Administrator, the request is authorized. 2) If the Auth_ID of a request affecting an existing object is the same as the "rant" of that object the request is authorized. 3) If the Auth_ID of a request affecting an existing object is the same as the "regis" of that object the request is authorized. 4) If the Auth_ID of a request creating a new object is an Administrator, the request is authorized. 5) If the Auth_ID of a request creating a new object is the same as the rant of the new object, the request is authorized. 6) If the Auth_ID of a request creating a new object is the same as the regis of the new object, AND the regis is an authorized registrar for the registrant specified by the rant in the request (see the rant-regis table), the request is authorized. Proposed PROTOCOL solution: 1) Add the concept of an Authenticated Identity (what I above called an Auth_ID) to the protocol. How Auth_IDs are added to the system is outside the scope of the protocol. How they are USED, however, is within the scope. What we know is that there is an Auth_ID presented for each transaction, and this this Auth_ID is used to a) identify the actor making the request, b) authenticate that the request is validly from that actor, and c) decide, along with other information, whether or not that actor is authorized to execute the given request. 2) Understand that roles such as Registrant, Registrar, Administrator, are all Organizations, each of which has a a unique name within the schema (of OrgIdType). 3) Extend BasicObjType to track the Registrar as well as the Registrant of each object: This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From kcartwright@tnsi.com Thu Aug 25 14:15:33 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD7E21F889A for ; Thu, 25 Aug 2011 14:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIsSggOtYjuU for ; Thu, 25 Aug 2011 14:15:33 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB6221F85A3 for ; Thu, 25 Aug 2011 14:15:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIAAE26Vk6sEQfn/2dsb2JhbABDmDGQT4FAAQEEATo/BQcEAgEIEQQBAQEVAQgJBzIUCQgBAQQOBQiHarplgzsIDIIdYASkMA X-IronPort-AV: E=Sophos;i="4.68,282,1312153200"; d="scan'208";a="143557" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 25 Aug 2011 22:16:44 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Thu, 25 Aug 2011 17:16:44 -0400 From: "Cartwright, Ken" To: Dean Willis Date: Thu, 25 Aug 2011 17:17:33 -0400 Thread-Topic: [drinks] Policy vs. Protocol Thread-Index: AcxjX29AQI2zrh+9TdKigN94Hg1jggAA/64w Message-ID: <754963199212404AB8E9CFCA6C3D0CDA38DDB8D059@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4E569811.3090503@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8CF82@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E56A625.4040104@softarmor.com> In-Reply-To: <4E56A625.4040104@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] Policy vs. Protocol X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 21:15:34 -0000 Answers in-line (KJC). Ken -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Thursday, August 25, 2011 3:45 PM To: Cartwright, Ken Cc: drinks@ietf.org Subject: Re: [drinks] Policy vs. Protocol On 8/25/11 2:28 PM, Cartwright, Ken wrote: > Hi Dean, > > Sorry, this statement is just too vague. Can you help me understand > what you mean by "a lot"? Even your example is not an SPP example, > but rather an IMAP analogy. And that analogy is not accurate with > respect to SPPP, if I understand what you mean by "how > authentication alternatives are negotiated and selected". SPPP does > specify how to do authentication (Digest Authentication) and SSL > certs. Now if you do not agree with the use of the Digest > Authentication then that is another matter. Ok, you've done authentication in SPPP. What did you get out of it? How do you use that information? based on this information, how do you decide which records are visible? In IMAP, the authentication produces an authenticated username, which can be string-compared to the names of individual IMAP accounts. If the authenticated user name =3D=3D an account user name, the access is authorized (possibly subject to other restraints in shared folders and where quotes are in use, but those are different error codes). KJC: It's not clear to me but you seem to be asking how to use Digest Auth= entication to implement authentication. I do not think that something we s= hould be putting in the spec. > > If my memory serves me, the SPPP document lists the following as > matters of policy: ... > 2) Data Authorization Rules: What data objects will be "gettable" > and "modifiable" by a given registrar/registrant. How does the user name returned by the digest authentication relate to the registrar or registrant name as specified in the schema especially given that the current schema says nothing about registrar names? That's not a policy question. It's a protocol binding. KJC: There is no such "binding" that exists because the registrant does no= t authenticate itself in SPPP. There is no construct in the protocol to do= such a thing because there has not been a requirement for it. It is the r= egistrar/SPPPClient that authenticates itself using Digest Authentication. -- Dean This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From syed.ali@neustar.biz Thu Aug 25 21:02:24 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8086221F8AB8 for ; Thu, 25 Aug 2011 21:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiFvAAZM--9A for ; Thu, 25 Aug 2011 21:02:23 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 7C93721F8AAF for ; Thu, 25 Aug 2011 21:02:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1314331415; x=1629688900; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=1GcW08aZsgCO2gKoHAYUZhnGNUsB18jYeMDsDaODDrA=; b=SYQjdl4HQ97ZOpp5pLheYs8lJjoZduac3RfBwxSlmln9hLp9uA0KDJ0WvOFIPo 3FrbX6WV0xfypT3tA81DWzeg== Received: from ([10.31.13.229]) by chihiron2.nc.neustar.com with ESMTP with TLS id 5202415.40603573; Fri, 26 Aug 2011 00:03:34 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Fri, 26 Aug 2011 00:03:31 -0400 From: "Ali, Syed Wasim" To: "drinks@ietf.org" Date: Fri, 26 Aug 2011 00:03:30 -0400 Thread-Topic: security considerations... Thread-Index: AcxjpR4NNZ0J3BzWQV6LnHhowBEaxQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: BnmH5CGXgVzC7D9EaHPbng== Content-Type: multipart/alternative; boundary="_000_CA7C935214639syedalineustarbiz_" MIME-Version: 1.0 Subject: [drinks] security considerations... X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 04:02:24 -0000 --_000_CA7C935214639syedalineustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am proposing addition of the following to the security considerations sec= tion. Thoughts? >>>>> For high visibility implementation, there may be additional concerns regard= ing repudiation issues and SPPP implementations may need to provide proof t= hat the message did not change since leaving the sender and to further vali= date the sender of SPPP message. Therefore, the SPPP implementations SHOULD= provide support for XML Signature standard to manage this concern. It is not uncommon for the logging systems to document on-the-wire messages= for various purposes, such as, debug, audit, and tracking. At the minimum,= the various support and administration staff will have access to these log= s. Also, if an unprivileged user gains access to the SPPP deployments and/o= r support systems, it will have access to the information that is potential= ly deemed confidential. To manage information disclosure concerns beyond th= e transport level, the SPPP implementations SHOULD support XML Encryption s= tandard to facilitate information hiding at the message level. Anti-replay protection ensures that a given SPPP object is not played back = at a later time and affect the integrity of the system. SPPP protocol provi= des at least two mechanisms to aid the implementers in this regard: client = transaction identifier and embedded create timestamps for the SPPP objects.= The client transaction identifier allows the sender to correlate the respo= nse with the request and verify that the transaction was returned from the = intended SPPP implementation. The timestamps in the modify SPPP objects tha= t reflect the time it was created MUST reflect the current time and the SPP= P implementations SHOULD test the time values to make sure that they are no= t replayed inadvertently, or with a malicious intent. <<<<< Thanks, -Syed -Syed --_000_CA7C935214639syedalineustarbiz_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I am propo= sing addition of the following to the security considerations section. = ;
<= br>
Thoughts?

>>>>>
For high visibility implementation, there may be additi= onal concerns regarding repudiation issues and SPPP implementations may nee= d to provide proof that the message did not change since leaving the sender= and to further validate the sender of SPPP message. Therefore, the SPPP im= plementations SHOULD provide support for XML Signature standard to manage t= his concern.

It is not uncommon for the logging systems to document on-the-w= ire messages for various purposes, such as, debug, audit, and tracking. At = the minimum, the various support and administration staff will have access = to these logs. Also, if an unprivileged user gains access to the SPPP deplo= yments and/or support systems, it will have access to the information that = is potentially deemed confidential. To manage information disclosure concer= ns beyond the transport level, the SPPP implementations SHOULD support XML = Encryption standard to facilitate information hiding at the message level.<= /div>
A= nti-replay protection ensures that a given SPPP object is not played back a= t a later time and affect the integrity of the system. SPPP protocol provid= es at least two mechanisms to aid the implementers in this regard: client t= ransaction identifier and embedded create timestamps for the SPPP objects. = The client transaction identifier allows the sender to correlate the respon= se with the request and verify that the transaction was returned from the i= ntended SPPP implementation. The timestamps in the modify SPPP objects that= reflect the time it was created MUST reflect the current time and the SPPP= implementations SHOULD test the time values to make sure that they are not= replayed inadvertently, or with a malicious intent.
<<<<&l= t;
=

-Syed

-Syed
--_000_CA7C935214639syedalineustarbiz_-- From dean.willis@softarmor.com Thu Aug 25 21:23:07 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9E521F8AA9 for ; Thu, 25 Aug 2011 21:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.424 X-Spam-Level: X-Spam-Status: No, score=-103.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwOPfVPM6XK0 for ; Thu, 25 Aug 2011 21:23:07 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2443721F8A7E for ; Thu, 25 Aug 2011 21:23:07 -0700 (PDT) Received: by gwb20 with SMTP id 20so2831995gwb.31 for ; Thu, 25 Aug 2011 21:24:22 -0700 (PDT) Received: by 10.236.72.169 with SMTP id t29mr3409495yhd.110.1314332662072; Thu, 25 Aug 2011 21:24:22 -0700 (PDT) Received: from dwillis-mb1.local (cpe-66-25-15-110.tx.res.rr.com [66.25.15.110]) by mx.google.com with ESMTPS id s62sm1680485yhn.47.2011.08.25.21.24.20 (version=SSLv3 cipher=OTHER); Thu, 25 Aug 2011 21:24:21 -0700 (PDT) Message-ID: <4E571FF3.1070308@softarmor.com> Date: Thu, 25 Aug 2011 23:24:19 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "Cartwright, Ken" References: <754963199212404AB8E9CFCA6C3D0CDA38DD5F2E9E@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E5651F2.2090307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8CDE8@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E56A264.50703@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8CFC5@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA38DDB8CFC5@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "drinks@ietf.org" Subject: Re: [drinks] Long Followup to Thoughts on "Organization" in draft-ietf-drinks-spprov-09 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 04:23:07 -0000 On 8/25/11 3:07 PM, Cartwright, Ken wrote: > Hi Dean, > > 1) The spec does not specify how to implement a DB or code that > manages credentials or roles, nor should it. There are multiple > internal design approaches/decisions to be made. The spec needs to define the actors within the protocol. For example, registrars are different actors than registrants. And it needs to talk about the range of options for each. > 2) The internal design of the OpenSPP Organization table you have > below looks just fine to me, as a bare bones implementation (which I > think is what you are going for). I guess it holds the list of the > registrants that exist in the system. And since I do not see a > "hash" or "passkey" column in that table, there must be another table > that holds the "registrars" and their IDs and authentication > credential in some form, which is what would be used when > evaluating/handling the Digest Authentication sequence required by > the spec. Gee, until today it hadn't been apparent that the database needed to hold registrars. It wasn't in the spec as far as the developers could tell. It's not in the schema, and is mentioned only in the protocol docs (as far as I can tell) as something that's outside the scope of the protocol and left up to "policy". > 3) There is no password or cert associated with a "registrant". A > registrant never authenticates itself to the SPPP server. It is the > "registrar" that authenticates itself to the SPPP server. So there's no mechanism for registrants to access the data in the registry and audit it? Can a registrant have relationships with multiple registrars (many-many), or does the protocol lock that down to many-one? Don't registrants need to access data in the database so they can offer and accept routing information to/from each other? > 3) As discussed on today's call, we did have the "rarId" (registrar > ID) in the protocol. It was an attribute of each object. However, > as the final change to the protocol we removed it at the request of a > couple of the work group participants because they felt it got in the > way of the local policies that drive their local implementations of > authentication and authorization. We all agreed to do this because > we saw that it is not _strictly_ necessary to have the "rarId" data > element exist within the context of the SPPP messages going between > the client and the server. But it _is_ certainly necessary within > the internal server side implementation DB to keep the ID of the > registrar that created each object. If an audit query using SPPP needs to be able to tell us which registrar added or updated a given object, then we need rarId. If we explicitly wish to preclude this function (which seems intuitively obvious and needful to somebody like me with an ops background) then we probably need to state explicitly that we've left it out of the protocol, and give reasons why. Otherwise the ops area people (who are admittedly less activist than in Randy Bush's IESG-days) are going to give us grief. -- Dean From dean.willis@softarmor.com Thu Aug 25 21:37:39 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2646821F8785 for ; Thu, 25 Aug 2011 21:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.133 X-Spam-Level: X-Spam-Status: No, score=-103.133 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UR4DLyD0WWtl for ; Thu, 25 Aug 2011 21:37:38 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 34E7E21F8A64 for ; Thu, 25 Aug 2011 21:37:38 -0700 (PDT) Received: by ywe9 with SMTP id 9so2823918ywe.31 for ; Thu, 25 Aug 2011 21:38:53 -0700 (PDT) Received: by 10.236.161.167 with SMTP id w27mr3909208yhk.1.1314333533151; Thu, 25 Aug 2011 21:38:53 -0700 (PDT) Received: from dwillis-mb1.local (cpe-66-25-15-110.tx.res.rr.com [66.25.15.110]) by mx.google.com with ESMTPS id o2sm1687165yhl.71.2011.08.25.21.38.51 (version=SSLv3 cipher=OTHER); Thu, 25 Aug 2011 21:38:52 -0700 (PDT) Message-ID: <4E57235B.3030509@softarmor.com> Date: Thu, 25 Aug 2011 23:38:51 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "Cartwright, Ken" References: <4E569811.3090503@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8CF82@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E56A625.4040104@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8D059@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA38DDB8D059@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "drinks@ietf.org" Subject: Re: [drinks] Policy vs. Protocol X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 04:37:39 -0000 On 8/25/11 4:17 PM, Cartwright, Ken wrote: > >> 2) Data Authorization Rules: What data objects will be "gettable" >> and "modifiable" by a given registrar/registrant. > > How does the user name returned by the digest authentication relate > to the registrar or registrant name as specified in the schema > especially given that the current schema says nothing about registrar > names? > > That's not a policy question. It's a protocol binding. > > KJC: There is no such "binding" that exists because the registrant > does not authenticate itself in SPPP. There is no construct in the > protocol to do such a thing because there has not been a requirement > for it. It is the registrar/SPPPClient that authenticates itself > using Digest Authentication. Okay, let's rephrase the question: How does the user name returned by the digest authentication relate to the registrar name as specified in the XSD schema? Is it a one-to-one mapping? Is it a direct mapping?Do we assume that they are textually the same? If so, what rules for string-comparison are used to match one against the other? I know this sounds like nit-picky crap. But it's the kind of stuff that IETF protocols often leave out (the first time) and that developers then get wrong, meaning "client A will not work with server B which will not work with provisioning system C" because A, B, and C filled in the ambiguous guesswork differently. The goal in spec-writing is to eliminate ambiguity, otherwise we're describing an architecture, not defining a protocol. There's nothing wrong with describing an architecture, of course. But we can't say to engineer A "Build me a plug with three wires for 220VAC" and to engineer B "Build me a socket with three wires for 220VAC" and hope to get a plug and a socket that work together. The history of the world's first known published engineering standard is worth reading: http://en.wikipedia.org/wiki/British_Standard_Whitworth -- Dean From dean.willis@softarmor.com Thu Aug 25 21:52:37 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8BC21F8AFB for ; Thu, 25 Aug 2011 21:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.426 X-Spam-Level: X-Spam-Status: No, score=-103.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUyIWERLmxbg for ; Thu, 25 Aug 2011 21:52:36 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5E98921F8ABC for ; Thu, 25 Aug 2011 21:52:36 -0700 (PDT) Received: by ywe9 with SMTP id 9so2834937ywe.31 for ; Thu, 25 Aug 2011 21:53:51 -0700 (PDT) Received: by 10.236.187.70 with SMTP id x46mr3707014yhm.71.1314334431223; Thu, 25 Aug 2011 21:53:51 -0700 (PDT) Received: from dwillis-mb1.local (cpe-66-25-15-110.tx.res.rr.com [66.25.15.110]) by mx.google.com with ESMTPS id e8sm716680yhm.82.2011.08.25.21.53.49 (version=SSLv3 cipher=OTHER); Thu, 25 Aug 2011 21:53:50 -0700 (PDT) Message-ID: <4E5726DD.4090704@softarmor.com> Date: Thu, 25 Aug 2011 23:53:49 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "Ali, Syed Wasim" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "drinks@ietf.org" Subject: Re: [drinks] security considerations... X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 04:52:37 -0000 On 8/25/11 11:03 PM, Ali, Syed Wasim wrote: > > Hi, > > I am proposing addition of the following to the security considerations > section. > > Thoughts? > > >>>>> > For high visibility implementation, there may be additional concerns > regarding repudiation issues and SPPP implementations may need to > provide proof that the message did not change since leaving the sender > and to further validate the sender of SPPP message. Therefore, the SPPP > implementations SHOULD provide support for XML Signature standard to > manage this concern. This further restricts protocol bindings to be XML-based instead of, for example, RESTful. Given that we're already deeply tied to XML at the "architecture" document that we're calling a protocol document (rather than in a transport binding, where I would personally have preferred to map to XML) I suppose this doesn't matter. But it is sort of running salt into the wound. Also needs a reference to the XML Signature standard. And most likely, to use XML Signature in an interoperable way, we're going to need to talk a lot more about what is being signed, what it is being signed with, and what the assumptions about key management are. > It is not uncommon for the logging systems to document on-the-wire > messages for various purposes, such as, debug, audit, and tracking. At > the minimum, the various support and administration staff will have > access to these logs. Also, if an unprivileged user gains access to the > SPPP deployments and/or support systems, it will have access to the > information that is potentially deemed confidential. To manage > information disclosure concerns beyond the transport level, the SPPP > implementations SHOULD support XML Encryption standard to facilitate > information hiding at the message level. As above WRT XML-centric design. Also needs a reference to XML Encryption standard. And most likely, to use XML Encryption in an interoperable way, we're going to need to talk a lot more about what is being encrypted, what it is being encrypted with, and what the assumptions about key management are. > Anti-replay protection ensures that a given SPPP object is not played > back at a later time and affect the integrity of the system. SPPP > protocol provides at least two mechanisms to aid the implementers in > this regard: client transaction identifier and embedded create Rather than "create" (verb form), you probably want "creation" (adjective form) as it modifies the following "timestamps" noun. That or I'm reading the sentence wrongly. > timestamps for the SPPP objects. The client transaction identifier > allows the sender to correlate the response with the request and verify > that the transaction was returned from the intended SPPP implementation. > The timestamps in the modify SPPP objects that reflect the time it was above sentence does not parse -- "in the modify"? Did you want "modified"? How does mDate play against cDate here? > created MUST reflect the current time and the SPPP implementations > SHOULD test the time values to make sure that they are not replayed > inadvertently, or with a malicious intent. Many SPPP transactions don't carry time stamps and as far as I know none have "expiry" periods. It appears that we therefore don't have the data needed for antireplay. We make can use mTime to let a client detect if someone has changed an object. Wouldn't eTags be a better solution for detecting changes? This also raises the question of absolute time-synchronization between server and client that has been problematic in some protocols. If we require time-synch, we need to say so, describe the parameters thereof (like how much drift is OK), and talk about what can happen if it gets out-of-synch. -- Dean From kcartwright@tnsi.com Fri Aug 26 06:27:31 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60FF521F8B78 for ; Fri, 26 Aug 2011 06:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CurQD5DT9Qa3 for ; Fri, 26 Aug 2011 06:27:30 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 46C1621F8B76 for ; Fri, 26 Aug 2011 06:27:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMAAOaeV06sEQfn/2dsb2JhbABCmDuQVIFAAQEEATo4BwUHBAIBCBEEAQEBGAYJBzIUCQgBAQQOBQiHarpOg0iCJGAEpDY X-IronPort-AV: E=Sophos;i="4.68,285,1312153200"; d="scan'208";a="145271" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 26 Aug 2011 14:28:44 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Fri, 26 Aug 2011 09:28:44 -0400 From: "Cartwright, Ken" To: Dean Willis Date: Fri, 26 Aug 2011 09:29:31 -0400 Thread-Topic: Long Followup to Thoughts on "Organization" in draft-ietf-drinks-spprov-09 Thread-Index: AcxjqAmPRL97+S4eTZO0s0pAFdxsPgASzIUw Message-ID: <754963199212404AB8E9CFCA6C3D0CDA38DDB8D170@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <754963199212404AB8E9CFCA6C3D0CDA38DD5F2E9E@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E5651F2.2090307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8CDE8@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E56A264.50703@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8CFC5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E571FF3.1070308@softarmor.com> In-Reply-To: <4E571FF3.1070308@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] Long Followup to Thoughts on "Organization" in draft-ietf-drinks-spprov-09 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 13:27:31 -0000 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Friday, August 26, 2011 12:24 AM To: Cartwright, Ken Cc: drinks@ietf.org Subject: Re: Long Followup to Thoughts on "Organization" in draft-ietf-drin= ks-spprov-09 On 8/25/11 3:07 PM, Cartwright, Ken wrote: > Hi Dean, > > 1) The spec does not specify how to implement a DB or code that > manages credentials or roles, nor should it. There are multiple > internal design approaches/decisions to be made. The spec needs to define the actors within the protocol. For example, registrars are different actors than registrants. And it needs to talk about the range of options for each. KJC: It does define the actors, that's why you see the definition of regis= trar and registrant. > 2) The internal design of the OpenSPP Organization table you have > below looks just fine to me, as a bare bones implementation (which I > think is what you are going for). I guess it holds the list of the > registrants that exist in the system. And since I do not see a > "hash" or "passkey" column in that table, there must be another table > that holds the "registrars" and their IDs and authentication > credential in some form, which is what would be used when > evaluating/handling the Digest Authentication sequence required by > the spec. Gee, until today it hadn't been apparent that the database needed to hold registrars. It wasn't in the spec as far as the developers could tell. It's not in the schema, and is mentioned only in the protocol docs (as far as I can tell) as something that's outside the scope of the protocol and left up to "policy". KJC: Then where do you store the authentication credentials? > 3) There is no password or cert associated with a "registrant". A > registrant never authenticates itself to the SPPP server. It is the > "registrar" that authenticates itself to the SPPP server. So there's no mechanism for registrants to access the data in the registry and audit it? KJC: Correct. The registrant role is not an actor/user of SPPP, only the = registrars are. That what Registrant and registrar mean. Can a registrant have relationships with multiple registrars (many-many), or does the protocol lock that down to many-one? Don't registrants need to access data in the database so they can offer and accept routing information to/from each other? No. The registrar role does that. Dean, you need to read and understand t= he definitions of registrar and registrant. I did not invent those terms. > 3) As discussed on today's call, we did have the "rarId" (registrar > ID) in the protocol. It was an attribute of each object. However, > as the final change to the protocol we removed it at the request of a > couple of the work group participants because they felt it got in the > way of the local policies that drive their local implementations of > authentication and authorization. We all agreed to do this because > we saw that it is not _strictly_ necessary to have the "rarId" data > element exist within the context of the SPPP messages going between > the client and the server. But it _is_ certainly necessary within > the internal server side implementation DB to keep the ID of the > registrar that created each object. If an audit query using SPPP needs to be able to tell us which registrar added or updated a given object, then we need rarId. KJC: Audit Query? You're inventing new requirements. The protocol is not= designed for auditing. Auditing is a very high volume activity that is be= st done via other means. That being said, I am not apposed to adding the r= arID back in. But the folks that wanted it removed would need to agree to = adding it back in. If we explicitly wish to preclude this function (which seems intuitively obvious and needful to somebody like me with an ops background) then we probably need to state explicitly that we've left it out of the protocol, and give reasons why. Otherwise the ops area people (who are admittedly less activist than in Randy Bush's IESG-days) are going to give us grief. KJC: Huh? Auditing is not supported by EPP, or Netconf, or ..... -- Dean This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From kcartwright@tnsi.com Fri Aug 26 06:29:17 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0763F21F8B79 for ; Fri, 26 Aug 2011 06:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pEEzxRRwUgu for ; Fri, 26 Aug 2011 06:29:16 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2A17B21F8B62 for ; Fri, 26 Aug 2011 06:29:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMAAOaeV06sEQfn/2dsb2JhbABCmDuQVIFAAQEEATo/DAQCAQgRAQMBARcICQcyFAMGCAEBBA4FCIdqBLpKg0MMgh1gBKQ2 X-IronPort-AV: E=Sophos;i="4.68,285,1312153200"; d="scan'208";a="145282" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 26 Aug 2011 14:30:31 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Fri, 26 Aug 2011 09:30:31 -0400 From: "Cartwright, Ken" To: Dean Willis Date: Fri, 26 Aug 2011 09:31:19 -0400 Thread-Topic: [drinks] Policy vs. Protocol Thread-Index: AcxjqhDZ3OOLxTLqRomy/wvF7E2nyAASipzw Message-ID: <754963199212404AB8E9CFCA6C3D0CDA38DDB8D174@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4E569811.3090503@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8CF82@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E56A625.4040104@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8D059@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E57235B.3030509@softarmor.com> In-Reply-To: <4E57235B.3030509@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] Policy vs. Protocol X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 13:29:17 -0000 Dean, there is no "registrar name" defined in the XSD schema. What are you= talking about? Ken -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Friday, August 26, 2011 12:39 AM To: Cartwright, Ken Cc: drinks@ietf.org Subject: Re: [drinks] Policy vs. Protocol On 8/25/11 4:17 PM, Cartwright, Ken wrote: > >> 2) Data Authorization Rules: What data objects will be "gettable" >> and "modifiable" by a given registrar/registrant. > > How does the user name returned by the digest authentication relate > to the registrar or registrant name as specified in the schema > especially given that the current schema says nothing about registrar > names? > > That's not a policy question. It's a protocol binding. > > KJC: There is no such "binding" that exists because the registrant > does not authenticate itself in SPPP. There is no construct in the > protocol to do such a thing because there has not been a requirement > for it. It is the registrar/SPPPClient that authenticates itself > using Digest Authentication. Okay, let's rephrase the question: How does the user name returned by the digest authentication relate to the registrar name as specified in the XSD schema? Is it a one-to-one mapping? Is it a direct mapping?Do we assume that they are textually the same? If so, what rules for string-comparison are used to match one against the other? I know this sounds like nit-picky crap. But it's the kind of stuff that IETF protocols often leave out (the first time) and that developers then get wrong, meaning "client A will not work with server B which will not work with provisioning system C" because A, B, and C filled in the ambiguous guesswork differently. The goal in spec-writing is to eliminate ambiguity, otherwise we're describing an architecture, not defining a protocol. There's nothing wrong with describing an architecture, of course. But we can't say to engineer A "Build me a plug with three wires for 220VAC" and to engineer B "Build me a socket with three wires for 220VAC" and hope to get a plug and a socket that work together. The history of the world's first known published engineering standard is worth reading: http://en.wikipedia.org/wiki/British_Standard_Whitworth -- Dean This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From kcartwright@tnsi.com Fri Aug 26 06:32:12 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 282C621F8B56 for ; Fri, 26 Aug 2011 06:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbj5B1J9vzER for ; Fri, 26 Aug 2011 06:32:09 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id E93E621F8B52 for ; Fri, 26 Aug 2011 06:32:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQAAECgV06sEQfn/2dsb2JhbABCgk2Vbo54gVyBQAEBBS0/HQIBCBEEAQEoBzIUCQgBAQQBEgjCKYVsYASkNg X-IronPort-AV: E=Sophos;i="4.68,285,1312153200"; d="scan'208,217";a="145292" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 26 Aug 2011 14:33:21 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Fri, 26 Aug 2011 09:33:21 -0400 From: "Cartwright, Ken" To: "Ali, Syed Wasim" , "drinks@ietf.org" Date: Fri, 26 Aug 2011 09:34:09 -0400 Thread-Topic: security considerations... Thread-Index: AcxjpR4NNZ0J3BzWQV6LnHhowBEaxQAT3jyQ Message-ID: <754963199212404AB8E9CFCA6C3D0CDA38DDB8D179@TNS-MAIL-NA.win2k.corp.tnsi.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_754963199212404AB8E9CFCA6C3D0CDA38DDB8D179TNSMAILNAwin2_" MIME-Version: 1.0 Subject: Re: [drinks] security considerations... X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 13:32:12 -0000 --_000_754963199212404AB8E9CFCA6C3D0CDA38DDB8D179TNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Syed, Thanks for this. A few comments. 1) I think the new items are the last three of the six paragraphs in Securi= ty considerations. 2) For paragraph 4, I think this "should" could be changed to a "may". SSL= and certs address the "not been tampered with" and "the source is known to= be who they say they are" requirements. XML signatures are more appropria= te for environments where SSL and certs are not being used. 3) For paragraph 5, this seems to be development guidance for how implement= ers can keep their internally managed data secure (after it has gotten into= their systems). I don't really see what this has to do with this protocol= . We should not be attempting to explain how to do that because the requir= ements for that will vary from deployment to deployment. And even the use = of XML encryption does not solve this problem. And this paragraph is not e= nough to enable the use of XML Encryption in this protocol. It does not ev= en have a reference to the XML Encryption spec. Lastly, the data managed b= y this protocol is not highly secret (i.e. there are no CCs, SSNs, person's= names, company names, etc, etc). At a minimum the "should" should be made= a "may". 4) I'm not sure I see a meaningful risk here related to replays (aka idempo= tence). A repeat of an "add" will not add the object twice, so it will do = no harm. A repeat of a delete will do no harm. A repeat of a mod will do = no harm. A repeat of a route offer will do no harm. As a result, I'm not = sure what is meant by " The Timestamps in the modify SPPP objects that refl= ect the time it was created MUST reflect the current time and the SPPP impl= ementations SHOULD test the time values to make sure that they are not repl= ayed inadvertently, or with a malicious intent." ________________________________ From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Ali, Syed Wasim Sent: Friday, August 26, 2011 12:04 AM To: drinks@ietf.org Subject: [drinks] security considerations... Hi, I am proposing addition of the following to the security considerations sec= tion. Thoughts? >>>>> For high visibility implementation, there may be additional concerns regard= ing repudiation issues and SPPP implementations may need to provide proof t= hat the message did not change since leaving the sender and to further vali= date the sender of SPPP message. Therefore, the SPPP implementations SHOULD= provide support for XML Signature standard to manage this concern. It is not uncommon for the logging systems to document on-the-wire messages= for various purposes, such as, debug, audit, and tracking. At the minimum,= the various support and administration staff will have access to these log= s. Also, if an unprivileged user gains access to the SPPP deployments and/o= r support systems, it will have access to the information that is potential= ly deemed confidential. To manage information disclosure concerns beyond th= e transport level, the SPPP implementations SHOULD support XML Encryption s= tandard to facilitate information hiding at the message level. Anti-replay protection ensures that a given SPPP object is not played back = at a later time and affect the integrity of the system. SPPP protocol provi= des at least two mechanisms to aid the implementers in this regard: client = transaction identifier and embedded create timestamps for the SPPP objects.= The client transaction identifier allows the sender to correlate the respo= nse with the request and verify that the transaction was returned from the = intended SPPP implementation. The timestamps in the modify SPPP objects tha= t reflect the time it was created MUST reflect the current time and the SPP= P implementations SHOULD test the time values to make sure that they are no= t replayed inadvertently, or with a malicious intent. <<<<< Thanks, -Syed -Syed ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_754963199212404AB8E9CFCA6C3D0CDA38DDB8D179TNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Syed,

 

Thanks for this.  A few comments.<= /p>

 

1) I think the new items are the last three of the six paragraph= s in Security considerations.

2) For paragraph 4, I think this "should" could be cha= nged to a "may".  SSL and certs address the "not been t= ampered with" and "the source is known to be who they say they are"= requirements.  XML signatures are more appropriate for environments w= here SSL and certs are not being used.

3) For paragraph 5, this seems to be development guidance for ho= w implementers can keep their internally managed data secure (after it has gotten into their systems).  I don’t reall= y see what this has to do with this protocol.  We should not be attemp= ting to explain how to do that because the requirements for that will vary = from deployment to deployment.  And even the use of XML encryption does not solve this problem.  And this paragraph is= not enough to enable the use of XML Encryption in this protocol.  It = does not even have a reference to the XML Encryption spec.  Lastly, th= e data managed by this protocol is not highly secret (i.e. there are no CCs, SSNs, person's names, company names, etc, etc).&nb= sp; At a minimum the "should" should be made a "may".

4) I'm not sure I see a meaningful risk here related to replays = (aka idempotence).  A repeat of an "add" will not add the object twice, so it will do no harm.  A repeat of a delete will d= o no harm.  A repeat of a mod will do no harm.  A repeat of a rou= te offer will do no harm.  As a result, I'm not sure what is meant by = " The Timestamps in the modify SPPP objects that reflect the time it was created MUST reflect the current time and the SPPP impleme= ntations SHOULD test the time values to make sure that they are not replaye= d inadvertently, or with a malicious intent."=

 

 

From: drin= ks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Ali, Syed Wasim
Sent: Friday, August 26, 201= 1 12:04 AM
To: drinks@ietf.org
Subject: [drinks] security c= onsiderations...

 

 <= /o:p>

Hi,

 <= /o:p>

I am proposi= ng addition of the following to the security considerations section. <= o:p>

 <= /o:p>

Thoughts?

 <= /o:p>

>>>= >> 

For high vis= ibility implementation, there may be additional concerns regarding repudiat= ion issues and SPPP implementations may need to provide proof that the message did not change since leaving the sender = and to further validate the sender of SPPP message. Therefore, the SPPP imp= lementations SHOULD provide support for XML Signature standard to manage th= is concern.

 <= /o:p>

It is not un= common for the logging systems to document on-the-wire messages for various= purposes, such as, debug, audit, and tracking. At the minimum, the various support and administration staff will have acc= ess to these logs. Also, if an unprivileged user gains access to the SPPP d= eployments and/or support systems, it will have access to the information t= hat is potentially deemed confidential. To manage information disclosure concerns beyond the transport level, the = SPPP implementations SHOULD support XML Encryption standard to facilitate i= nformation hiding at the message level.

 <= /o:p>

Anti-replay = protection ensures that a given SPPP object is not played back at a later t= ime and affect the integrity of the system. SPPP protocol provides at least two mechanisms to aid the implementers in = this regard: client transaction identifier and embedded create timestamps f= or the SPPP objects. The client transaction identifier allows the sender to= correlate the response with the request and verify that the transaction was returned from the intended SPP= P implementation. The timestamps in the modify SPPP objects that reflect th= e time it was created MUST reflect the current time and the SPPP implementa= tions SHOULD test the time values to make sure that they are not replayed inadvertently, or with a malicious= intent.

<<<= << 

 <= /o:p>

Thanks,=

 <= /o:p>

-Syed

 <= /o:p>

-Syed


This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_754963199212404AB8E9CFCA6C3D0CDA38DDB8D179TNSMAILNAwin2_-- From jeremyb@digitalshtick.com Fri Aug 26 08:00:16 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C09621F8B8B for ; Fri, 26 Aug 2011 08:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isxPQsf39mag for ; Fri, 26 Aug 2011 08:00:12 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [69.56.195.5]) by ietfa.amsl.com (Postfix) with SMTP id EA50C21F8B74 for ; Fri, 26 Aug 2011 08:00:11 -0700 (PDT) Received: (qmail 32414 invoked from network); 26 Aug 2011 15:06:37 -0000 Received: from ham.websitewelcome.com (173.192.111.51) by gateway14.websitewelcome.com with SMTP; 26 Aug 2011 15:06:37 -0000 Received: by ham.websitewelcome.com (Postfix, from userid 666) id 57FFB99F9677; Fri, 26 Aug 2011 09:58:59 -0500 (CDT) X-Spam-Flag2999: NO X-Spam-Level2999: X-Spam-Status2999: "No, score=0.0 required=5.0 tests=BAYES_40,HTML_MESSAGE autolearn=ham version=3.3.1 Received: from gator1286.hostgator.com (gator1286.hostgator.com [174.122.176.226]) by ham.websitewelcome.com (Postfix) with ESMTP id 39E2A99F8F40 for ; Fri, 26 Aug 2011 09:58:57 -0500 (CDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=digitalshtick.com; h=Received:From:To:References:In-Reply-To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-BWhitelist:X-Source:X-Source-Args:X-Source-Dir:X-Source-Sender:X-Source-Auth:X-Email-Count:X-Source-Cap; b=mQCpNCS0xNF4VnswbErOO8nwwSRMygOzkkpcVu32JwfzV5SRwbW1EyF/VnrSziPA23QuJe2oiPzkNnPeZmc9/c1THxCn2vQUu5sOtan2gUiPqs8AhZfnAdJBfpvKkpSk; Received: from [46.116.85.236] (port=62076 helo=jeremybxps) by gator1286.hostgator.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qwxrw-0003ry-Dm; Fri, 26 Aug 2011 09:58:55 -0500 From: "Jeremy Barkan \(Digitalshtick\)" To: "'Cartwright, Ken'" , "'Ali, Syed Wasim'" , References: <754963199212404AB8E9CFCA6C3D0CDA38DDB8D179@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA38DDB8D179@TNS-MAIL-NA.win2k.corp.tnsi.com> Date: Fri, 26 Aug 2011 17:58:14 +0300 Organization: Digitalshtick Message-ID: <030401cc6400$968e2f60$c3aa8e20$@digitalshtick.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0305_01CC6419.BBE1F710" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKmqCX12dto1+GH6zWO6NCwCfPFMAF7DOPjk27SBcA= Content-Language: en-gb X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - digitalshtick.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 46-116-85-236.bb.netvision.net.il (jeremybxps) [46.116.85.236]:62076 X-Source-Auth: jeremyb@digitalshtick.com X-Email-Count: 3 X-Source-Cap: bGlzYW1hcms7bGlzYW1hcms7Z2F0b3IxMjg2Lmhvc3RnYXRvci5jb20= Subject: Re: [drinks] security considerations... X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 15:00:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0305_01CC6419.BBE1F710 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Syed & Ken, Some thoughts - Re: Repudiation and Signed SPPP Messages For clarity - is what you are proposing to sign the SPPP command ? I'm distinguishing between message integrity tampering on the wire - in transport [ as Ken refers to SSL ] - which could be made a requirement of the transport [ such as HTTPS ] - and end to end message integrity which would mean having clients sign commands and registries sign responses and require a trust system and certificate authorities and so on. In non-repudiation per-se - you would a signed command as a binding proof that a client issued a command to a server - so the command would be - "add a record route" signed SPPP_Provider_3. Similarly - in route offers and in acceptance of route offers. I think we should be sure this is a requirement before adding it to the protocol - and if XML-SIG at the level of the SPPP Command is the right place to do this. Re: Encryption - I would also distinguish between the threats on the wire, and the end-to-end threats. In the case of privacy - exposure of the a log or audit trail could bypass all the authorization and visibility rules we spoke about. That said - encrypting the SPPP Commands and having an encrypted log or audit trail is a level of complexity. That said - having a tamper-proof audit trail would certainly be a best-practice, although I do not recall seeing other protocols where this is required of the server. Re: Replay attack - I agree with Ken's comment. I don't understand the threat, other than a DOS type attack. In fact - given that the protocol is stateless and does not really have a session [ albeit commands can be batched ] - we would need a way to construct unique client identifiers. Best Regards and wishing all a good weekend Jeremy Jeremy Barkan CTO Digitalshtick Tel: +972 2 6728069 Mobile: +972 54 6321603 Skype: jeremy_barkan www.digitalshtick.com From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Cartwright, Ken Sent: 26 August 2011 16:34 To: Ali, Syed Wasim; drinks@ietf.org Subject: Re: [drinks] security considerations... Hi Syed, Thanks for this. A few comments. 1) I think the new items are the last three of the six paragraphs in Security considerations. 2) For paragraph 4, I think this "should" could be changed to a "may". SSL and certs address the "not been tampered with" and "the source is known to be who they say they are" requirements. XML signatures are more appropriate for environments where SSL and certs are not being used. 3) For paragraph 5, this seems to be development guidance for how implementers can keep their internally managed data secure (after it has gotten into their systems). I don't really see what this has to do with this protocol. We should not be attempting to explain how to do that because the requirements for that will vary from deployment to deployment. And even the use of XML encryption does not solve this problem. And this paragraph is not enough to enable the use of XML Encryption in this protocol. It does not even have a reference to the XML Encryption spec. Lastly, the data managed by this protocol is not highly secret (i.e. there are no CCs, SSNs, person's names, company names, etc, etc). At a minimum the "should" should be made a "may". 4) I'm not sure I see a meaningful risk here related to replays (aka idempotence). A repeat of an "add" will not add the object twice, so it will do no harm. A repeat of a delete will do no harm. A repeat of a mod will do no harm. A repeat of a route offer will do no harm. As a result, I'm not sure what is meant by " The Timestamps in the modify SPPP objects that reflect the time it was created MUST reflect the current time and the SPPP implementations SHOULD test the time values to make sure that they are not replayed inadvertently, or with a malicious intent." _____ From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Ali, Syed Wasim Sent: Friday, August 26, 2011 12:04 AM To: drinks@ietf.org Subject: [drinks] security considerations... Hi, I am proposing addition of the following to the security considerations section. Thoughts? >>>>> For high visibility implementation, there may be additional concerns regarding repudiation issues and SPPP implementations may need to provide proof that the message did not change since leaving the sender and to further validate the sender of SPPP message. Therefore, the SPPP implementations SHOULD provide support for XML Signature standard to manage this concern. It is not uncommon for the logging systems to document on-the-wire messages for various purposes, such as, debug, audit, and tracking. At the minimum, the various support and administration staff will have access to these logs. Also, if an unprivileged user gains access to the SPPP deployments and/or support systems, it will have access to the information that is potentially deemed confidential. To manage information disclosure concerns beyond the transport level, the SPPP implementations SHOULD support XML Encryption standard to facilitate information hiding at the message level. Anti-replay protection ensures that a given SPPP object is not played back at a later time and affect the integrity of the system. SPPP protocol provides at least two mechanisms to aid the implementers in this regard: client transaction identifier and embedded create timestamps for the SPPP objects. The client transaction identifier allows the sender to correlate the response with the request and verify that the transaction was returned from the intended SPPP implementation. The timestamps in the modify SPPP objects that reflect the time it was created MUST reflect the current time and the SPPP implementations SHOULD test the time values to make sure that they are not replayed inadvertently, or with a malicious intent. <<<<< Thanks, -Syed -Syed _____ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Services. Any unauthorised review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ------=_NextPart_000_0305_01CC6419.BBE1F710 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Syed & Ken,

 

Some thoughts -

 

Re: Repudiation and Signed SPPP Messages

For clarity – is what you are proposing to sign the SPPP = command ?  I'm distinguishing between message integrity =  tampering on the wire – in transport [ as Ken refers to SSL = ] – which could be made a requirement of the transport [ such as = HTTPS ]  - and end to end message integrity which would mean having = clients sign commands and registries sign responses and require a trust = system and certificate authorities and so on.

In non-repudiation per-se – you would a signed command as a = binding proof that a client issued a command to a server – so the = command would be – "add a record route" signed = SPPP_Provider_3.

Similarly – in route offers and in acceptance of route = offers.

I think we should be sure this is a requirement before adding it to = the protocol – and if XML-SIG at the level of the SPPP Command is = the right place to do this.

 

Re: Encryption – I would also distinguish between the threats = on the wire, and the end-to-end threats. In the case of privacy – = exposure of the a log or audit trail could bypass all the authorization = and visibility rules we spoke about. That said – encrypting the = SPPP Commands and having an encrypted log or audit trail is a level of = complexity.

That said – having a tamper-proof audit trail would certainly = be a best-practice, although I do not recall seeing other protocols = where this is required of the server.

 

Re: Replay attack – I agree with Ken's comment. I don't = understand the threat, other than a DOS type attack.  In fact = – given that the protocol is stateless and does not really have a = session [ albeit commands can be batched ] – we would need a way = to construct unique client identifiers.

 

Best Regards and wishing all a good weekend

 

Jeremy

 

 

Jeremy Barkan

 

CTO

Digitalshtick

Tel: +972 2 6728069

Mobile: +972 54 6321603

Skype: jeremy_barkan

www.digitalshtick.com

 

 

 

From:= = drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of = Cartwright, Ken
Sent: 26 August 2011 16:34
To: = Ali, Syed Wasim; drinks@ietf.org
Subject: Re: [drinks] = security considerations...

 

Hi = Syed,

 

Thanks for = this.  A few comments.

 

1) I think the new = items are the last three of the six paragraphs in Security = considerations.

2) For paragraph 4, = I think this "should" could be changed to a = "may".  SSL and certs address the "not been tampered = with" and "the source is known to be who they say they = are" requirements.  XML signatures are more appropriate for = environments where SSL and certs are not being = used.

3) For paragraph 5, = this seems to be development guidance for how implementers can keep = their internally managed data secure (after it has gotten into their = systems).  I don’t really see what this has to do with this = protocol.  We should not be attempting to explain how to do that = because the requirements for that will vary from deployment to = deployment.  And even the use of XML encryption does not solve this = problem.  And this paragraph is not enough to enable the use of XML = Encryption in this protocol.  It does not even have a reference to = the XML Encryption spec.  Lastly, the data managed by this protocol = is not highly secret (i.e. there are no CCs, SSNs, person's names, = company names, etc, etc).  At a minimum the "should" = should be made a "may".

4) I'm not sure I = see a meaningful risk here related to replays (aka idempotence).  A = repeat of an "add" will not add the object twice, so it will = do no harm.  A repeat of a delete will do no harm.  A repeat = of a mod will do no harm.  A repeat of a route offer will do no = harm.  As a result, I'm not sure what is meant by " The = Timestamps in the modify SPPP objects that reflect the time it was = created MUST reflect the current time and the SPPP implementations = SHOULD test the time values to make sure that they are not replayed = inadvertently, or with a malicious intent."

 

 

From:= = drinks-bounces@ietf.org = [mailto:drinks-bounces@i= etf.org] On Behalf Of Ali, Syed Wasim
Sent: Friday, = August 26, 2011 12:04 AM
To: drinks@ietf.org
Subject: = [drinks] security considerations...

 

 

Hi,

 

I am proposing addition of the following to the security considerations = section. 

 

Thoughts?

 

>>>>> 

For high visibility implementation, there may be additional concerns = regarding repudiation issues and SPPP implementations may need to = provide proof that the message did not change since leaving the sender = and to further validate the sender of SPPP message. Therefore, the SPPP = implementations SHOULD provide support for XML Signature standard to = manage this concern.

 

It is not uncommon for the logging systems to document on-the-wire = messages for various purposes, such as, debug, audit, and tracking. At = the minimum, the various support and administration staff will have = access to these logs. Also, if an unprivileged user gains access to the = SPPP deployments and/or support systems, it will have access to the = information that is potentially deemed confidential. To manage = information disclosure concerns beyond the transport level, the SPPP = implementations SHOULD support XML Encryption standard to facilitate = information hiding at the message = level.

 

Anti-replay protection ensures that a given SPPP object is not played = back at a later time and affect the integrity of the system. SPPP = protocol provides at least two mechanisms to aid the implementers in = this regard: client transaction identifier and embedded create = timestamps for the SPPP objects. The client transaction identifier = allows the sender to correlate the response with the request and verify = that the transaction was returned from the intended SPPP implementation. = The timestamps in the modify SPPP objects that reflect the time it was = created MUST reflect the current time and the SPPP implementations = SHOULD test the time values to make sure that they are not replayed = inadvertently, or with a malicious = intent.

<<<<< 

 

Thanks,

 

-Syed

 

-Syed

 

Thi= s e-mail message is for the sole use of the intended recipient(s)and = may
contain confidential and privileged information of Transaction = Network Services.
Any unauthorised review, use, disclosure or = distribution is prohibited. If you
are not the intended recipient, = please contact the sender by reply e-mail and destroy all copies of the = original message.

------=_NextPart_000_0305_01CC6419.BBE1F710-- From kcartwright@tnsi.com Fri Aug 26 08:19:05 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31F121F8779 for ; Fri, 26 Aug 2011 08:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.911 X-Spam-Level: X-Spam-Status: No, score=-0.911 tagged_above=-999 required=5 tests=[AWL=-1.646, BAYES_00=-2.599, FB_IOW=3.333, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlpqHtJsIgHp for ; Fri, 26 Aug 2011 08:19:01 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 734A621F8B85 for ; Fri, 26 Aug 2011 08:19:00 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUAAJS4V06sEQfn/2dsb2JhbABCgk2VeI54gVyBQAEBBS0cIx0CAQgHCgQBARoCBQEGBzIUCQgCBAESCMFkg1cCghNgBKQ2 X-IronPort-AV: E=Sophos;i="4.68,285,1312153200"; d="scan'208,217";a="145944" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 26 Aug 2011 16:20:13 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Fri, 26 Aug 2011 11:20:13 -0400 From: "Cartwright, Ken" To: "Jeremy Barkan (Digitalshtick)" , "'Ali, Syed Wasim'" , "drinks@ietf.org" Date: Fri, 26 Aug 2011 11:21:00 -0400 Thread-Topic: [drinks] security considerations... Thread-Index: AQKmqCX12dto1+GH6zWO6NCwCfPFMAF7DOPjk27SBcCAAAu5QA== Message-ID: <754963199212404AB8E9CFCA6C3D0CDA38DDC746C2@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <754963199212404AB8E9CFCA6C3D0CDA38DDB8D179@TNS-MAIL-NA.win2k.corp.tnsi.com> <030401cc6400$968e2f60$c3aa8e20$@digitalshtick.com> In-Reply-To: <030401cc6400$968e2f60$c3aa8e20$@digitalshtick.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_754963199212404AB8E9CFCA6C3D0CDA38DDC746C2TNSMAILNAwin2_" MIME-Version: 1.0 Subject: Re: [drinks] security considerations... X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 15:19:05 -0000 --_000_754963199212404AB8E9CFCA6C3D0CDA38DDC746C2TNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jeremy, The protocol "musts" HTTPS and also "shoulds" certs based server and client= auth. Imo, the cert based server and client auth covers what you refer to= as "end-to-end message integrity". Iow, if you have used the cert to veri= fy that the party on the other end is who you think they are then it's cove= red I believe. And anything more than that I do not see as necessary (a "m= ay" at best). Ken ________________________________ From: Jeremy Barkan (Digitalshtick) [mailto:jeremyb@digitalshtick.com] Sent: Friday, August 26, 2011 10:58 AM To: Cartwright, Ken; 'Ali, Syed Wasim'; drinks@ietf.org Subject: RE: [drinks] security considerations... Hi Syed & Ken, Some thoughts - Re: Repudiation and Signed SPPP Messages For clarity - is what you are proposing to sign the SPPP command ? I'm dis= tinguishing between message integrity tampering on the wire - in transport= [ as Ken refers to SSL ] - which could be made a requirement of the transp= ort [ such as HTTPS ] - and end to end message integrity which would mean = having clients sign commands and registries sign responses and require a tr= ust system and certificate authorities and so on. In non-repudiation per-se - you would a signed command as a binding proof t= hat a client issued a command to a server - so the command would be - "add = a record route" signed SPPP_Provider_3. Similarly - in route offers and in acceptance of route offers. I think we should be sure this is a requirement before adding it to the pro= tocol - and if XML-SIG at the level of the SPPP Command is the right place = to do this. Re: Encryption - I would also distinguish between the threats on the wire, = and the end-to-end threats. In the case of privacy - exposure of the a log = or audit trail could bypass all the authorization and visibility rules we s= poke about. That said - encrypting the SPPP Commands and having an encrypte= d log or audit trail is a level of complexity. That said - having a tamper-proof audit trail would certainly be a best-pra= ctice, although I do not recall seeing other protocols where this is requir= ed of the server. Re: Replay attack - I agree with Ken's comment. I don't understand the thre= at, other than a DOS type attack. In fact - given that the protocol is sta= teless and does not really have a session [ albeit commands can be batched = ] - we would need a way to construct unique client identifiers. Best Regards and wishing all a good weekend Jeremy Jeremy Barkan CTO Digitalshtick Tel: +972 2 6728069 Mobile: +972 54 6321603 Skype: jeremy_barkan www.digitalshtick.com From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Cartwright, Ken Sent: 26 August 2011 16:34 To: Ali, Syed Wasim; drinks@ietf.org Subject: Re: [drinks] security considerations... Hi Syed, Thanks for this. A few comments. 1) I think the new items are the last three of the six paragraphs in Securi= ty considerations. 2) For paragraph 4, I think this "should" could be changed to a "may". SSL= and certs address the "not been tampered with" and "the source is known to= be who they say they are" requirements. XML signatures are more appropria= te for environments where SSL and certs are not being used. 3) For paragraph 5, this seems to be development guidance for how implement= ers can keep their internally managed data secure (after it has gotten into= their systems). I don't really see what this has to do with this protocol= . We should not be attempting to explain how to do that because the requir= ements for that will vary from deployment to deployment. And even the use = of XML encryption does not solve this problem. And this paragraph is not e= nough to enable the use of XML Encryption in this protocol. It does not ev= en have a reference to the XML Encryption spec. Lastly, the data managed b= y this protocol is not highly secret (i.e. there are no CCs, SSNs, person's= names, company names, etc, etc). At a minimum the "should" should be made= a "may". 4) I'm not sure I see a meaningful risk here related to replays (aka idempo= tence). A repeat of an "add" will not add the object twice, so it will do = no harm. A repeat of a delete will do no harm. A repeat of a mod will do = no harm. A repeat of a route offer will do no harm. As a result, I'm not = sure what is meant by " The Timestamps in the modify SPPP objects that refl= ect the time it was created MUST reflect the current time and the SPPP impl= ementations SHOULD test the time values to make sure that they are not repl= ayed inadvertently, or with a malicious intent." ________________________________ From: drinks-bounces@ietf.org [mailto:drink= s-bounces@ietf.org] On Behalf = Of Ali, Syed Wasim Sent: Friday, August 26, 2011 12:04 AM To: drinks@ietf.org Subject: [drinks] security considerations... Hi, I am proposing addition of the following to the security considerations sec= tion. Thoughts? >>>>> For high visibility implementation, there may be additional concerns regard= ing repudiation issues and SPPP implementations may need to provide proof t= hat the message did not change since leaving the sender and to further vali= date the sender of SPPP message. Therefore, the SPPP implementations SHOULD= provide support for XML Signature standard to manage this concern. It is not uncommon for the logging systems to document on-the-wire messages= for various purposes, such as, debug, audit, and tracking. At the minimum,= the various support and administration staff will have access to these log= s. Also, if an unprivileged user gains access to the SPPP deployments and/o= r support systems, it will have access to the information that is potential= ly deemed confidential. To manage information disclosure concerns beyond th= e transport level, the SPPP implementations SHOULD support XML Encryption s= tandard to facilitate information hiding at the message level. Anti-replay protection ensures that a given SPPP object is not played back = at a later time and affect the integrity of the system. SPPP protocol provi= des at least two mechanisms to aid the implementers in this regard: client = transaction identifier and embedded create timestamps for the SPPP objects.= The client transaction identifier allows the sender to correlate the respo= nse with the request and verify that the transaction was returned from the = intended SPPP implementation. The timestamps in the modify SPPP objects tha= t reflect the time it was created MUST reflect the current time and the SPP= P implementations SHOULD test the time values to make sure that they are no= t replayed inadvertently, or with a malicious intent. <<<<< Thanks, -Syed -Syed ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_754963199212404AB8E9CFCA6C3D0CDA38DDC746C2TNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jeremy,

 

The protocol “musts” HTTPS= and also “shoulds” certs based server and client auth.  I= mo, the cert based server and client auth covers what you refer to as “end-to-end message integrity”.  Iow= , if you have used the cert to verify that the party on the other end is wh= o you think they are then it’s covered I believe.  And anything = more than that I do not see as necessary (a “may” at best).

 

Ken

 

From: Jere= my Barkan (Digitalshtick) [mailto:jeremyb@digitalshtick.com]
Sent: Friday, August 26, 201= 1 10:58 AM
To: Cartwright, Ken; 'Ali, Syed Wasim'; drinks@ietf.org
Subject: RE: [drinks] securi= ty considerations...

 

= Hi Syed = & Ken,

= &nb= sp;

= Some tho= ughts -

= &nb= sp;

= Re: Repu= diation and Signed SPPP Messages

= For clar= ity – is what you are proposing to sign the SPPP command ?  I'm = distinguishing between message integrity  tampering on the wire – in transport [ as Ken refers to SSL ] – which could= be made a requirement of the transport [ such as HTTPS ]  - and end t= o end message integrity which would mean having clients sign commands and r= egistries sign responses and require a trust system and certificate authorities and so on.

= In non-r= epudiation per-se – you would a signed command as a binding proof tha= t a client issued a command to a server – so the command would be – "add a record route" signed SPPP_Provid= er_3.

= Similarl= y – in route offers and in acceptance of route offers.

= I think = we should be sure this is a requirement before adding it to the protocol &#= 8211; and if XML-SIG at the level of the SPPP Command is the right place to do this.

= &nb= sp;

= Re: Encr= yption – I would also distinguish between the threats on the wire, an= d the end-to-end threats. In the case of privacy – exposure of the a log or audit trail could bypass all the authoriz= ation and visibility rules we spoke about. That said – encrypting the= SPPP Commands and having an encrypted log or audit trail is a level of com= plexity.

= That sai= d – having a tamper-proof audit trail would certainly be a best-pract= ice, although I do not recall seeing other protocols where this is required of the server.

= &nb= sp;

= Re: Repl= ay attack – I agree with Ken's comment. I don't understand the threat= , other than a DOS type attack.  In fact – given that the protocol is stateless and does not really have a session [ albeit= commands can be batched ] – we would need a way to construct unique = client identifiers.

= &nb= sp;

= Best Reg= ards and wishing all a good weekend

= &nb= sp;

= Jeremy

= &nb= sp;

= &nb= sp;

Jeremy Barkan

 

= CTO=

= Digitals= htick

= Tel: = 3;972 2 6728069

Mobile: +972 54 6321603

= Skype: j= eremy_barkan

= www.digitalshtick.com

= &nb= sp;

= &nb= sp;

= &nb= sp;

From: drin= ks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Cartwright, Ken=
Sent: 26 August 2011 16:34 To: Ali, Syed Wasim; drinks@ietf.org
Subject: Re: [drinks] securi= ty considerations...

 

Hi Syed,

 

Thanks for this.  A few comments.<= /p>

 

1) I think the new items are the last three of the six paragraph= s in Security considerations.

2) For paragraph 4, I think this "should" could be cha= nged to a "may".  SSL and certs address the "not been t= ampered with" and "the source is known to be who they say they are"= requirements.  XML signatures are more appropriate for environments w= here SSL and certs are not being used.

3) For paragraph 5, this seems to be development guidance for ho= w implementers can keep their internally managed data secure (after it has gotten into their systems).  I don’t reall= y see what this has to do with this protocol.  We should not be attemp= ting to explain how to do that because the requirements for that will vary = from deployment to deployment.  And even the use of XML encryption does not solve this problem.  And this paragraph is= not enough to enable the use of XML Encryption in this protocol.  It = does not even have a reference to the XML Encryption spec.  Lastly, th= e data managed by this protocol is not highly secret (i.e. there are no CCs, SSNs, person's names, company names, etc, etc).&nb= sp; At a minimum the "should" should be made a "may".

4) I'm not sure I see a meaningful risk here related to replays = (aka idempotence).  A repeat of an "add" will not add the object twice, so it will do no harm.  A repeat of a delete will d= o no harm.  A repeat of a mod will do no harm.  A repeat of a rou= te offer will do no harm.  As a result, I'm not sure what is meant by = " The Timestamps in the modify SPPP objects that reflect the time it was created MUST reflect the current time and the SPPP impleme= ntations SHOULD test the time values to make sure that they are not replaye= d inadvertently, or with a malicious intent."=

 

 

From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On= Behalf Of Ali, Syed Wasim
Sent: Friday, August 26, 201= 1 12:04 AM
To: drinks@ietf.org
Subject: [drinks] security c= onsiderations...

 

 <= /o:p>

Hi,

 <= /o:p>

I am proposi= ng addition of the following to the security considerations section. <= o:p>

 <= /o:p>

Thoughts?

 <= /o:p>

>>>= >> 

For high vis= ibility implementation, there may be additional concerns regarding repudiat= ion issues and SPPP implementations may need to provide proof that the message did not change since leaving the sender = and to further validate the sender of SPPP message. Therefore, the SPPP imp= lementations SHOULD provide support for XML Signature standard to manage th= is concern.

 <= /o:p>

It is not un= common for the logging systems to document on-the-wire messages for various= purposes, such as, debug, audit, and tracking. At the minimum, the various support and administration staff will have acc= ess to these logs. Also, if an unprivileged user gains access to the SPPP d= eployments and/or support systems, it will have access to the information t= hat is potentially deemed confidential. To manage information disclosure concerns beyond the transport level, the = SPPP implementations SHOULD support XML Encryption standard to facilitate i= nformation hiding at the message level.

 <= /o:p>

Anti-replay = protection ensures that a given SPPP object is not played back at a later t= ime and affect the integrity of the system. SPPP protocol provides at least two mechanisms to aid the implementers in = this regard: client transaction identifier and embedded create timestamps f= or the SPPP objects. The client transaction identifier allows the sender to= correlate the response with the request and verify that the transaction was returned from the intended SPP= P implementation. The timestamps in the modify SPPP objects that reflect th= e time it was created MUST reflect the current time and the SPPP implementa= tions SHOULD test the time values to make sure that they are not replayed inadvertently, or with a malicious= intent.

<<<= << 

 <= /o:p>

Thanks,=

 <= /o:p>

-Syed

 <= /o:p>

-Syed

 

This e-mail message is for the sole use of the intended recipie= nt(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.


This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_754963199212404AB8E9CFCA6C3D0CDA38DDC746C2TNSMAILNAwin2_-- From dean.willis@softarmor.com Fri Aug 26 12:26:16 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D774C21F8C7B for ; Fri, 26 Aug 2011 12:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.935 X-Spam-Level: X-Spam-Status: No, score=-102.935 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599, DRUGS_ERECTILE=1, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1z-Ls2222ESc for ; Fri, 26 Aug 2011 12:26:16 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0579421F87F0 for ; Fri, 26 Aug 2011 12:26:15 -0700 (PDT) Received: by ywe9 with SMTP id 9so3616902ywe.31 for ; Fri, 26 Aug 2011 12:27:32 -0700 (PDT) Received: by 10.236.191.35 with SMTP id f23mr9699031yhn.8.1314386852834; Fri, 26 Aug 2011 12:27:32 -0700 (PDT) Received: from dwillis-mb1.local (cpe-66-25-15-110.tx.res.rr.com [66.25.15.110]) by mx.google.com with ESMTPS id f48sm2457598yhh.0.2011.08.26.12.27.31 (version=SSLv3 cipher=OTHER); Fri, 26 Aug 2011 12:27:32 -0700 (PDT) Message-ID: <4E57F3A3.8010400@softarmor.com> Date: Fri, 26 Aug 2011 14:27:31 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "Cartwright, Ken" References: <754963199212404AB8E9CFCA6C3D0CDA38DD5F2E9E@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E5651F2.2090307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8CDE8@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E56A264.50703@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8CFC5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E571FF3.1070308@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8D170@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA38DDB8D170@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "drinks@ietf.org" Subject: Re: [drinks] Long Followup to Thoughts on "Organization" in draft-ietf-drinks-spprov-09 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 19:26:17 -0000 On 8/26/11 8:29 AM, Cartwright, Ken wrote: > > Gee, until today it hadn't been apparent that the database needed to > hold registrars. It wasn't in the spec as far as the developers > could tell. It's not in the schema, and is mentioned only in the > protocol docs (as far as I can tell) as something that's outside the > scope of the protocol and left up to "policy". > > KJC: Then where do you store the authentication credentials? Don't have any yet. Since how it worked was not obvious from the spec, we put that off to a future phase. Consequently, OpenSPP "sprint 2 demonstrable" does no authentication and no authorization checks. It's wide-open, and I'm expecting spammers to figure out how to put porn and viagra links in there any day. Perhaps if you'd shown up for the demo sessions... > Can a registrant have relationships with multiple registrars > (many-many), or does the protocol lock that down to many-one? > > Don't registrants need to access data in the database so they can > offer and accept routing information to/from each other? > > No. The registrar role does that. Dean, you need to read and > understand the definitions of registrar and registrant. I did not > invent those terms. Okay, maybe the business model isn't clear to me. As a VoIP provider, why on earth would I allow my registrar to negotiate which routes I want to accept from a peer? I need control over the routes I'm offering my peers and the routes I'm accepting from them. >> 3) As discussed on today's call, we did have the "rarId" (registrar >> ID) in the protocol. It was an attribute of each object. However, >> as the final change to the protocol we removed it at the request of >> a couple of the work group participants because they felt it got in >> the way of the local policies that drive their local >> implementations of authentication and authorization. We all agreed >> to do this because we saw that it is not _strictly_ necessary to >> have the "rarId" data element exist within the context of the SPPP >> messages going between the client and the server. But it _is_ >> certainly necessary within the internal server side implementation >> DB to keep the ID of the registrar that created each object. > > If an audit query using SPPP needs to be able to tell us which > registrar added or updated a given object, then we need rarId. > > KJC: Audit Query? You're inventing new requirements. The protocol > is not designed for auditing. Auditing is a very high volume > activity that is best done via other means. That being said, I am > not apposed to adding the rarID back in. But the folks that wanted > it removed would need to agree to adding it back in. It all comes down to whether or not a registrant can have relations with multiple registrars. If not, then we can use a single table mapping registrant to registrar, and don't need to track registrar in the objects. If, however, there is a possibility that a single registrant can have records with multiple registrars, then we require a registrar ID in the object too. Even if the case where there is a single registrar per registrant, we require a table mapping registrant to registrar to be able to manage permissions at the registrar level on objects that are only identified in the schema by their registrant. In other words, if I understand you correctly, we authenticate and authorize exclusively based on the registrar's identity. That is, only registrars have Auth_ID. But records in the current database are keyed by registrant, not registrar. So there's currently no way to look at a record and decide whether a given registrar "owns" that record on behalf of the registrant, and consequently we have no way to decide whether the registrar should be allowed to modify (or even read) that record. > If we explicitly wish to preclude this function (which seems > intuitively obvious and needful to somebody like me with an ops > background) then we probably need to state explicitly that we've > left it out of the protocol, and give reasons why. Otherwise the ops > area people (who are admittedly less activist than in Randy Bush's > IESG-days) are going to give us grief. > > KJC: Huh? Auditing is not supported by EPP, or Netconf, or ..... Auditing is supported by the ability to query the data and see what is there, as well as by the ability to insert new data and observe state changes on the output. Clearly this can be done in SPPP, EPP, NetConf, whatever. The question is: which actors have the rights to do it, and what tools do they do it with? One doesn't necessarily have to do it. it through the provisioning front end. But if not for auditing, why do we have query methods instead of just add/update methods? With EPP I can, for example, do a "dig" on the final result and see what's there. I suppose in certain use cases, where the information from SPPP is eventually making its way into an ENUM presentation, that one could audit from that end. I'm accustomed to thinking of data in private ENUM as being unavailable, but I suppose the scenarios you have in mind require that the registrant be able to query the ENUM directly. The problem is that the final ENUM presentation is a rather complex calculation of destination groups, route groups, offers, answers, acceptances, etc. It could be very hard to debug from the output alone. It would be a lot easier if, as a registrant. I could just query the registry using SPPP (or something similar) and verify the inputs. -- Dean From dean.willis@softarmor.com Fri Aug 26 12:29:33 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4B221F8C7E for ; Fri, 26 Aug 2011 12:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.419 X-Spam-Level: X-Spam-Status: No, score=-103.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52ljYGKFYTc9 for ; Fri, 26 Aug 2011 12:29:32 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id A25F121F8BA2 for ; Fri, 26 Aug 2011 12:29:32 -0700 (PDT) Received: by gwb20 with SMTP id 20so3642436gwb.31 for ; Fri, 26 Aug 2011 12:30:49 -0700 (PDT) Received: by 10.236.165.71 with SMTP id d47mr3539655yhl.15.1314387049458; Fri, 26 Aug 2011 12:30:49 -0700 (PDT) Received: from dwillis-mb1.local (cpe-66-25-15-110.tx.res.rr.com [66.25.15.110]) by mx.google.com with ESMTPS id q25sm1443586yhm.20.2011.08.26.12.30.48 (version=SSLv3 cipher=OTHER); Fri, 26 Aug 2011 12:30:48 -0700 (PDT) Message-ID: <4E57F467.5050505@softarmor.com> Date: Fri, 26 Aug 2011 14:30:47 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "Cartwright, Ken" References: <4E569811.3090503@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8CF82@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E56A625.4040104@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8D059@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E57235B.3030509@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8D174@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA38DDB8D174@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "drinks@ietf.org" Subject: Re: [drinks] Policy vs. Protocol X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 19:29:33 -0000 On 8/26/11 8:31 AM, Cartwright, Ken wrote: > Dean, there is no "registrar name" defined in the XSD schema. What are you talking about? My bad. Maybe I should just say "rar" and "rant" instear of "registar" and "registrant". Let's try again: How does the user name returned by the digest authentication relate to the registrant name as specified in the XSD schema? Is it a one-to-one mapping? Is it a direct mapping? Do we assume that they are textually the same? If so, what rules for string-comparison are used to match one against the other? -- dean From kcartwright@tnsi.com Fri Aug 26 12:36:37 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531BA21F8C92 for ; Fri, 26 Aug 2011 12:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=-0.369, BAYES_00=-2.599, DRUGS_ERECTILE=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+44p4pKkOPM for ; Fri, 26 Aug 2011 12:36:36 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 58B2E21F8C53 for ; Fri, 26 Aug 2011 12:36:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUAAI31V06sEQfn/2dsb2JhbAA6CZhIkFWBQAEBBAE6OAcFBwQCAQgRBAEBAR4JBzIUCQgBAQQOBQiHarpcgymCQ2AEpDY X-IronPort-AV: E=Sophos;i="4.68,286,1312153200"; d="scan'208";a="147255" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 26 Aug 2011 20:37:49 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Fri, 26 Aug 2011 15:38:37 -0400 From: "Cartwright, Ken" To: Dean Willis Date: Fri, 26 Aug 2011 15:38:36 -0400 Thread-Topic: Long Followup to Thoughts on "Organization" in draft-ietf-drinks-spprov-09 Thread-Index: AcxkJjXSuEod1jaMRWCetlpe2RQ9ggAAFBPA Message-ID: <754963199212404AB8E9CFCA6C3D0CDA38DDC748B8@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <754963199212404AB8E9CFCA6C3D0CDA38DD5F2E9E@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E5651F2.2090307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8CDE8@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E56A264.50703@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8CFC5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E571FF3.1070308@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8D170@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E57F3A3.8010400@softarmor.com> In-Reply-To: <4E57F3A3.8010400@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] Long Followup to Thoughts on "Organization" in draft-ietf-drinks-spprov-09 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 19:36:37 -0000 Responses in-line (KJC2). -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Friday, August 26, 2011 3:28 PM To: Cartwright, Ken Cc: drinks@ietf.org Subject: Re: Long Followup to Thoughts on "Organization" in draft-ietf-drin= ks-spprov-09 On 8/26/11 8:29 AM, Cartwright, Ken wrote: > > Gee, until today it hadn't been apparent that the database needed to > hold registrars. It wasn't in the spec as far as the developers > could tell. It's not in the schema, and is mentioned only in the > protocol docs (as far as I can tell) as something that's outside the > scope of the protocol and left up to "policy". > > KJC: Then where do you store the authentication credentials? Don't have any yet. Since how it worked was not obvious from the spec, we put that off to a future phase. KJC2: Dean that is not at all correct. The spec explicitly requires Diges= t Authentication. Consequently, OpenSPP "sprint 2 demonstrable" does no authentication and no authorization checks. It's wide-open, and I'm expecting spammers to figure out how to put porn and viagra links in there any day. Perhaps if you'd shown up for the demo sessions... > Can a registrant have relationships with multiple registrars > (many-many), or does the protocol lock that down to many-one? > > Don't registrants need to access data in the database so they can > offer and accept routing information to/from each other? > > No. The registrar role does that. Dean, you need to read and > understand the definitions of registrar and registrant. I did not > invent those terms. Okay, maybe the business model isn't clear to me. As a VoIP provider, why on earth would I allow my registrar to negotiate which routes I want to accept from a peer? I need control over the routes I'm offering my peers and the routes I'm accepting from them. KJC2: Both use case already widely exist in the industry. Voip providers = sometimes are their own registrars, in which case the same company plays th= e role of registrar and registrant. Some other Voip providers sometimes de= legate the registrant role to another organization. >> 3) As discussed on today's call, we did have the "rarId" (registrar >> ID) in the protocol. It was an attribute of each object. However, >> as the final change to the protocol we removed it at the request of >> a couple of the work group participants because they felt it got in >> the way of the local policies that drive their local >> implementations of authentication and authorization. We all agreed >> to do this because we saw that it is not _strictly_ necessary to >> have the "rarId" data element exist within the context of the SPPP >> messages going between the client and the server. But it _is_ >> certainly necessary within the internal server side implementation >> DB to keep the ID of the registrar that created each object. > > If an audit query using SPPP needs to be able to tell us which > registrar added or updated a given object, then we need rarId. > > KJC: Audit Query? You're inventing new requirements. The protocol > is not designed for auditing. Auditing is a very high volume > activity that is best done via other means. That being said, I am > not apposed to adding the rarID back in. But the folks that wanted > it removed would need to agree to adding it back in. It all comes down to whether or not a registrant can have relations with multiple registrars. If not, then we can use a single table mapping registrant to registrar, and don't need to track registrar in the objects. If, however, there is a possibility that a single registrant can have records with multiple registrars, then we require a registrar ID in the object too. Even if the case where there is a single registrar per registrant, we require a table mapping registrant to registrar to be able to manage permissions at the registrar level on objects that are only identified in the schema by their registrant. In other words, if I understand you correctly, we authenticate and authorize exclusively based on the registrar's identity. That is, only registrars have Auth_ID. But records in the current database are keyed by registrant, not registrar. So there's currently no way to look at a record and decide whether a given registrar "owns" that record on behalf of the registrant, and consequently we have no way to decide whether the registrar should be allowed to modify (or even read) that record. > If we explicitly wish to preclude this function (which seems > intuitively obvious and needful to somebody like me with an ops > background) then we probably need to state explicitly that we've > left it out of the protocol, and give reasons why. Otherwise the ops > area people (who are admittedly less activist than in Randy Bush's > IESG-days) are going to give us grief. > > KJC: Huh? Auditing is not supported by EPP, or Netconf, or ..... Auditing is supported by the ability to query the data and see what is there, as well as by the ability to insert new data and observe state changes on the output. Clearly this can be done in SPPP, EPP, NetConf, whatever. The question is: which actors have the rights to do it, and what tools do they do it with? One doesn't necessarily have to do it. it through the provisioning front end. But if not for auditing, why do we have query methods instead of just add/update methods? With EPP I can, for example, do a "dig" on the final result and see what's there. KJC2: You can also use dig against an SPPP fed resolution server (or issue= a SIP query). I suppose in certain use cases, where the information from SPPP is eventually making its way into an ENUM presentation, that one could audit from that end. I'm accustomed to thinking of data in private ENUM as being unavailable, but I suppose the scenarios you have in mind require that the registrant be able to query the ENUM directly. The problem is that the final ENUM presentation is a rather complex calculation of destination groups, route groups, offers, answers, acceptances, etc. It could be very hard to debug from the output alone. It would be a lot easier if, as a registrant. I could just query the registry using SPPP (or something similar) and verify the inputs. KJC2: To see the resolution response from a resolution server that is feed= using SPPP the way is to do a dig or an SIP invite. -- Dean This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From kcartwright@tnsi.com Fri Aug 26 12:59:31 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8897A21F8C55 for ; Fri, 26 Aug 2011 12:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIY+Kmjsh3Z2 for ; Fri, 26 Aug 2011 12:59:31 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id DD62921F8C3A for ; Fri, 26 Aug 2011 12:59:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUAAD/6V06sEQfn/2dsb2JhbABDmEiQVYFAAQEFOj8MBAIBCBEEAQEBFggJBzIUCQgBAQQOBQjCPoNDDIIdYASkNg X-IronPort-AV: E=Sophos;i="4.68,286,1312153200"; d="scan'208";a="147507" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 26 Aug 2011 21:00:37 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Fri, 26 Aug 2011 16:01:26 -0400 From: "Cartwright, Ken" To: Dean Willis Date: Fri, 26 Aug 2011 16:01:25 -0400 Thread-Topic: [drinks] Policy vs. Protocol Thread-Index: AcxkJqqsiNm1EtxKT7G0Xpk9+kJkrwAAUGcw Message-ID: <754963199212404AB8E9CFCA6C3D0CDA38DDC748EC@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4E569811.3090503@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8CF82@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E56A625.4040104@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8D059@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E57235B.3030509@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8D174@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E57F467.5050505@softarmor.com> In-Reply-To: <4E57F467.5050505@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] Policy vs. Protocol X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 19:59:31 -0000 Given that there is also no "registrant name" in the XSD schema, I assume y= ou mean the registrant ID, the rantID data element. So I guess your questi= on is, "How does a registrars' authentication credentials (part of which wo= uld be what you call a 'user name') relate to the identifier of the registr= ants whose data it can manage?" The spec clearly makes no limitation that = there be a one-to-one correlation between the two (the spec would be in vio= lation of one of the use cases if it went out of its way to impose such a l= imitation), nor does it impose a limitation that some part of the registrar= authentication credentials somehow be the same as a rantID (which would no= t even make sense). As we've already discussed a couple times on the phone, the administrative = steps involved in setting up registrars' authentication credentials, and th= e list of registrants whose data that registrar is authorized to manage is = an out-of-band activity. This activity would then, in part, result in some= portion of a data store getting populated that contains that registrar's a= uthentication credentials and the list of registrants whose data that regis= trar is authorized to manage. Ken -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Friday, August 26, 2011 3:31 PM To: Cartwright, Ken Cc: drinks@ietf.org Subject: Re: [drinks] Policy vs. Protocol On 8/26/11 8:31 AM, Cartwright, Ken wrote: > Dean, there is no "registrar name" defined in the XSD schema. What are y= ou talking about? My bad. Maybe I should just say "rar" and "rant" instear of "registar" and "registrant". Let's try again: How does the user name returned by the digest authentication relate to the registrant name as specified in the XSD schema? Is it a one-to-one mapping? Is it a direct mapping? Do we assume that they are textually the same? If so, what rules for string-comparison are used to match one against the other? -- dean This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From dean.willis@softarmor.com Fri Aug 26 13:36:50 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1349021F8CA0 for ; Fri, 26 Aug 2011 13:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.761 X-Spam-Level: X-Spam-Status: No, score=-101.761 tagged_above=-999 required=5 tests=[AWL=-1.495, BAYES_00=-2.599, FB_IOW=3.333, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQ0kZu6TD5Tf for ; Fri, 26 Aug 2011 13:36:49 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1FC21F8C9F for ; Fri, 26 Aug 2011 13:36:48 -0700 (PDT) Received: by gyf3 with SMTP id 3so3704438gyf.31 for ; Fri, 26 Aug 2011 13:38:06 -0700 (PDT) Received: by 10.236.190.193 with SMTP id e41mr9488845yhn.118.1314391085846; Fri, 26 Aug 2011 13:38:05 -0700 (PDT) Received: from dwillis-mb1.local (cpe-66-25-15-110.tx.res.rr.com [66.25.15.110]) by mx.google.com with ESMTPS id j45sm2506779yhe.50.2011.08.26.13.38.04 (version=SSLv3 cipher=OTHER); Fri, 26 Aug 2011 13:38:05 -0700 (PDT) Message-ID: <4E58042C.60502@softarmor.com> Date: Fri, 26 Aug 2011 15:38:04 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "Cartwright, Ken" References: <754963199212404AB8E9CFCA6C3D0CDA38DDB8D179@TNS-MAIL-NA.win2k.corp.tnsi.com> <030401cc6400$968e2f60$c3aa8e20$@digitalshtick.com> <754963199212404AB8E9CFCA6C3D0CDA38DDC746C2@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA38DDC746C2@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "drinks@ietf.org" Subject: Re: [drinks] security considerations... X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 20:36:50 -0000 On 8/26/11 10:21 AM, Cartwright, Ken wrote: > Hi Jeremy, > > The protocol “musts” HTTPS and also “shoulds” certs based server and > client auth. Imo, the cert based server and client auth covers what you > refer to as “end-to-end message integrity”. Iow, if you have used the > cert to verify that the party on the other end is who you think they are > then it’s covered I believe. And anything more than that I do not see as > necessary (a “may” at best). Good points. As we know from RFC 3552, the key here is deciding what the credible threat model is, then effectively using techniques to block the credible threats. For example, is having a server CPU that has been designed by its manufacturer to leak our information a credible threat? Probably not. Is having somebody standing outside the office or in a switching junking sniffing our traffic a credible threat? Quite probably. The goal here is to think like an attacker, and figure out where in the system the weak parts are and how to attack them, to document those attacks, and then explain how to defend against them. We have "on the wire" interception threats, which (as Ken points out) are mostly handled by HTTPS. But our confidential records could "leak" at the back end. For example, if an intruder has access to the transaction log, they could find out what transactions we had sent. Of course, if they have access to the transaction log, they quite probably also have access to the server database, which would tell them a lot more. That's not something we can really defend against at the level of protocol we're using. At best, we can describe the risk (especially if there are any "special" risk factors to leaking our data) and remind implementor/users to apply appropriate measures to secure the back-end. How about an HTTPS MITM? Perhaps rar A connects to what it thinks is the registry, but is actually an attacker. If A is not careful about evaluation of the certificate presented by the registry, then A could be tricked into authenticating with the attacker. Digest is reasonably good but imperfect at keeping the attacker from deducing A's password, so the attacker might then be able to initiate transactions on behalf of rar A (and all A's rants) to the registry. Consequently, we probably need to talk about how A should evaluate the cert presented by the registry. I'm not an expert on the references here. IS the sequence in Section 3.1 of RFC 28218 adequate as a reference, or do we need more discussion? Note that RFC 4523 spends a lot of effort talking about certificate matching rules for LDAP, as RFC 5922 does for SIP. So it's not uncommon for an IETF spec to need more discussion on certificate matching. We have client-identity impersonation threats, which we're currently relying on the use of a simple password authentication scheme to control. We assume that the password is unlikely to be intercepted "on the wire" since it is being used over HTTPS. But what if it leaks from either the client or server sides through a back-end process? For example, as a client, I've left the password on a sticky-note attached to my monitor, and the cleaning staff transmits it to the competitor who has bribed them to send copies of all sticky-notes attached to monitors. Yes, we could use XML signing to make this harder, but we'd get the same benefit out of using a stronger authentication mechanism that uses a client-side cert. What about the threat model where a legitimate client crafts transactions designed to interfere with the operation of other clients? Assume we have rar A representing rant Alice. A protocol design or implementation error could easily let rar B inappropriately read, write, update, or insert faux records affecting rant Alice. One can also envision cases where a rant-to-rar interface outside the scope of this protocol might be used by a malicious rant to "trick" the rar into doing something inappropriate. For example, what happens when rant Bob sends rar B a batch of updates and accidentally refers to himself as rant Alice? B might then recklessly send those changes to the registry, adversely affecting Alice (if the registry allows rar B to affect records for rant Alice). Hopefully we defend against this by permission masking, or in RFC 3552 terms applying an access control list to the records of rant Alice that precludes rar B from altering them. But what if rants Alice and Bob are both legitimate clients of rar A? Our access list won't work. It becomes critical that A apply mechanisms, currently outside the control of SPPP, to verify that the transactions it submits on behalf of a rant affect only records relating to that rant. This is something we can't control at the SPPP level, but is a threat we can identify and warn the rars about. On a related note, is there a special threat to offer validation? Can Charlie offer routes to Alice that appear to be from her preferred partner Bob, but terminate on Charlie instead, thereby stealing revenue from Bob? Where there's a financial incentive, there's a lot of risk of an attack. So we need to identify areas where there's a strong financial incentive, and where possible, defend those points strongly. Do we need non-repudiation? Consider the case where rant Alice sends rar A some updates, and A dutifully pushes them into the registry using SPPP. These records are bad and they break something -- maybe Alice. Presume Alice then sues the registry operator for the resulting catastrophe. How does the registry (or the intervening rar) prove that the records came from Alice and not an administrative error or an attacker that was negligently admitted by the registry or the rar? Since at the very best our database shows that the transaction was authenticated to rar A (and that such authentication could be in-error), it's hard to prove that the fault was Alice's. We can't even ask Alice to XML-sign the incoming data, since she's using a non-SPPP interface to talk to A. A similar attack could be launched by rar A. If we had XML signatures by A on the records, then we could "prove" that A had submitted the erroneous data, not somebody else (for whom the registry is presumably responsible). Is this an important enough threat that we want to think about it in our protocol? If so, then we can't just say "use XML signatures". We'd have to talk about the certification process used to support the signatures. The same complexity applies to any more advanced authentication techniques. Does it make sense for rars to encrypt all data (XML Encryption) before submitting to the registry over HTTPS, such that the records are encrypted even in the database? Probably not, because then the registry would not be able to operate on the records to do things like matching route group offers. Nor would it be able to construct an ENUM presentation from the data. While it might be feasible for the registry to also have all the keys needed to decrypt the records, there's no real reason to presume that this will protect the back-end process. Since matching operations require decrypting the data, many logging operations are going to happen on decrypted data, and if an intruder has access into the database, there's no reason to assume the intruder couldn't also steal the decryption key(s). -- Dean From syed.ali@neustar.biz Fri Aug 26 14:14:46 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F17D521F8C3A for ; Fri, 26 Aug 2011 14:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sF--Owsp5Xrv for ; Fri, 26 Aug 2011 14:14:45 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8746F21F8B66 for ; Fri, 26 Aug 2011 14:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1314393344; x=1629749947; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=ASmC1chOPucbdCF440j0e mbziiPK0LWmF7hxUcGqTCc=; b=LucDabTbnzIK2KWVF+o114YAAwW0B/skrkm+t Eyl10Snu4SfYy0gyC/Mv8lZMgVo/aJFYhFv4VNCCHyEDKBghg== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id G6K7MJ1.26242637; Fri, 26 Aug 2011 17:15:43 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Fri, 26 Aug 2011 17:15:42 -0400 From: "Ali, Syed Wasim" To: Dean Willis Date: Fri, 26 Aug 2011 17:15:41 -0400 Thread-Topic: [drinks] security considerations... Thread-Index: AcxkNVAGKASzBQZoS3C+BaDL92sYug== Message-ID: In-Reply-To: <4E5726DD.4090704@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 4O0bkQWxlkJoAmhP20MBtQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] security considerations... X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 21:14:46 -0000 Dean, Thanks for the reply. Please, see comments inline. On 8/26/11 12:53 AM, "Dean Willis" wrote: >On 8/25/11 11:03 PM, Ali, Syed Wasim wrote: >> >> Hi, >> >> I am proposing addition of the following to the security considerations >> section. >> >> Thoughts? >> >> >>>>> >> For high visibility implementation, there may be additional concerns >> regarding repudiation issues and SPPP implementations may need to >> provide proof that the message did not change since leaving the sender >> and to further validate the sender of SPPP message. Therefore, the SPPP >> implementations SHOULD provide support for XML Signature standard to >> manage this concern. > >This further restricts protocol bindings to be XML-based instead of, for >example, RESTful. Given that we're already deeply tied to XML at the >"architecture" document that we're calling a protocol document (rather >than in a transport binding, where I would personally have preferred to >map to XML) I suppose this doesn't matter. But it is sort of running >salt into the wound. RESTful paradigm doesn't prohibit use of XML content. I don't understand your comment. XML Signature standard applies to XML content. And yes, SPPP relies on XML to describe the protocol structure. This is partly because we are trying to stay in line with current industry practices. This is not an add choice by any measure. Not sure what I mentioned here makes things worse than the status quo. For systems that cannot consume XML, there are ways to tackle this is a standards-based fashion. Granted that signing a message for integrity protection at the message level gets in the way of transformations, but that is a different discussion. > >Also needs a reference to the XML Signature standard. Yes. This would be part of the final edit. > >And most likely, to use XML Signature in an interoperable way, we're >going to need to talk a lot more about what is being signed, what it is >being signed with, and what the assumptions about key management are. The goal here was to clarify to the consumer of the SPPP document that if message integrity protection is desirable then the standards-based approach. RFC3552 section 2.1.2 recognizes that there is more to data integrity beyond the transport layer protection. And yes, when and if someone needs to exercise this requirement, they will "talk a lot more about" it.=20 > > >> It is not uncommon for the logging systems to document on-the-wire >> messages for various purposes, such as, debug, audit, and tracking. At >> the minimum, the various support a nd administration staff will have >> access to these logs. Also, if an unprivileged user gains access to the >> SPPP deployments and/or support systems, it will have access to the >> information that is potentially deemed confidential. To manage >> information disclosure concerns beyond the transport level, the SPPP >> implementations SHOULD support XML Encryption standard to facilitate >> information hiding at the message level. > >As above WRT XML-centric design. Also needs a reference to XML >Encryption standard. Yes, the reference to the XML Encryption standard is needed. > >And most likely, to use XML Encryption in an interoperable way, we're >going to need to talk a lot more about what is being encrypted, what it >is being encrypted with, and what the assumptions about key management >are. > > >> Anti-replay protection ensures that a given SPPP object is not played >> back at a later time and affect the integrity of the system. SPPP >> protocol provides at least two mechanisms to aid the implementers in >> this regard: client transaction identifier and embedded create The reference to the create and modify data in this context was incorrect. It serves an entirely different purpose and I shall rectify the text. -Syed > > From dean.willis@softarmor.com Fri Aug 26 16:29:08 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC2A21F8B5A for ; Fri, 26 Aug 2011 16:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.365 X-Spam-Level: X-Spam-Status: No, score=-103.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bF5GTz3c18pl for ; Fri, 26 Aug 2011 16:29:07 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id BBBDC21F8B55 for ; Fri, 26 Aug 2011 16:29:07 -0700 (PDT) Received: by yie12 with SMTP id 12so2368225yie.31 for ; Fri, 26 Aug 2011 16:30:24 -0700 (PDT) Received: by 10.91.176.16 with SMTP id d16mr1708953agp.122.1314401424179; Fri, 26 Aug 2011 16:30:24 -0700 (PDT) Received: from dwillis-mb1.local (cpe-66-25-15-110.tx.res.rr.com [66.25.15.110]) by mx.google.com with ESMTPS id p34sm2025109ann.43.2011.08.26.16.30.23 (version=SSLv3 cipher=OTHER); Fri, 26 Aug 2011 16:30:23 -0700 (PDT) Message-ID: <4E582C8E.3090202@softarmor.com> Date: Fri, 26 Aug 2011 18:30:22 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "Cartwright, Ken" References: <754963199212404AB8E9CFCA6C3D0CDA38DD5F2E9E@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E5651F2.2090307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8CDE8@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E56A264.50703@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8CFC5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E571FF3.1070308@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8D170@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E57F3A3.8010400@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDC748B8@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA38DDC748B8@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "drinks@ietf.org" Subject: Re: [drinks] Long Followup to Thoughts on "Organization" in draft-ietf-drinks-spprov-09 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 23:29:08 -0000 On 8/26/11 2:38 PM, Cartwright, Ken wrote: > Responses in-line (KJC2). > > -----Original Message----- From: Dean Willis > [mailto:dean.willis@softarmor.com] Sent: Friday, August 26, 2011 3:28 > PM To: Cartwright, Ken Cc: drinks@ietf.org Subject: Re: Long Followup > to Thoughts on "Organization" in draft-ietf-drinks-spprov-09 > > On 8/26/11 8:29 AM, Cartwright, Ken wrote: >> > >> Gee, until today it hadn't been apparent that the database needed >> to hold registrars. It wasn't in the spec as far as the developers >> could tell. It's not in the schema, and is mentioned only in the >> protocol docs (as far as I can tell) as something that's outside >> the scope of the protocol and left up to "policy". >> >> KJC: Then where do you store the authentication credentials? > > Don't have any yet. Since how it worked was not obvious from the > spec, we put that off to a future phase. > > KJC2: Dean that is not at all correct. The spec explicitly requires > Digest Authentication. It might require digest authentication but of what/who and using what credentials isn't in the spec. So we deferred that part of the implementation. >> Can a registrant have relationships with multiple registrars >> (many-many), or does the protocol lock that down to many-one? >> >> Don't registrants need to access data in the database so they can >> offer and accept routing information to/from each other? >> >> No. The registrar role does that. Dean, you need to read and >> understand the definitions of registrar and registrant. I did not >> invent those terms. > > Okay, maybe the business model isn't clear to me. > > As a VoIP provider, why on earth would I allow my registrar to > negotiate which routes I want to accept from a peer? I need control > over the routes I'm offering my peers and the routes I'm accepting > from them. > > KJC2: Both use case already widely exist in the industry. Voip > providers sometimes are their own registrars, in which case the same > company plays the role of registrar and registrant. Some other Voip > providers sometimes delegate the registrant role to another > organization. You mean delegate the registrar role, right? So registrars are the ones offering routs to each other and accepting routes from each other, not registrants? Seems backwards to me. ... > >> If we explicitly wish to preclude this function (which seems >> intuitively obvious and needful to somebody like me with an ops >> background) then we probably need to state explicitly that we've >> left it out of the protocol, and give reasons why. Otherwise the >> ops area people (who are admittedly less activist than in Randy >> Bush's IESG-days) are going to give us grief. >> >> KJC: Huh? Auditing is not supported by EPP, or Netconf, or ..... > > Auditing is supported by the ability to query the data and see what > is there, as well as by the ability to insert new data and observe > state changes on the output. Clearly this can be done in SPPP, EPP, > NetConf, whatever. The question is: which actors have the rights to > do it, and what tools do they do it with? > > One doesn't necessarily have to do it. it through the provisioning > front end. But if not for auditing, why do we have query methods > instead of just add/update methods? > > With EPP I can, for example, do a "dig" on the final result and see > what's there. > > KJC2: You can also use dig against an SPPP fed resolution server (or > issue a SIP query). > > I suppose in certain use cases, where the information from SPPP is > eventually making its way into an ENUM presentation, that one could > audit from that end. I'm accustomed to thinking of data in private > ENUM as being unavailable, but I suppose the scenarios you have in > mind require that the registrant be able to query the ENUM directly. > > The problem is that the final ENUM presentation is a rather complex > calculation of destination groups, route groups, offers, answers, > acceptances, etc. It could be very hard to debug from the output > alone. > > It would be a lot easier if, as a registrant. I could just query the > registry using SPPP (or something similar) and verify the inputs. > > KJC2: To see the resolution response from a resolution server that > is feed using SPPP the way is to do a dig or an SIP invite. A SIP INVITE doesn't normally return a database lookup. It doesn't tell me what routes I've offered to people, what routes I've been offered, or how my destinations are grouped up. In the "normal" case, it returns some SDP for setting up a media flow. Likewise, the expressive range of a "dig" lookup is much less than the expressive range of an SPPP request. From dean.willis@softarmor.com Fri Aug 26 16:44:11 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFAE21F8B7C for ; Fri, 26 Aug 2011 16:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.374 X-Spam-Level: X-Spam-Status: No, score=-103.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nU1dC34JHqul for ; Fri, 26 Aug 2011 16:44:10 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id BF16821F8B6B for ; Fri, 26 Aug 2011 16:44:10 -0700 (PDT) Received: by ywe9 with SMTP id 9so3810084ywe.31 for ; Fri, 26 Aug 2011 16:45:28 -0700 (PDT) Received: by 10.91.170.7 with SMTP id x7mr1743463ago.114.1314402327983; Fri, 26 Aug 2011 16:45:27 -0700 (PDT) Received: from dwillis-mb1.local (cpe-66-25-15-110.tx.res.rr.com [66.25.15.110]) by mx.google.com with ESMTPS id g17sm2039965ank.10.2011.08.26.16.45.27 (version=SSLv3 cipher=OTHER); Fri, 26 Aug 2011 16:45:27 -0700 (PDT) Message-ID: <4E583016.5070501@softarmor.com> Date: Fri, 26 Aug 2011 18:45:26 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "Ali, Syed Wasim" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "drinks@ietf.org" Subject: Re: [drinks] security considerations... X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 23:44:11 -0000 On 8/26/11 4:15 PM, Ali, Syed Wasim wrote: > > Dean, > > Thanks for the reply. Please, see comments inline. > > > > On 8/26/11 12:53 AM, "Dean Willis" wrote: > >> On 8/25/11 11:03 PM, Ali, Syed Wasim wrote: >>> >>> Hi, >>> >>> I am proposing addition of the following to the security considerations >>> section. >>> >>> Thoughts? >>> >>> >>>>> >>> For high visibility implementation, there may be additional concerns >>> regarding repudiation issues and SPPP implementations may need to >>> provide proof that the message did not change since leaving the sender >>> and to further validate the sender of SPPP message. Therefore, the SPPP >>> implementations SHOULD provide support for XML Signature standard to >>> manage this concern. >> >> This further restricts protocol bindings to be XML-based instead of, for >> example, RESTful. Given that we're already deeply tied to XML at the >> "architecture" document that we're calling a protocol document (rather >> than in a transport binding, where I would personally have preferred to >> map to XML) I suppose this doesn't matter. But it is sort of running >> salt into the wound. > > RESTful paradigm doesn't prohibit use of XML content. I don't understand > your comment. REST uses the URL to indicate the service being performed, and generally splits the parameters (which might be XML) up into separate URL parameters or form-values in the request. Our XML encoding wraps the service designator and everything else into one XML document that then has to be parsed at the receiving end. This makes it very hard to explicitly map the protocol onto a RESTful model. Even relying on HTTP Auth as part of our resource identification is un-RESTful. SO the registrar identifier should be one of the parameters, not something we get from the auth layer. But Ken is telling me that the registar identifier is completely out-of-scope for the protocol. XML signing/encrypting the whole submitted document in one block makes it even further distant from REST. -- Dean From alexander.mayrhofer@nic.at Mon Aug 29 04:15:33 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9793521F874B for ; Mon, 29 Aug 2011 04:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.679 X-Spam-Level: X-Spam-Status: No, score=-8.679 tagged_above=-999 required=5 tests=[AWL=-0.738, BAYES_05=-1.11, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btrSOTUxx5c6 for ; Mon, 29 Aug 2011 04:15:32 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 1583D21F8B0D for ; Mon, 29 Aug 2011 04:15:31 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47 ; Mon, 29 Aug 2011 13:16:53 +0200 Received: from nics-mail.sbg.nic.at (10.17.175.2) by NICS-EXCH.sbg.nic.at (10.17.175.3) with Microsoft SMTP Server id 14.1.218.12; Mon, 29 Aug 2011 13:16:51 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 29 Aug 2011 13:16:43 +0200 Message-ID: <8BC845943058D844ABFC73D2220D46650AC3832B@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: on data validation... Thread-Index: AcxmMw3r8FwzikkYTuibmLYviZ0gkQ== From: Alexander Mayrhofer To: X-XWALL-BCKS: auto Subject: [drinks] on data validation... X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 11:15:33 -0000 The concerns about the "unconstrained" elements were raised a long time ago, and i admit it was a TODO on me that i never delivered - so let's hope it's still useful now: In preperation for the virtual interim, i've looked through the formal schema specification of SPPP, checking which elements should have more reasonable constraints added (compared to the current "everything goes" policy). I've also found a few other things (listed below). We have currently very little constraints on the various fields, which means that a client could theoretically use a 8GB long blob of unprintable unicode character codepoints as an object identifier. This would obviously lead to a lot of problems, and hence (as indicated by Dean and his developers), some constraints are required for interopability. Similar protocols in the IETF (most notably, EPP), have limited such identifiers in a similar way and are deployed in a broad fashion. Quantitative and qualitative limitations help interopability (i'd even go that far to say that protocols with no such limitations have unknown interopability, because any test cannot be exhaustive). Object Names ------------------ - I think that the various "names" and "keys" are the most important ones to apply constraints on, since they are used as references between objects, and used in comparison / lookup operations. Therefore, i suggest to change the definition of ObjNameType from the current to the following definition (note that the upper and lower limits are arbitrary - anybody willing to offer a reasoning from practice? Also, more on "string" vs. "token" base type below) This affects, from what i can see, the following elements: - dgName - rrName - egrRteName - rgName Transaction IDs ------------------ In a similar way, we should also restrict Transaction IDs. Those are currently very "open" as well, and have the following definition: I do suggest to change those to: (note: I've seen that transaction ids tend to get longer than object identifiers, so i extended my arbitrar length restrictions from the ObjNameType above). This restriction would affect the following elements: - clientTransId - serverTransId Restrictions on E.164-derived elements ------------------------------------------------ The instances of the abstract public identifier object contain elements that are derived from E.164 numbers. Since those are a namespace that is very well defined and constrained, we should also look into constraining the derived elements in SPPP. I do hence suggest to change the definition of=20 - tn - rn - startTN - endTN - tnPrefix (all of them are currently defined as "string" with no additional length constraints) to a specific Type (eg. "e164DerivedType"?). For definitions, one option is to use the definition from RFC5105: However, i do understand that E.164 numbers can also use hexadecimal characters "a-f", and hence the above definition would not allow those? I haven't taken up the effort of checkign against E.164, but i'm sure there are more knowledgeable people on the list... Any advice? Organizations ---------------- Identifier of organizations are currently unrestricted as well. The respective XML Schema definition is as follows: I understand that since the namespace for those organizations will probably come out of the GSPID work, or use some existing namespace, but i think it will definitely need to be constrained (for the reasons outlined above). Base Type "string" vs "token" ------------------------------------ comparing the XML Schema definitions for "string" (base type) vs. "token" base type, i'm pretty sure that we want all elements in our protocol that contain textual contents to derive from the "token" base type. The difference is that "string" base types allow for line feeds, carriage returns, etc. Whitespace is significant.=20 On the other hand, the "token" basetype does not allow for carriage return, line feed, tab, leading and trailing spaces.=20 http://www.w3.org/TR/xmlschema-2/#token I cannot think of a case where we would need to consider those characters in an element, and hence suggest that we change all "string" base types in SPPP to "token". Anybody aware of an element where we should make an exception from that rule? (Disclaimer: I'm not a XML expert, though!) NAPTR -------- RFC 4114 contains an "IESG-tested" schema definition for the contents of a NAPTR record. We should probably re-use that, instead of creating a new definition: http://tools.ietf.org/html/rfc4114#section-4 Format of Nameservers / IP addresses ----------------------------------------------- The same applies to the definition of IP addresses and nameserver names, those could be copied over from the respective EPP specifications in RFC5731 (and adapted slightly, as needed). The definition for IP addresses there is: Again, this would have the advantage that we use an IESG-approved definition from an existing RFC. URIs ------ Note that XML Schema contains a base type for URIs. we could use that one eg. for tghe definition of the "uri" element in the "URIType": http://www.w3.org/TR/xmlschema-2/#anyURI (plus, i'm sure we want that field, like other fields that contain URIs, limit to absolute URIs, because we don't have a definition what the base for a relative URI would be - i think that can only be done in text, though - not in Schema). (However, given that the "uri" element can contain backreferences, the base type "URI" would probably not be appropriate, because it's not an actual URI?) I hope we can use that information above as a basis to discuss data validation during the interim meeting - if someone comes up with different ideas, please share on the list! Alex From kcartwright@tnsi.com Mon Aug 29 06:21:06 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3C521F855F for ; Mon, 29 Aug 2011 06:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmOSD4YRWjNa for ; Mon, 29 Aug 2011 06:21:05 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id E2DA321F88B6 for ; Mon, 29 Aug 2011 06:20:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwAAACRW06sEQfn/2dsb2JhbABCmCeQT4FAAQEEATo4BwUHBAIBCBEEAQEBHgkHMhQJCAEBBA4FCIdquGSFbGAEpD8 X-IronPort-AV: E=Sophos;i="4.68,296,1312153200"; d="scan'208";a="153902" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 29 Aug 2011 14:22:21 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 29 Aug 2011 09:22:21 -0400 From: "Cartwright, Ken" To: Dean Willis Date: Mon, 29 Aug 2011 09:23:04 -0400 Thread-Topic: Long Followup to Thoughts on "Organization" in draft-ietf-drinks-spprov-09 Thread-Index: AcxkSCKxdZ4u27Y+Qvy7Um7f1r13+ACBWNGg Message-ID: <754963199212404AB8E9CFCA6C3D0CDA38DDC74B29@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <754963199212404AB8E9CFCA6C3D0CDA38DD5F2E9E@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E5651F2.2090307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8CDE8@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E56A264.50703@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8CFC5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E571FF3.1070308@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8D170@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E57F3A3.8010400@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDC748B8@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E582C8E.3090202@softarmor.com> In-Reply-To: <4E582C8E.3090202@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] Long Followup to Thoughts on "Organization" in draft-ietf-drinks-spprov-09 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 13:21:06 -0000 In-line KJC3. Ken -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Friday, August 26, 2011 7:30 PM To: Cartwright, Ken Cc: drinks@ietf.org Subject: Re: Long Followup to Thoughts on "Organization" in draft-ietf-drin= ks-spprov-09 On 8/26/11 2:38 PM, Cartwright, Ken wrote: > Responses in-line (KJC2). > > -----Original Message----- From: Dean Willis > [mailto:dean.willis@softarmor.com] Sent: Friday, August 26, 2011 3:28 > PM To: Cartwright, Ken Cc: drinks@ietf.org Subject: Re: Long Followup > to Thoughts on "Organization" in draft-ietf-drinks-spprov-09 > > On 8/26/11 8:29 AM, Cartwright, Ken wrote: >> > >> Gee, until today it hadn't been apparent that the database needed >> to hold registrars. It wasn't in the spec as far as the developers >> could tell. It's not in the schema, and is mentioned only in the >> protocol docs (as far as I can tell) as something that's outside >> the scope of the protocol and left up to "policy". >> >> KJC: Then where do you store the authentication credentials? > > Don't have any yet. Since how it worked was not obvious from the > spec, we put that off to a future phase. > > KJC2: Dean that is not at all correct. The spec explicitly requires > Digest Authentication. It might require digest authentication but of what/who and using what credentials isn't in the spec. So we deferred that part of the implementation. KJC3: (1) Not sure I agree with that. The spec says that the clients of t= he SPPP/SOAP/HTTPS must use digest authentication. (2) The IETF RFCs that I= 've read do not go to the extent of explaining how implementers of a protoc= ol that must use digest authentication will do Digest Authentication. But = if there is some specific statement you would like me to add I will do so. >> Can a registrant have relationships with multiple registrars >> (many-many), or does the protocol lock that down to many-one? >> >> Don't registrants need to access data in the database so they can >> offer and accept routing information to/from each other? >> >> No. The registrar role does that. Dean, you need to read and >> understand the definitions of registrar and registrant. I did not >> invent those terms. > > Okay, maybe the business model isn't clear to me. > > As a VoIP provider, why on earth would I allow my registrar to > negotiate which routes I want to accept from a peer? I need control > over the routes I'm offering my peers and the routes I'm accepting > from them. > > KJC2: Both use case already widely exist in the industry. Voip > providers sometimes are their own registrars, in which case the same > company plays the role of registrar and registrant. Some other Voip > providers sometimes delegate the registrant role to another > organization. You mean delegate the registrar role, right? KJC3: Yes So registrars are the ones offering routs to each other and accepting routes from each other, not registrants? Seems backwards to me. KJC3: As has been explained, registrars take action on behalf of the regis= trants. Not backwards at all. ... > >> If we explicitly wish to preclude this function (which seems >> intuitively obvious and needful to somebody like me with an ops >> background) then we probably need to state explicitly that we've >> left it out of the protocol, and give reasons why. Otherwise the >> ops area people (who are admittedly less activist than in Randy >> Bush's IESG-days) are going to give us grief. >> >> KJC: Huh? Auditing is not supported by EPP, or Netconf, or ..... > > Auditing is supported by the ability to query the data and see what > is there, as well as by the ability to insert new data and observe > state changes on the output. Clearly this can be done in SPPP, EPP, > NetConf, whatever. The question is: which actors have the rights to > do it, and what tools do they do it with? > > One doesn't necessarily have to do it. it through the provisioning > front end. But if not for auditing, why do we have query methods > instead of just add/update methods? > > With EPP I can, for example, do a "dig" on the final result and see > what's there. > > KJC2: You can also use dig against an SPPP fed resolution server (or > issue a SIP query). > > I suppose in certain use cases, where the information from SPPP is > eventually making its way into an ENUM presentation, that one could > audit from that end. I'm accustomed to thinking of data in private > ENUM as being unavailable, but I suppose the scenarios you have in > mind require that the registrant be able to query the ENUM directly. > > The problem is that the final ENUM presentation is a rather complex > calculation of destination groups, route groups, offers, answers, > acceptances, etc. It could be very hard to debug from the output > alone. > > It would be a lot easier if, as a registrant. I could just query the > registry using SPPP (or something similar) and verify the inputs. > > KJC2: To see the resolution response from a resolution server that > is feed using SPPP the way is to do a dig or an SIP invite. A SIP INVITE doesn't normally return a database lookup. KJC3: That's simply incorrect. The SIP response is built from a lookup in= to a DB, be it in memory on on disk. It doesn't tell me what routes I've offered to people, what routes I've been offered, or how my destinations are grouped up. In the "normal" case, it returns some SDP for setting up a media flow. KJC3: There are several detailed use case around how SIP response are cons= tructed from an underlying set of data, and what the resulting SIP response= might be. You brought up using dig if te protocol id ENUM, so I offered u= p the additional use of SIP. ENUM and SIP are analogous here. Neither of = these protocols will tell you all of the data that was _evaluated_ when arr= iving at the final ENUM or SIP response. Likewise, the expressive range of a "dig" lookup is much less than the expressive range of an SPPP request. KJC3: OF course. You brought up dig, not me. This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From kcartwright@tnsi.com Mon Aug 29 06:28:28 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E92A121F8B36 for ; Mon, 29 Aug 2011 06:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuzjiiRLP55E for ; Mon, 29 Aug 2011 06:28:28 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3C03E21F8B35 for ; Mon, 29 Aug 2011 06:28:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwAAFOTW06sEQfn/2dsb2JhbAA5CZgnkE+BQAEBAQEDAQEBNzQLDAQCAQgRAQMBAQEeCQcnCxQDBggBAQQOBQiHbrhVgymCQ2AEpD8 X-IronPort-AV: E=Sophos;i="4.68,296,1312153200"; d="scan'208";a="153948" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 29 Aug 2011 14:29:51 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 29 Aug 2011 09:29:51 -0400 From: "Cartwright, Ken" To: Dean Willis , "Ali, Syed Wasim" Date: Mon, 29 Aug 2011 09:30:34 -0400 Thread-Topic: [drinks] security considerations... Thread-Index: AcxkSj7ZsQmQAYINTqycvAG4dj1VFQCBJuIg Message-ID: <754963199212404AB8E9CFCA6C3D0CDA38DDC74B42@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4E583016.5070501@softarmor.com> In-Reply-To: <4E583016.5070501@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] security considerations... X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 13:28:29 -0000 Inline. -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Dean Willis Sent: Friday, August 26, 2011 7:45 PM To: Ali, Syed Wasim Cc: drinks@ietf.org Subject: Re: [drinks] security considerations... On 8/26/11 4:15 PM, Ali, Syed Wasim wrote: > > Dean, > > Thanks for the reply. Please, see comments inline. > > > > On 8/26/11 12:53 AM, "Dean Willis" wrote: > >> On 8/25/11 11:03 PM, Ali, Syed Wasim wrote: >>> >>> Hi, >>> >>> I am proposing addition of the following to the security considerations >>> section. >>> >>> Thoughts? >>> >>> >>>>> >>> For high visibility implementation, there may be additional concerns >>> regarding repudiation issues and SPPP implementations may need to >>> provide proof that the message did not change since leaving the sender >>> and to further validate the sender of SPPP message. Therefore, the SPPP >>> implementations SHOULD provide support for XML Signature standard to >>> manage this concern. >> >> This further restricts protocol bindings to be XML-based instead of, for >> example, RESTful. Given that we're already deeply tied to XML at the >> "architecture" document that we're calling a protocol document (rather >> than in a transport binding, where I would personally have preferred to >> map to XML) I suppose this doesn't matter. But it is sort of running >> salt into the wound. > > RESTful paradigm doesn't prohibit use of XML content. I don't understand > your comment. REST uses the URL to indicate the service being performed, and generally splits the parameters (which might be XML) up into separate URL parameters or form-values in the request. Our XML encoding wraps the service designator and everything else into one XML document that then has to be parsed at the receiving end. This makes it very hard to explicitly map the protocol onto a RESTful model. KJC: Absolutely, which is part of what I presented in Sweden. Even relying on HTTP Auth as part of our resource identification is un-RESTful. SO the registrar identifier should be one of the parameters, not something we get from the auth layer. But Ken is telling me that the registar identifier is completely out-of-scope for the protocol. KJC: You exaggerate. What I said was that two of the parties involved in = specifying the protocol wanted to remove the registrar ID from the protocol= XSD objects, as the last change to the protocol XSD. And because having t= he registrar ID in there was not strictly necessary I agreed to that change= as well. And I also told you that in order to add it back we would need t= o get those parties to agree to do so. But just to prevent thrashing, addi= ng it back in would require a very solid justification at this point. Furt= hermore I explained that the identity of the registrar is now effectively e= mbedded within (i.e. determined from) authentication credentials. XML signing/encrypting the whole submitted document in one block makes it even further distant from REST. -- Dean _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From syed.ali@neustar.biz Mon Aug 29 09:21:14 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1CD21F8876 for ; Mon, 29 Aug 2011 09:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zpo2XnoQ3mLt for ; Mon, 29 Aug 2011 09:21:14 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id CAEFD21F8834 for ; Mon, 29 Aug 2011 09:21:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1314634957; x=1629988489; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=mxht6tBrn2ij7MkY4iuZB C7zmXcaTCAmf3WfnuW7smA=; b=l/uU7+HHXqL15lDzl9CBBlheELwTpMk1JwdxZ PtKstyzL91RrbOfqD0xrwcEf3zv6uRHAYe9KOJZfpgl+wgB8A== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id 5202415.40702145; Mon, 29 Aug 2011 12:22:36 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Mon, 29 Aug 2011 12:22:35 -0400 From: "Ali, Syed Wasim" To: Dean Willis Date: Mon, 29 Aug 2011 12:22:33 -0400 Thread-Topic: [drinks] security considerations... Thread-Index: AcxmZ9xdgdn8HMVNTcuC1nSdX6s22A== Message-ID: In-Reply-To: <4E583016.5070501@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: JJovfFy7fs+HSScAeyFWqg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] security considerations... X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 16:21:14 -0000 Please see inline: On 8/26/11 7:45 PM, "Dean Willis" wrote: >On 8/26/11 4:15 PM, Ali, Syed Wasim wrote: >> >> Dean, >> >> Thanks for the reply. Please, see comments inline. >> >> >> >> On 8/26/11 12:53 AM, "Dean Willis" wrote: >> >>> On 8/25/11 11:03 PM, Ali, Syed Wasim wrote: >>>> >>>> Hi, >>>> >>>> I am proposing addition of the following to the security >>>>considerations >>>> section. >>>> >>>> Thoughts? >>>> >>>> >>>>> >>>> For high visibility implementation, there may be additional concerns >>>> regarding repudiation issues and SPPP implementations may need to >>>> provide proof that the message did not change since leaving the sender >>>> and to further validate the sender of SPPP message. Therefore, the >>>>SPPP >>>> implementations SHOULD provide support for XML Signature standard to >>>> manage this concern. >>> >>> This further restricts protocol bindings to be XML-based instead of, >>>for >>> example, RESTful. Given that we're already deeply tied to XML at the >>> "architecture" document that we're calling a protocol document (rather >>> than in a transport binding, where I would personally have preferred to >>> map to XML) I suppose this doesn't matter. But it is sort of running >>> salt into the wound. >> >> RESTful paradigm doesn't prohibit use of XML content. I don't understand >> your comment. > >REST uses the URL to indicate the service being performed, and generally >splits the parameters (which might be XML) up into separate URL >parameters or form-values in the request. Our XML encoding wraps the >service designator and everything else into one XML document that then >has to be parsed at the receiving end. This makes it very hard to >explicitly map the protocol onto a RESTful model. We discussed RESTful or "not" before. In fact, we can do SOAP wrapper or REST, not both. This has been addressed before... > >Even relying on HTTP Auth as part of our resource identification is >un-RESTful. SO the registrar identifier should be one of the parameters, >not something we get from the auth layer. But Ken is telling me that the >registar identifier is completely out-of-scope for the protocol. See earlier comment. Since RESTful doesn't apply in the SPPP document, this comment is irrelevant at best. This discussion is out of scope unless there is a requirement to ditch SOAP and do REST. Also, you probably mean "registrant" and not "registrar". The resource belongs to registrant, not the registrar. > >XML signing/encrypting the whole submitted document in one block makes >it even further distant from REST. > >-- >Dean From syed.ali@neustar.biz Mon Aug 29 10:37:06 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EFB21F8B5C for ; Mon, 29 Aug 2011 10:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23hz1OgSu6ww for ; Mon, 29 Aug 2011 10:37:04 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 33B3521F8AD9 for ; Mon, 29 Aug 2011 10:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1314639508; x=1629986688; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=pOFidN9QZGFfvu/j2c6rOYLhrHJF5/k3ppHcGwu7zaI=; b=IVufScmbXanVaNZzE4x7QByxjfOCrF0mu7WygYwcgkzohiU8WBUcPHKUhlxIp2 hjtxdO5dktJnDzkhYozG4qxA== Received: from ([10.31.13.242]) by chihiron1.nc.neustar.com with ESMTP with TLS id 5202942.42456090; Mon, 29 Aug 2011 13:38:27 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Mon, 29 Aug 2011 13:38:26 -0400 From: "Ali, Syed Wasim" To: "Cartwright, Ken" , "drinks@ietf.org" Date: Mon, 29 Aug 2011 13:38:22 -0400 Thread-Topic: security considerations... Thread-Index: AcxmcnURjtVwEfRRTy+u4eKhz+XOiQ== Message-ID: In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA38DDB8D179@TNS-MAIL-NA.win2k.corp.tnsi.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 5d4Y1QLRJGxQInqsTqHZ/w== Content-Type: multipart/alternative; boundary="_000_CA7D8646147F8syedalineustarbiz_" MIME-Version: 1.0 Subject: Re: [drinks] security considerations... X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 17:37:06 -0000 --_000_CA7D8646147F8syedalineustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Ken, Thanks for the feedback. Please see comments inline: From: "Cartwright, Ken" > Date: Fri, 26 Aug 2011 09:34:09 -0400 To: Neustar >, "drinks@ie= tf.org" > Subject: RE: security considerations... Hi Syed, Thanks for this. A few comments. 1) I think the new items are the last three of the six paragraphs in Securi= ty considerations. [SYED] Yes. 2) For paragraph 4, I think this "should" could be changed to a "may". SSL= and certs address the "not been tampered with" and "the source is known to= be who they say they are" requirements. XML signatures are more appropria= te for environments where SSL and certs are not being used. [SYED] You are right, SSL addresses end to end connection security. I am no= t sure if the last statement is correct. There are protocols that not only = use both, but may use multiple signatures within a message (top level messa= ge integrity + embedded token protection that gets stored in the backend an= d may be passed on to other actors=97see SAML). Repudiation is required whe= n there is a concern that the sender may refuse to take ownership of the tr= ansaction, often much later in time. As an example, the plain text message = is not enough to demonstrate proof of transaction during the billing and se= ttlement phase since there is not enough proof that it hasn't changed since= it was received over supposedly a mTLS connection. This may not be an issu= e for all SPPP implementations, but this situation begs clarification. Also= , I am fine with a change from "SHOULD" to "MAY". 3) For paragraph 5, this seems to be development guidance for how implement= ers can keep their internally managed data secure (after it has gotten into= their systems). I don=92t really see what this has to do with this protoc= ol. We should not be attempting to explain how to do that because the requ= irements for that will vary from deployment to deployment. And even the us= e of XML encryption does not solve this problem. And this paragraph is not= enough to enable the use of XML Encryption in this protocol. It does not = even have a reference to the XML Encryption spec. Lastly, the data managed= by this protocol is not highly secret (i.e. there are no CCs, SSNs, person= 's names, company names, etc, etc). At a minimum the "should" should be ma= de a "may". [SYED] Here the intent is to follow RFC3552: "to encourage document authors= to consider security in their designs and to inform the reader of relevant= security issues". This may not be an issue for all implementations, but de= serves mention for complete coverage. I mentioned the standards-based choic= es in the text and will include the reference in the document edits. And ye= s, "SHOULD" can be changed to "MAY". 4) I'm not sure I see a meaningful risk here related to replays (aka idempo= tence). A repeat of an "add" will not add the object twice, so it will do = no harm. A repeat of a delete will do no harm. A repeat of a mod will do = no harm. A repeat of a route offer will do no harm. [SYED] (1) In the sequence that you mentioned here, there may not be an iss= ue, but a delayed replay of a message could have unintended results. Let's = see how the use of "clientTransId" helps in this regard. Registrar sends th= e AddDestGrpRqstType request and deliberately includes a "clientTransId" va= lue of "txid-1342134-1324-34" in the request. The correct response from the= server will include same "clientTransId" and helps bring closure to this t= ransaction. Any future replay of the SPPP server response will be harmless = if the client is not reusing the transaction id and is actively testing the= value to weed out bad messages. If the "clientTransId" is not included in = the original client request, and it doesn't have to be since it is optional= , a response such as, tx_id_12346 1000 success can be construed as a valid response to the original request when this coul= d very well be a replay of a message that was intercepted by a malicious us= er earlier, and not the conclusive response for the request from SPPP serve= r. For more on the replay attacks, please see RFC3552: 3.3.1. This is not a= ll that hard to imagine since the mTLS session is between two end points wh= en in fact a SSL proxy may be in play to perform mTLS handshake creating an= illusion of a "secure" environment. Now, this may appear far fetched to so= me, then again, the proposed text is there for the "security considerations= " section and helps the consumers of SPPP get the full picture. As a result, I'm not sure what is meant by " The Timestamps in the modify S= PPP objects that reflect the time it was created MUST reflect the current t= ime and the SPPP implementations SHOULD test the time values to make sure t= hat they are not replayed inadvertently, or with a malicious intent." [SYED] Right. I was recalling things on top of my head and confused the mat= ters with a couple of other things I am actively engaged in. This text shou= ld be discarded. ________________________________ From: drinks-bounces@ietf.org [mailto:drink= s-bounces@ietf.org] On Behalf Of Ali, Syed Wasim Sent: Friday, August 26, 2011 12:04 AM To: drinks@ietf.org Subject: [drinks] security considerations... Hi, I am proposing addition of the following to the security considerations sec= tion. Thoughts? >>>>> For high visibility implementation, there may be additional concerns regard= ing repudiation issues and SPPP implementations may need to provide proof t= hat the message did not change since leaving the sender and to further vali= date the sender of SPPP message. Therefore, the SPPP implementations SHOULD= provide support for XML Signature standard to manage this concern. It is not uncommon for the logging systems to document on-the-wire messages= for various purposes, such as, debug, audit, and tracking. At the minimum,= the various support and administration staff will have access to these log= s. Also, if an unprivileged user gains access to the SPPP deployments and/o= r support systems, it will have access to the information that is potential= ly deemed confidential. To manage information disclosure concerns beyond th= e transport level, the SPPP implementations SHOULD support XML Encryption s= tandard to facilitate information hiding at the message level. Anti-replay protection ensures that a given SPPP object is not played back = at a later time and affect the integrity of the system. SPPP protocol provi= des at least two mechanisms to aid the implementers in this regard: client = transaction identifier and embedded create timestamps for the SPPP objects.= The client transaction identifier allows the sender to correlate the respo= nse with the request and verify that the transaction was returned from the = intended SPPP implementation. The timestamps in the modify SPPP objects tha= t reflect the time it was created MUST reflect the current time and the SPP= P implementations SHOULD test the time values to make sure that they are no= t replayed inadvertently, or with a malicious intent. <<<<< Thanks, -Syed -Syed ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_CA7D8646147F8syedalineustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

=
Hi Ken,

T= hanks for the feedback. Please see comments inline:

<= /div>

F= rom: "Cartwright, Ken" <kcartwright@tnsi.com>
= Date: Fri, 26 Aug 2011 09:34:09 -0400
To: Neustar <syed= .ali@neustar.biz>, "drinks@i= etf.org" <drinks@ietf.org>
Subject: RE: security con= siderations...

Hi Syed,

 <= /span>

Thanks for this.  A few comments.

 

1) I think the new ite= ms are the last three of the six paragraphs in Security considerations.


2) For paragraph 4, I th= ink this "should" could be changed to a "may".  SS= L and certs address the "not been tampered with" and "the source is known to be who they say they are"= requirements.  XML signatures are more appropriate for environments w= here SSL and certs are not being used.

[SYED] You are right, SSL addresses end= to end connection security. I am not sure if the last statement is correct= . There are protocols that not only use both, but may use multiple signatur= es within a message (top level message integrity + embedded token prote= ction that gets stored in the backend and may be passed on to other actors= =97see SAML). Repudiation is required when there is a concern that the send= er may refuse to take ownership of the transaction, often much later in tim= e. As an example, the plain text message is not enough to demonstrate proof= of transaction during the billing and settlement phase since there is not = enough proof that it hasn't changed since it was received over supposedly a= mTLS connection. This may not be an issue for all SPPP implementations, bu= t this situation begs clarification. Also, I am fine with a change fro= m "SHOULD" to "MAY".

3) For paragraph 5, this= seems to be development guidance for how implementers can keep their inter= nally managed data secure (after it has gotten into their systems).  I don=92t really se= e what this has to do with this protocol.  We should not be attempting= to explain how to do that because the requirements for that will vary from= deployment to deployment.  And even the use of XML encryption does not solve this problem.  And this paragraph is= not enough to enable the use of XML Encryption in this protocol.  It = does not even have a reference to the XML Encryption spec.  Lastly, th= e data managed by this protocol is not highly secret (i.e. there are no CCs, SSNs, person's names, company names, etc, etc).&nb= sp; At a minimum the "should" should be made a "may".

[SYE= D] Here the intent is to follow RFC3552: "to encourage document author= s to consider security in their designs and to inform the reader of relevan= t security issues". This may not be an issue for all implementations, = but deserves mention for complete coverage. I mentioned the standards-based= choices in the text and will include the reference in the document edits. = And yes, "SHOULD" can be changed to "MAY". 
<= div style=3D"color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-si= ze: 14px; ">

4) I'm not sure I see a = meaningful risk here related to replays (aka idempotence).  A repeat o= f an "add" will not add the object twice, so it will do no harm.  A repeat of a delete will d= o no harm.  A repeat of a mod will do no harm.  A repeat of a rou= te offer will do no harm. 

[SYED] (1) In the sequence that you mentioned= here, there may not be an issue, but a delayed replay of a message could h= ave unintended results. Let's see how the use of "clientTransId" = helps in this regard. Registrar sends the AddDestGrpRqstType request and de= liberately includes a "clientTransId" value of "txid-1342134= -1324-34" in the request. The correct response from the server will in= clude same "clientTransId" and helps bring closure to this transa= ction. Any future replay of the SPPP server response will be harmless if th= e client is not reusing the transaction id and is actively testing the valu= e to weed out bad messages. If the "clientTransId" is not include= d in the original client request, and it doesn't have to be since it is opt= ional, a response such as,

      <=
?xml version=3D"1.0" encoding=3D"UTF-8"?>
      <spppUpdateResponse
       xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation=3D"urn:ietf:params:xml:ns:sppp:base:1 sppp.x=
sd"
       xmlns=3D"urn:ietf:params:xml:ns:sppp:base:1">
        <serverTransId>tx_id_12346</serverTransId>
        <overallResult>
          <code>1000</code>
          <msg>success</msg>
        </overallResult>
      </spppUpdateResponse>

=
can be construed as a valid response to the original request w= hen this could very well be a replay of a message that was intercepted by a= malicious user earlier, and not the conclusive response for the request fr= om SPPP server. For more on the replay attacks, please see RFC3552: 3.3.1. = This is not all that hard to imagine since the mTLS session is between two = end points when in fact a SSL proxy may be in play to perform mTLS handshak= e creating an illusion of a "secure" environment. Now, this may a= ppear far fetched to some, then again, the proposed text is there for the &= quot;security considerations" section and helps the consumers of SPPP = get the full picture.

As a result, I'= m not sure what is meant by " The Timestamps in the modify SPPP object= s that reflect the time it was created MUST reflect the current time and the SPPP impleme= ntations SHOULD test the time values to make sure that they are not replaye= d inadvertently, or with a malicious intent."=

[SYED] Right. I was recallin= g things on top of my head and confused the matters with a couple of other = things I am actively engaged in. This text should be discarded.

<= p class=3D"MsoNormal" style=3D"color: rgb(0, 0, 0); font-family: Calibri, s= ans-serif; font-size: 14px; "> 

=

From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Ali, Syed Wasim
Sent: Friday, August 26, 2011 12:04 AM
To: drinks@ietf.org
Subject: [drinks] security consider= ations...

=  

 

Hi,

&nbs= p;

I am proposing addition of the following t= o the security considerations section. 

 

Thoughts?<= /font>

 

>>>>= ;> 

For high visibility i= mplementation, there may be additional concerns regarding repudiation issue= s and SPPP implementations may need to provide proof that the message did not change since leaving the sender = and to further validate the sender of SPPP message. Therefore, the SPPP imp= lementations SHOULD provide support for XML Signature standard to manage th= is concern.

<= font size=3D"2" color=3D"black" face=3D"Calibri"> 

<= /div>

It= is not uncommon for the logging systems to document on-the-wire messages f= or various purposes, such as, debug, audit, and tracking. At the minimum, the various support and administration staff will have acc= ess to these logs. Also, if an unprivileged user gains access to the SPPP d= eployments and/or support systems, it will have access to the information t= hat is potentially deemed confidential. To manage information disclosure concerns beyond the transport level, the = SPPP implementations SHOULD support XML Encryption standard to facilitate i= nformation hiding at the message level.

<= div>

&nb= sp;

Anti-replay protection ensures that a given SPPP = object is not played back at a later time and affect the integrity of the s= ystem. SPPP protocol provides at least two mechanisms to aid the implementers in = this regard: client transaction identifier and embedded create timestamps f= or the SPPP objects. The client transaction identifier allows the sender to= correlate the response with the request and verify that the transaction was returned from the intended SPP= P implementation. The timestamps in the modify SPPP objects that reflect th= e time it was created MUST reflect the current time and the SPPP implementa= tions SHOULD test the time values to make sure that they are not replayed inadvertently, or with a malicious= intent.

<<<<<=  

 

Thanks,

 

-Syed

 

-Syed


This e-mail= message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

--_000_CA7D8646147F8syedalineustarbiz_-- From syed.ali@neustar.biz Mon Aug 29 13:19:12 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3091F21F8C59 for ; Mon, 29 Aug 2011 13:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.621 X-Spam-Level: X-Spam-Status: No, score=-4.621 tagged_above=-999 required=5 tests=[AWL=-1.908, BAYES_00=-2.599, FB_IOW=3.333, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLihgJN2wPcD for ; Mon, 29 Aug 2011 13:19:10 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAEC21F8C52 for ; Mon, 29 Aug 2011 13:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1314649230; x=1630001120; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=8ZP7Zk8jsvKRgP5v4KKoa qfWufLe4ty1zXtDBBvicWM=; b=OQxINUkANSJsgv0358Sds1I+1xxSuZE1YIzgN Cf8GQRSvsFSENCCqWU4gYIa+3BEUypNFU0D5QP1dQdxFzuhqQ== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id G6K7MJ1.26356503; Mon, 29 Aug 2011 16:20:29 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Mon, 29 Aug 2011 16:20:29 -0400 From: "Ali, Syed Wasim" To: Dean Willis , "Cartwright, Ken" Date: Mon, 29 Aug 2011 16:20:25 -0400 Thread-Topic: [drinks] security considerations... Thread-Index: AcxmiRfzp3bZgyIFThqeRS9GL0qlPw== Message-ID: In-Reply-To: <4E58042C.60502@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: wHrdU0Cm5WFfflikdu4m7g== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] security considerations... X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 20:19:12 -0000 Good thoughts. Please see inline: On 8/26/11 4:38 PM, "Dean Willis" wrote: >On 8/26/11 10:21 AM, Cartwright, Ken wrote: >> Hi Jeremy, >> >> The protocol =B3musts=B2 HTTPS and also =B3shoulds=B2 certs based server= and >> client auth. Imo, the cert based server and client auth covers what you >> refer to as =B3end-to-end message integrity=B2. Iow, if you have used th= e >> cert to verify that the party on the other end is who you think they are >> then it=B9s covered I believe. And anything more than that I do not see = as >> necessary (a =B3may=B2 at best). > >Good points. > >As we know from RFC 3552, the key here is deciding what the credible >threat model is, then effectively using techniques to block the credible >threats. For example, is having a server CPU that has been designed by >its manufacturer to leak our information a credible threat? Probably >not. Is having somebody standing outside the office or in a switching >junking sniffing our traffic a credible threat? Quite probably. > >The goal here is to think like an attacker, and figure out where in the >system the weak parts are and how to attack them, to document those >attacks, and then explain how to defend against them. > > >We have "on the wire" interception threats, which (as Ken points out) >are mostly handled by HTTPS. [SYED] Yes. > >But our confidential records could "leak" at the back end. For example, >if an intruder has access to the transaction log, they could find out >what transactions we had sent. Of course, if they have access to the >transaction log, they quite probably also have access to the server >database, which would tell them a lot more. That's not something we can >really defend against at the level of protocol we're using. At best, we >can describe the risk (especially if there are any "special" risk >factors to leaking our data) and remind implementor/users to apply >appropriate measures to secure the back-end. [SYED] How to "secure the back-end" is covered by local IT Policy. Since this doesn't affect SPPP protocol messages, I don't think this belongs to the SPPP threat model. > >How about an HTTPS MITM? Perhaps rar A connects to what it thinks is the >registry, but is actually an attacker. If A is not careful about >evaluation of the certificate presented by the registry, then A could be >tricked into authenticating with the attacker. Digest is reasonably good >but imperfect at keeping the attacker from deducing A's password, so the >attacker might then be able to initiate transactions on behalf of rar A >(and all A's rants) to the registry. Consequently, we probably need to >talk about how A should evaluate the cert presented by the registry. I'm >not an expert on the references here. IS the sequence in Section 3.1 of >RFC 28218 adequate as a reference, or do we need more discussion? [SYED] "how A should evaluate the cert presented by the registry" refers to implementation details that, specially if covered by other RFCs, should not be repeated again here in the SPPP doc. > >Note that RFC 4523 spends a lot of effort talking about certificate >matching rules for LDAP, as RFC 5922 does for SIP. So it's not uncommon >for an IETF spec to need more discussion on certificate matching. [SYED] Relevant RFCs should be included in the "Informative References" section. Perhaps this particular section can be reviewed in the upcoming interim. Sumanth? > > > >We have client-identity impersonation threats, which we're currently >relying on the use of a simple password authentication scheme to >control. We assume that the password is unlikely to be intercepted "on >the wire" since it is being used over HTTPS. But what if it leaks from >either the client or server sides through a back-end process? For >example, as a client, I've left the password on a sticky-note attached >to my monitor, and the cleaning staff transmits it to the competitor who >has bribed them to send copies of all sticky-notes attached to monitors. > >Yes, we could use XML signing to make this harder, but we'd get the same >benefit out of using a stronger authentication mechanism that uses a >client-side cert. [SYED] At the minimum, this belongs to the transport layer. Though there may be other RFC/standard that describes how to manage these concerns. > > >What about the threat model where a legitimate client crafts >transactions designed to interfere with the operation of other clients? >Assume we have rar A representing rant Alice. A protocol design or >implementation error could easily let rar B inappropriately read, write, >update, or insert faux records affecting rant Alice. [SYED] "implementation error" is beyond SPPP spec. Quality Assurance should catch these errors. > >One can also envision cases where a rant-to-rar interface outside the >scope of this protocol might be used by a malicious rant to "trick" the >rar into doing something inappropriate. For example, what happens when >rant Bob sends rar B a batch of updates and accidentally refers to >himself as rant Alice? B might then recklessly send those changes to the >registry, adversely affecting Alice (if the registry allows rar B to >affect records for rant Alice). Hopefully we defend against this by >permission masking, or in RFC 3552 terms applying an access control list >to the records of rant Alice that precludes rar B from altering them. [SYED] As you noted, it is "outside the scope of this protocol". If "B might then **recklessly** send those changes to registry" ... (1) It is an implementation error on the client side. (2) If it escapes the authorization checks on the registry, these issues will be caught by way of bad resolution errors and/or audit/tracking reports. The only thing I can think of warning the implementers is against bad implementation and better quality assurance. Not sure if this belongs in the security considerations section. > >But what if rants Alice and Bob are both legitimate clients of rar A? >Our access list won't work. It becomes critical that A apply mechanisms, >currently outside the control of SPPP, to verify that the transactions >it submits on behalf of a rant affect only records relating to that >rant. This is something we can't control at the SPPP level, but is a >threat we can identify and warn the rars about. [SYED] "can't control at the SPPP level", and this amounts to implementation guidance. > >On a related note, is there a special threat to offer validation? Can >Charlie offer routes to Alice that appear to be from her preferred >partner Bob, but terminate on Charlie instead, thereby stealing revenue >from Bob? Where there's a financial incentive, there's a lot of risk of >an attack. So we need to identify areas where there's a strong financial >incentive, and where possible, defend those points strongly. [SYED] SPPP is a provisioning protocol and I would prefer to not address business intelligence concerns with it. > > >Do we need non-repudiation? Consider the case where rant Alice sends rar >A some updates, and A dutifully pushes them into the registry using >SPPP. These records are bad and they break something -- maybe Alice. >Presume Alice then sues the registry operator for the resulting >catastrophe. How does the registry (or the intervening rar) prove that >the records came from Alice and not an administrative error or an >attacker that was negligently admitted by the registry or the rar? >Since at the very best our database shows that the transaction was >authenticated to rar A (and that such authentication could be in-error), >it's hard to prove that the fault was Alice's. We can't even ask Alice >to XML-sign the incoming data, since she's using a non-SPPP interface to >talk to A. [SYED] This is what I proposed as well. And yes, this relates to SPPP objects and, in my opinion, belongs to the security considerations section. > >A similar attack could be launched by rar A. If we had XML signatures by >A on the records, then we could "prove" that A had submitted the >erroneous data, not somebody else (for whom the registry is presumably >responsible). Is this an important enough threat that we want to think >about it in our protocol? If so, then we can't just say "use XML >signatures". We'd have to talk about the certification process used to >support the signatures. The same complexity applies to any more advanced >authentication techniques. > > > >Does it make sense for rars to encrypt all data (XML Encryption) before >submitting to the registry over HTTPS, such that the records are >encrypted even in the database? [SYED] Depends on the information disclosure policy that the "rars" must adhere to. If there is concern that the data may be exposed to unintended actors before (or after) the registry implementation has an opportunity to munch it, then it is not that far-fetched an idea. Also, it is likely that parts of the SPPP message are encrypted, and not the whole message. >Probably not, because then the registry >would not be able to operate on the records to do things like matching >route group offers. Nor would it be able to construct an ENUM >presentation from the data. While it might be feasible for the registry >to also have all the keys needed to decrypt the records, there's no real >reason to presume that this will protect the back-end process. Since >matching operations require decrypting the data, many logging operations >are going to happen on decrypted data, and if an intruder has access >into the database, there's no reason to assume the intruder couldn't >also steal the decryption key(s). [SYED] There are a lot of assumptions here that help construct one way to consume data. Most well-known database products enumerate a strategy to store encrypted data and key managemement to encrypt/decrypt it, as well as an elaborate song and dance for the app layer to access it. I don't think this level of detail belongs into the SPPP security considerations. The proposed text in the original message of this thread covers the encryption needs and the related standard that may be used to leverage it. > > >-- >Dean > > > From kcartwright@tnsi.com Tue Aug 30 08:01:39 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F7521F8C7B for ; Tue, 30 Aug 2011 08:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDpNsT9I9p2m for ; Tue, 30 Aug 2011 08:01:38 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 97DC821F8C76 for ; Tue, 30 Aug 2011 08:01:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMAAIn7XE6sEQfn/2dsb2JhbABCmDOQYYFAAQEBAQMBAQE3LQQDFwQCAQgRBAEBHwkHJwsUCQgBAQQBEgiHbrlLhW1gBKRF X-IronPort-AV: E=Sophos;i="4.68,302,1312153200"; d="scan'208";a="158812" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 30 Aug 2011 16:03:01 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Tue, 30 Aug 2011 11:03:01 -0400 From: "Cartwright, Ken" To: Alexander Mayrhofer , "drinks@ietf.org" Date: Tue, 30 Aug 2011 11:03:41 -0400 Thread-Topic: on data validation... Thread-Index: AcxmMw3r8FwzikkYTuibmLYviZ0gkQA8ck1w Message-ID: <754963199212404AB8E9CFCA6C3D0CDA38DDC75224@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <8BC845943058D844ABFC73D2220D46650AC3832B@nics-mail.sbg.nic.at> In-Reply-To: <8BC845943058D844ABFC73D2220D46650AC3832B@nics-mail.sbg.nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [drinks] on data validation... X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 15:01:39 -0000 Hi Alex, Excellent contribution. I think all of your proposals are reasonable. We = can implement these improvements into the spec in a couple hours, once we g= et concensus. My only slight concern is about _requiring_ the "+" sign in TNs. Not all s= equence of digits that will be provisioned into this field are going to be = e164 numbers. So I'd say making the "+" optional would be good. Ken -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Alexander Mayrhofer Sent: Monday, August 29, 2011 7:17 AM To: drinks@ietf.org Subject: [drinks] on data validation... The concerns about the "unconstrained" elements were raised a long time ago, and i admit it was a TODO on me that i never delivered - so let's hope it's still useful now: In preperation for the virtual interim, i've looked through the formal schema specification of SPPP, checking which elements should have more reasonable constraints added (compared to the current "everything goes" policy). I've also found a few other things (listed below). We have currently very little constraints on the various fields, which means that a client could theoretically use a 8GB long blob of unprintable unicode character codepoints as an object identifier. This would obviously lead to a lot of problems, and hence (as indicated by Dean and his developers), some constraints are required for interopability. Similar protocols in the IETF (most notably, EPP), have limited such identifiers in a similar way and are deployed in a broad fashion. Quantitative and qualitative limitations help interopability (i'd even go that far to say that protocols with no such limitations have unknown interopability, because any test cannot be exhaustive). Object Names ------------------ - I think that the various "names" and "keys" are the most important ones to apply constraints on, since they are used as references between objects, and used in comparison / lookup operations. Therefore, i suggest to change the definition of ObjNameType from the current to the following definition (note that the upper and lower limits are arbitrary - anybody willing to offer a reasoning from practice? Also, more on "string" vs. "token" base type below) This affects, from what i can see, the following elements: - dgName - rrName - egrRteName - rgName Transaction IDs ------------------ In a similar way, we should also restrict Transaction IDs. Those are currently very "open" as well, and have the following definition: I do suggest to change those to: (note: I've seen that transaction ids tend to get longer than object identifiers, so i extended my arbitrar length restrictions from the ObjNameType above). This restriction would affect the following elements: - clientTransId - serverTransId Restrictions on E.164-derived elements ------------------------------------------------ The instances of the abstract public identifier object contain elements that are derived from E.164 numbers. Since those are a namespace that is very well defined and constrained, we should also look into constraining the derived elements in SPPP. I do hence suggest to change the definition of - tn - rn - startTN - endTN - tnPrefix (all of them are currently defined as "string" with no additional length constraints) to a specific Type (eg. "e164DerivedType"?). For definitions, one option is to use the definition from RFC5105: However, i do understand that E.164 numbers can also use hexadecimal characters "a-f", and hence the above definition would not allow those? I haven't taken up the effort of checkign against E.164, but i'm sure there are more knowledgeable people on the list... Any advice? Organizations ---------------- Identifier of organizations are currently unrestricted as well. The respective XML Schema definition is as follows: I understand that since the namespace for those organizations will probably come out of the GSPID work, or use some existing namespace, but i think it will definitely need to be constrained (for the reasons outlined above). Base Type "string" vs "token" ------------------------------------ comparing the XML Schema definitions for "string" (base type) vs. "token" base type, i'm pretty sure that we want all elements in our protocol that contain textual contents to derive from the "token" base type. The difference is that "string" base types allow for line feeds, carriage returns, etc. Whitespace is significant. On the other hand, the "token" basetype does not allow for carriage return, line feed, tab, leading and trailing spaces. http://www.w3.org/TR/xmlschema-2/#token I cannot think of a case where we would need to consider those characters in an element, and hence suggest that we change all "string" base types in SPPP to "token". Anybody aware of an element where we should make an exception from that rule? (Disclaimer: I'm not a XML expert, though!) NAPTR -------- RFC 4114 contains an "IESG-tested" schema definition for the contents of a NAPTR record. We should probably re-use that, instead of creating a new definition: http://tools.ietf.org/html/rfc4114#section-4 Format of Nameservers / IP addresses ----------------------------------------------- The same applies to the definition of IP addresses and nameserver names, those could be copied over from the respective EPP specifications in RFC5731 (and adapted slightly, as needed). The definition for IP addresses there is: Again, this would have the advantage that we use an IESG-approved definition from an existing RFC. URIs ------ Note that XML Schema contains a base type for URIs. we could use that one eg. for tghe definition of the "uri" element in the "URIType": http://www.w3.org/TR/xmlschema-2/#anyURI (plus, i'm sure we want that field, like other fields that contain URIs, limit to absolute URIs, because we don't have a definition what the base for a relative URI would be - i think that can only be done in text, though - not in Schema). (However, given that the "uri" element can contain backreferences, the base type "URI" would probably not be appropriate, because it's not an actual URI?) I hope we can use that information above as a basis to discuss data validation during the interim meeting - if someone comes up with different ideas, please share on the list! Alex _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From sumanth@cablelabs.com Tue Aug 30 15:35:38 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7E121F8ED1 for ; Tue, 30 Aug 2011 15:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.406 X-Spam-Level: X-Spam-Status: No, score=-0.406 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZyOki-W-Wvz for ; Tue, 30 Aug 2011 15:35:38 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id BED4321F8EE7 for ; Tue, 30 Aug 2011 15:35:37 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id p7UMb5u1030764 for ; Tue, 30 Aug 2011 16:37:05 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Tue, 30 Aug 2011 16:37:05 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 30 Aug 2011 16:37:04 -0600 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Tue, 30 Aug 2011 16:35:39 -0600 Thread-Topic: INTERIM meeting is tomorrow Thread-Index: AQHMZ2VX+Ipx7W/CZ0ilL5KYeePt7g== Message-ID: <76AC5FEF83F1E64491446437EA81A61F8190801FE8@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] INTERIM meeting is tomorrow X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 22:35:38 -0000 FYI.... Also, we may add one agenda item regarding demonstration of OpenSPPP. We ca= n discuss during the agenda bashing...=20 - S Date and Time =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Wed, Aug 31 2011 - 01:00 PM - 05:00 PM (Eastern)/ 17:00 - 21:00 (UTC) -- use http://www.tim= ezoneconverter.com or equivalent to check local times Location =3D=3D=3D=3D=3D=3D - Virtual; via GoToMeeting and a teleconference bridge (you can use the bui= lt-in VoIP or use the call-in number) - Link: https://www1.gotomeeting.com/join/259806864 - Call-in Dial : +1 (636) 277-0134 Access Code: 259-806-864 AGENDA =3D=3D=3D=3D=3D=3D=3D 0/ Administrivia (note well, scribes) and agenda bashing -- ~10 mts 1/ Review and resolve open items related to the following a) protocol document (draft-ietf-drinks-spprov) -- ~= 120 mts b) transport document (draft-ietf-drinks-sppp-over-soap) -- ~45 mts 2/ Discuss and respond to the ITU liaison -- ~15 mts 3/ Open Discussion -- ~30 mts 4/ Next Steps -- ~15 mts - Sumanth & Alex _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks From dean.willis@softarmor.com Tue Aug 30 16:20:05 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38ACD21F8C8E for ; Tue, 30 Aug 2011 16:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.398 X-Spam-Level: X-Spam-Status: No, score=-103.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOQwDPd1yJwb for ; Tue, 30 Aug 2011 16:20:04 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7485021F8C8A for ; Tue, 30 Aug 2011 16:20:04 -0700 (PDT) Received: by gyf3 with SMTP id 3so121537gyf.31 for ; Tue, 30 Aug 2011 16:21:32 -0700 (PDT) Received: by 10.91.18.12 with SMTP id v12mr2636988agi.43.1314746492815; Tue, 30 Aug 2011 16:21:32 -0700 (PDT) Received: from dwillis-mb1.local (cpe-66-25-15-110.tx.res.rr.com [66.25.15.110]) by mx.google.com with ESMTPS id p6sm6544060anh.37.2011.08.30.16.21.30 (version=SSLv3 cipher=OTHER); Tue, 30 Aug 2011 16:21:32 -0700 (PDT) Message-ID: <4E5D7078.7050502@softarmor.com> Date: Tue, 30 Aug 2011 18:21:28 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "Cartwright, Ken" References: <754963199212404AB8E9CFCA6C3D0CDA38DD5F2E9E@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E5651F2.2090307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8CDE8@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E56A264.50703@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8CFC5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E571FF3.1070308@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8D170@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E57F3A3.8010400@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDC748B8@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E582C8E.3090202@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDC74B29@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA38DDC74B29@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "drinks@ietf.org" Subject: Re: [drinks] Long Followup to Thoughts on "Organization" in draft-ietf-drinks-spprov-09 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 23:20:05 -0000 On 8/29/11 8:23 AM, Cartwright, Ken wrote: >>> KJC2: Dean that is not at all correct. The spec explicitly requires >>> Digest Authentication. >> >> It might require digest authentication but of what/who and using what >> credentials isn't in the spec. So we deferred that part of the >> implementation. > > KJC3: (1) Not sure I agree with that. The spec says that the > clients of the SPPP/SOAP/HTTPS must use digest authentication. (2) > The IETF RFCs that I've read do not go to the extent of explaining > how implementers of a protocol that must use digest authentication > will do Digest Authentication. But if there is some specific > statement you would like me to add I will do so. A counterexample: RFC 3261 has a modest discussion of how it uses digest authentication. EPP, RFC 4930, also discusses how the login" command is used to establish authenticated identity. Some discussion of "how it works" with SPPP might be useful. Oddly enough, EPP transports the authentication identity in the payload, rather than leaving it fully to the transport binding. Proposed (but probably inadequate) text: In the SPPP protocol document: Only registrars have authentication credentials in SPPP. The registrar identifier (name) by which an SPPP request is checked against authorization policy is not conveyed in the body of the SPPP request. Authentication is performed at the the transport binding layer. The transport binding MUST therefore provide the authenticated registrar identifier to the lower layers of the implementation. The implementation MUST check the authenticated registrar identifier against local policy in order to determine whether or not the specific request is currently authorized for that registrar. In the SOAP binding document: The SPPP SOAP binding uses digest authentication over HTTPS as specified in RFC 2617. The "username" parameter of the Authorization header encodes the name of the registrar making the request, and MUST be passed by the implementation along with the SOAP request body to the application. Use of this username in the making of authorization decisions is subject to local policy in the implementation. ... >> KJC2: To see the resolution response from a resolution server that >> is feed using SPPP the way is to do a dig or an SIP invite. > > A SIP INVITE doesn't normally return a database lookup. > > KJC3: That's simply incorrect. The SIP response is built from a lookup into a DB, be it in memory on on disk. SOMETIMES SIP returns the results of a database lookup in a 302 response. The more common case is for the SIP proxy to send the INVITE along to the terminating user agent, which responds with something like a 200 OK setting the call up. You certainly can't end SIP INVITE requests to arbitrary destination URLs in the hope of doing a database lookup, unless you a priori knowledge about the behavior of the servers at those URLs. > > It doesn't tell > me what routes I've offered to people, what routes I've been offered, or > how my destinations are grouped up. In the "normal" case, it returns > some SDP for setting up a media flow. > > KJC3: There are several detailed use case around how SIP response are constructed from an underlying set of data, and what the resulting SIP response might be. You brought up using dig if te protocol id ENUM, so I offered up the additional use of SIP. ENUM and SIP are analogous here. Neither of these protocols will tell you all of the data that was _evaluated_ when arriving at the final ENUM or SIP response. > > Likewise, the expressive range of a "dig" lookup is much less than the > expressive range of an SPPP request. > > KJC3: OF course. You brought up dig, not me. Yeah, I'd still like better diagnostic tools. -- Dean From dean.willis@softarmor.com Tue Aug 30 16:24:56 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 499AA21F8E89 for ; Tue, 30 Aug 2011 16:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.405 X-Spam-Level: X-Spam-Status: No, score=-103.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSiFwdEX--Ud for ; Tue, 30 Aug 2011 16:24:55 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id EBB6521F8D0F for ; Tue, 30 Aug 2011 16:24:54 -0700 (PDT) Received: by gxk19 with SMTP id 19so121925gxk.31 for ; Tue, 30 Aug 2011 16:26:23 -0700 (PDT) Received: by 10.91.16.31 with SMTP id t31mr5824705agi.165.1314746783381; Tue, 30 Aug 2011 16:26:23 -0700 (PDT) Received: from dwillis-mb1.local (cpe-66-25-15-110.tx.res.rr.com [66.25.15.110]) by mx.google.com with ESMTPS id l38sm6552183ani.18.2011.08.30.16.26.20 (version=SSLv3 cipher=OTHER); Tue, 30 Aug 2011 16:26:22 -0700 (PDT) Message-ID: <4E5D719B.2020804@softarmor.com> Date: Tue, 30 Aug 2011 18:26:19 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "Ali, Syed Wasim" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "drinks@ietf.org" Subject: Re: [drinks] security considerations... X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 23:24:56 -0000 On 8/29/11 11:22 AM, Ali, Syed Wasim wrote: > We discussed RESTful or "not" before. In fact, we can do SOAP wrapper or > REST, not both. This has been addressed before... If the data model were really separated from the transport, then we could do a REST binding or a SOAP binding, or a JDBC binding, or am XMLRPC binding, or whatever. > >> >> Even relying on HTTP Auth as part of our resource identification is >> un-RESTful. SO the registrar identifier should be one of the parameters, >> not something we get from the auth layer. But Ken is telling me that the >> registar identifier is completely out-of-scope for the protocol. > > See earlier comment. Since RESTful doesn't apply in the SPPP document, > this comment is irrelevant at best. This discussion is out of scope unless > there is a requirement to ditch SOAP and do REST. Also, you probably mean > "registrant" and not "registrar". The resource belongs to registrant, not > the registrar. Not according to what I think Ken is explaining to me. I think Ken is saying that the only authenticated party is the registrar, and that the registrar makes all requests on behalf of the registrant. Therefore it's the registrar who "owns", meaning "controls changes to" the data. But since we lost rarId from the schema, we can't really track which registrar put the data there unless we have another object-registrar mapping "outside" the protocol. I suspect this can lead to all sort of interesting data-access and update conflicts when multiple registrars are handling a given registrant. -- dean From dean.willis@softarmor.com Tue Aug 30 16:33:46 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B2A21F8D97 for ; Tue, 30 Aug 2011 16:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.412 X-Spam-Level: X-Spam-Status: No, score=-103.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvd0Ke0llYfe for ; Tue, 30 Aug 2011 16:33:46 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE8C21F8D94 for ; Tue, 30 Aug 2011 16:33:46 -0700 (PDT) Received: by yie12 with SMTP id 12so164023yie.31 for ; Tue, 30 Aug 2011 16:35:14 -0700 (PDT) Received: by 10.90.23.34 with SMTP id 34mr5852634agw.90.1314747314716; Tue, 30 Aug 2011 16:35:14 -0700 (PDT) Received: from dwillis-mb1.local (cpe-66-25-15-110.tx.res.rr.com [66.25.15.110]) by mx.google.com with ESMTPS id g3sm3185062ank.28.2011.08.30.16.35.12 (version=SSLv3 cipher=OTHER); Tue, 30 Aug 2011 16:35:14 -0700 (PDT) Message-ID: <4E5D73AD.8040502@softarmor.com> Date: Tue, 30 Aug 2011 18:35:09 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "Ali, Syed Wasim" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "drinks@ietf.org" Subject: Re: [drinks] security considerations... X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 23:33:47 -0000 On 8/29/11 3:20 PM, Ali, Syed Wasim wrote: >> How about an HTTPS MITM? Perhaps rar A connects to what it thinks is the >> registry, but is actually an attacker. If A is not careful about >> evaluation of the certificate presented by the registry, then A could be >> tricked into authenticating with the attacker. Digest is reasonably good >> but imperfect at keeping the attacker from deducing A's password, so the >> attacker might then be able to initiate transactions on behalf of rar A >> (and all A's rants) to the registry. Consequently, we probably need to >> talk about how A should evaluate the cert presented by the registry. I'm >> not an expert on the references here. IS the sequence in Section 3.1 of >> RFC 28218 adequate as a reference, or do we need more discussion? > [SYED] "how A should evaluate the cert presented by the registry" refers > to implementation details that, specially if covered by other RFCs, should > not be repeated again here in the SPPP doc. Actually, there are a lot of choices about how a client could interpret the cert. RFC 2818 section 3.1 introduces the basic concept, and references RFC 2459 for matching. Are these mechanisms adequate for our usage? > >> >> Note that RFC 4523 spends a lot of effort talking about certificate >> matching rules for LDAP, as RFC 5922 does for SIP. So it's not uncommon >> for an IETF spec to need more discussion on certificate matching. > [SYED] Relevant RFCs should be included in the "Informative References" > section. Perhaps this particular section can be reviewed in the upcoming > interim. Sumanth? > >> >> >> >> We have client-identity impersonation threats, which we're currently >> relying on the use of a simple password authentication scheme to >> control. We assume that the password is unlikely to be intercepted "on >> the wire" since it is being used over HTTPS. But what if it leaks from >> either the client or server sides through a back-end process? For >> example, as a client, I've left the password on a sticky-note attached >> to my monitor, and the cleaning staff transmits it to the competitor who >> has bribed them to send copies of all sticky-notes attached to monitors. >> >> Yes, we could use XML signing to make this harder, but we'd get the same >> benefit out of using a stronger authentication mechanism that uses a >> client-side cert. > [SYED] At the minimum, this belongs to the transport layer. Though there > may be other RFC/standard that describes how to manage these concerns. Ok, that argues XML signing should not be included at a SHOULD level. > >> >> >> What about the threat model where a legitimate client crafts >> transactions designed to interfere with the operation of other clients? >> Assume we have rar A representing rant Alice. A protocol design or >> implementation error could easily let rar B inappropriately read, write, >> update, or insert faux records affecting rant Alice. > [SYED] "implementation error" is beyond SPPP spec. Quality Assurance > should catch these errors. However, there is a requirement that the implementation check the authenticated (but unspecified) rar identity against something "currently unspecified" in making a check. This requires more guidance than saying "just authenticate something" in the protocol spec. If we want client A to work with server B, we at least need rar identifier validation rules, need to know what charset they're in, and so on. -- Dean >> > From philippe.fouquart@orange-ftgroup.com Wed Aug 31 02:27:00 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E4721F8B30 for ; Wed, 31 Aug 2011 02:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvFRqBw4Zi7s for ; Wed, 31 Aug 2011 02:26:59 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8D77021F8B42 for ; Wed, 31 Aug 2011 02:26:59 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EB929FDC005; Wed, 31 Aug 2011 11:28:27 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id E1267FDC012; Wed, 31 Aug 2011 11:28:27 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 31 Aug 2011 11:28:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Aug 2011 11:28:21 +0200 Message-ID: In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA38DDC75224@TNS-MAIL-NA.win2k.corp.tnsi.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [drinks] on data validation... Thread-Index: AcxmMw3r8FwzikkYTuibmLYviZ0gkQA8ck1wACQw6tA= References: <8BC845943058D844ABFC73D2220D46650AC3832B@nics-mail.sbg.nic.at> <754963199212404AB8E9CFCA6C3D0CDA38DDC75224@TNS-MAIL-NA.win2k.corp.tnsi.com> From: To: , X-OriginalArrivalTime: 31 Aug 2011 09:28:23.0162 (UTC) FILETIME=[543DCDA0:01CC67C0] Subject: Re: [drinks] on data validation... X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 09:27:00 -0000 Hi Alex, FWIW on this point, I think what you say is that in some signaling protocols=20 (eg ISUP) parameters originally defined for E.164 numbers are also used=20 to convey things like hexadecimal strings even if they're not part of=20 the numbering plan. And indeed this is correct, and was also reflected=20 in RFC 3966 in the section on such strings along with DTMF (see section=20 5.1.3.). (There was a time when these were explicitly ruled out in an annex=20 to the recommendation, now gone). If you use "e164numberType" as simpleType=20 name, my personal inclination therefore would be not to change that definition=20 from RFC5105 to be consistent, and keep "\+\d\d*".=20 Non E.164 formats, however, are a valid use case for interconnect especially=20 when you use NP-corrected numbers with a national prefix. It may therefore=20 also make sense to cover these in the schema (which I think it also relates=20 to Ken's observation on the '+' sign). If you want to address that and=20 provided that's within charter, I'd suggest you simply change the simpleType=20 name for clarity and allow for a more flexible syntax.=20 I hope this helps, Regards, Philippe Fouquart R&D/CORE/NAS +33 (0) 1 45 29 58 13 -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Alexander Mayrhofer Sent: Monday, August 29, 2011 7:17 AM To: drinks@ietf.org Subject: [drinks] on data validation... However, i do understand that E.164 numbers can also use hexadecimal characters "a-f", and hence the above definition would not allow those? I haven't taken up the effort of checkign against E.164, but i'm sure there are more knowledgeable people on the list... Any advice? From kcartwright@tnsi.com Wed Aug 31 06:42:52 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71EDC21F8B76 for ; Wed, 31 Aug 2011 06:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnThqejBX85L for ; Wed, 31 Aug 2011 06:42:51 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5E90321F8B66 for ; Wed, 31 Aug 2011 06:42:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0AAEg6Xk6sEQfn/2dsb2JhbAA5AQmYXpBhgUABAQQBOj8MBAIBCBEEAQEXAQcJBzIUCQgBAQQOAwIIh2q5T4MwARoBgilgBKRIIA X-IronPort-AV: E=Sophos;i="4.68,307,1312153200"; d="scan'208";a="163336" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 31 Aug 2011 14:44:16 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Wed, 31 Aug 2011 09:44:16 -0400 From: "Cartwright, Ken" To: Dean Willis Date: Wed, 31 Aug 2011 09:44:15 -0400 Thread-Topic: Long Followup to Thoughts on "Organization" in draft-ietf-drinks-spprov-09 Thread-Index: Acxna4/1M7himnuDQE2lCZdGpRYU8gAdrZ2A Message-ID: <754963199212404AB8E9CFCA6C3D0CDA38DDD5CEE4@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <754963199212404AB8E9CFCA6C3D0CDA38DD5F2E9E@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E5651F2.2090307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8CDE8@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E56A264.50703@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8CFC5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E571FF3.1070308@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8D170@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E57F3A3.8010400@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDC748B8@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E582C8E.3090202@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDC74B29@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E5D7078.7050502@softarmor.com> In-Reply-To: <4E5D7078.7050502@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] Long Followup to Thoughts on "Organization" in draft-ietf-drinks-spprov-09 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 13:42:52 -0000 See responses in-line, KJC4. -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Tuesday, August 30, 2011 7:21 PM To: Cartwright, Ken Cc: drinks@ietf.org Subject: Re: Long Followup to Thoughts on "Organization" in draft-ietf-drin= ks-spprov-09 On 8/29/11 8:23 AM, Cartwright, Ken wrote: >>> KJC2: Dean that is not at all correct. The spec explicitly requires >>> Digest Authentication. >> >> It might require digest authentication but of what/who and using what >> credentials isn't in the spec. So we deferred that part of the >> implementation. > > KJC3: (1) Not sure I agree with that. The spec says that the > clients of the SPPP/SOAP/HTTPS must use digest authentication. (2) > The IETF RFCs that I've read do not go to the extent of explaining > how implementers of a protocol that must use digest authentication > will do Digest Authentication. But if there is some specific > statement you would like me to add I will do so. A counterexample: RFC 3261 has a modest discussion of how it uses digest authentication. EPP, RFC 4930, also discusses how the login" command is used to establish authenticated identity. KJC4: There is no "login" command in SPPP, because it uses Digest Authenti= cation, at the explicit request of one of the participants. So there is no= login command to talk about. I am certainly not apposed to having an expl= icit "login" operation. But you would need to convince others. Some discussion of "how it works" with SPPP might be useful. Oddly enough, EPP transports the authentication identity in the payload, rather than leaving it fully to the transport binding. KJC4: Yes, it does. Because it has a direct login type command, not using= digest authentication. Dean, we've addressed this point at least 5 times = now with me proposing what can be done about this. Proposed (but probably inadequate) text: In the SPPP protocol document: Only registrars have authentication credentials in SPPP. The registrar identifier (name) by which an SPPP request is checked against authorization policy is not conveyed in the body of the SPPP request. Authentication is performed at the the transport binding layer. The transport binding MUST therefore provide the authenticated registrar identifier to the lower layers of the implementation. The implementation MUST check the authenticated registrar identifier against local policy in order to determine whether or not the specific request is currently authorized for that registrar. KJC4: I'm fine with this, as long as we sync this statement with the relat= ed statements that are already in the "Transport Requirements Section" of t= he document. We also need to remove the "(name)" word in the above. In the SOAP binding document: The SPPP SOAP binding uses digest authentication over HTTPS as specified in RFC 2617. The "username" parameter of the Authorization header encodes the name of the registrar making the request, and MUST be passed by the implementation along with the SOAP request body to the application. Use of this username in the making of authorization decisions is subject to local policy in the implementation. KJC4: The spec already has the first sentence in there. But I don't think= the rest of what you propose here is accurate. But we can change what you= propose to explain how digest authentication is/canBe used to authorize (a= nd therefore identify) the entity being authorized, as is the case in all u= ses of Digest Authentication (because that is what is exists to accomplish)= . ... >> KJC2: To see the resolution response from a resolution server that >> is feed using SPPP the way is to do a dig or an SIP invite. > > A SIP INVITE doesn't normally return a database lookup. > > KJC3: That's simply incorrect. The SIP response is built from a lookup = into a DB, be it in memory on on disk. SOMETIMES SIP returns the results of a database lookup in a 302 response. The more common case is for the SIP proxy to send the INVITE along to the terminating user agent, which responds with something like a 200 OK setting the call up. You certainly can't end SIP INVITE requests to arbitrary destination URLs in the hope of doing a database lookup, unless you a priori knowledge about the behavior of the servers at those URLs. KJC4: Being responsible for a system that supports ENUM, SIP, and SS7 prot= ocols into the same underlying database, I'm fully aware of the use cases t= hat come into play. And even the case where a SIP response is "proxied" we= still need to hit the DB in order to, among other reasons, know where to p= roxy to! Come on dean this back and forth is pointless. > > It doesn't tell > me what routes I've offered to people, what routes I've been offered, or > how my destinations are grouped up. In the "normal" case, it returns > some SDP for setting up a media flow. > > KJC3: There are several detailed use case around how SIP response are co= nstructed from an underlying set of data, and what the resulting SIP respon= se might be. You brought up using dig if te protocol id ENUM, so I offered= up the additional use of SIP. ENUM and SIP are analogous here. Neither o= f these protocols will tell you all of the data that was _evaluated_ when a= rriving at the final ENUM or SIP response. > > Likewise, the expressive range of a "dig" lookup is much less than the > expressive range of an SPPP request. > > KJC3: OF course. You brought up dig, not me. Yeah, I'd still like better diagnostic tools. KJC4: Yea, and they do/will exist, but are not part of the SPP protocol sp= ec. -- Dean This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From kcartwright@tnsi.com Wed Aug 31 06:52:04 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8391421F8B52 for ; Wed, 31 Aug 2011 06:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OT0yYs--5iA6 for ; Wed, 31 Aug 2011 06:52:03 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1A021F8B49 for ; Wed, 31 Aug 2011 06:52:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0AAJo8Xk6sEQfn/2dsb2JhbABDmF6QYYFAAQEBAQIBAQEBNzQLBQcEAgEIEQQBAR8JBycLFAkIAQEEDgUIh2oEuUaFdWAEpEg X-IronPort-AV: E=Sophos;i="4.68,307,1312153200"; d="scan'208";a="163398" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 31 Aug 2011 14:53:32 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Wed, 31 Aug 2011 09:53:32 -0400 From: "Cartwright, Ken" To: Dean Willis , "Ali, Syed Wasim" Date: Wed, 31 Aug 2011 09:53:31 -0400 Thread-Topic: [drinks] security considerations... Thread-Index: AcxnbEAO/nNdH8E6RYi/nEarfpCVogAd9vGw Message-ID: <754963199212404AB8E9CFCA6C3D0CDA38DDD5CF06@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4E5D719B.2020804@softarmor.com> In-Reply-To: <4E5D719B.2020804@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] security considerations... X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 13:52:04 -0000 -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Dean Willis Sent: Tuesday, August 30, 2011 7:26 PM To: Ali, Syed Wasim Cc: drinks@ietf.org Subject: Re: [drinks] security considerations... On 8/29/11 11:22 AM, Ali, Syed Wasim wrote: > We discussed RESTful or "not" before. In fact, we can do SOAP wrapper or > REST, not both. This has been addressed before... If the data model were really separated from the transport, then we could do a REST binding or a SOAP binding, or a JDBC binding, or am XMLRPC binding, or whatever. KJC4: Not correct. ReST is not a transport. If ReST were just a transpor= t then there would be no problem creating a great ReST transport specificat= ion for SPPP. SPPP as specified will work nicely over vanilla TCP, vanilla= HTTP, beep, RPCs, files, and of course SOAP (and others). But it will of = course not elegantly fit with IPC techniques and technologies that want the= data structures and operations and operation responses structured and defi= ned in a specific manner, as is the case with ReST, CORBA, RMI and others. = If that was a requirement from the get go (more than 2 years ago at this p= oint I think) then we should have stated it. But it was not. This discuss= ion has been well worn and documented it. > >> >> Even relying on HTTP Auth as part of our resource identification is >> un-RESTful. SO the registrar identifier should be one of the parameters, >> not something we get from the auth layer. But Ken is telling me that the >> registar identifier is completely out-of-scope for the protocol. > > See earlier comment. Since RESTful doesn't apply in the SPPP document, > this comment is irrelevant at best. This discussion is out of scope unles= s > there is a requirement to ditch SOAP and do REST. Also, you probably mean > "registrant" and not "registrar". The resource belongs to registrant, not > the registrar. Not according to what I think Ken is explaining to me. I think Ken is saying that the only authenticated party is the registrar, and that the registrar makes all requests on behalf of the registrant. Therefore it's the registrar who "owns", meaning "controls changes to" the data. KJC: Not correct, and not relevant. The concept of "ownership" here is to= o vague to be valuable here. You continue to have difficulty with the conc= ept of registrar and registrant. But since we lost rarId from the schema, we can't really track which registrar put the data there unless we have another object-registrar mapping "outside" the protocol. I suspect this can lead to all sort of interesting data-access and update conflicts when multiple registrars are handling a given registrant. -- dean _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From dean.willis@softarmor.com Wed Aug 31 08:47:19 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAA421F8C58 for ; Wed, 31 Aug 2011 08:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.423 X-Spam-Level: X-Spam-Status: No, score=-103.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywzSbjsJ1Fpi for ; Wed, 31 Aug 2011 08:47:18 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id AAA3D21F8C4C for ; Wed, 31 Aug 2011 08:47:18 -0700 (PDT) Received: by ywe9 with SMTP id 9so842997ywe.31 for ; Wed, 31 Aug 2011 08:48:49 -0700 (PDT) Received: by 10.91.203.39 with SMTP id f39mr451881agq.96.1314805729030; Wed, 31 Aug 2011 08:48:49 -0700 (PDT) Received: from dwillis-mb1.local (cpe-66-25-15-110.tx.res.rr.com [66.25.15.110]) by mx.google.com with ESMTPS id c15sm7347264anm.46.2011.08.31.08.48.47 (version=SSLv3 cipher=OTHER); Wed, 31 Aug 2011 08:48:48 -0700 (PDT) Message-ID: <4E5E57DF.5070102@softarmor.com> Date: Wed, 31 Aug 2011 10:48:47 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "Cartwright, Ken" References: <754963199212404AB8E9CFCA6C3D0CDA38DD5F2E9E@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E5651F2.2090307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8CDE8@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E56A264.50703@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8CFC5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E571FF3.1070308@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8D170@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E57F3A3.8010400@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDC748B8@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E582C8E.3090202@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDC74B29@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E5D7078.7050502@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDD5CEE4@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA38DDD5CEE4@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "drinks@ietf.org" Subject: Re: [drinks] Long Followup to Thoughts on "Organization" in draft-ietf-drinks-spprov-09 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 15:47:19 -0000 On 8/31/11 8:44 AM, Cartwright, Ken wrote: > > EPP, RFC 4930, also discusses how the login" command is used to > establish authenticated identity. > > KJC4: There is no "login" command in SPPP, because it uses Digest > Authentication, at the explicit request of one of the participants. > So there is no login command to talk about. I am certainly not > apposed to having an explicit "login" operation. But you would need > to convince others. I'm not proposing an explicit login. I AM proposing that the data payload carry the validated username, which appears to be the registrar identity. I'll propose in further detail below. > Some discussion of "how it works" with SPPP might be useful. Oddly > enough, EPP transports the authentication identity in the payload, > rather than leaving it fully to the transport binding. > > KJC4: Yes, it does. Because it has a direct login type command, not > using digest authentication. Dean, we've addressed this point at > least 5 times now with me proposing what can be done about this. It still hasn't quite resolved to what I think might be robustly implementable. Here's a proposal: We need some way to tie the "username" from Digest auth with the request and with the underlying database. 1) Add rar back into the BasicObjType 2) Say that the username expressed in the Digest MUST be matched against the request's rar by local policy to determine whether local policy will authorize the request. This gives us a model where local policy could say that rar A can only manipulate stored records owned by rar A, or it could manipulate records owned by rar A, B, or C but not D, E, F and so on. In other words, a full range of flexibility. Alternatively, if we really believe that "rant" is the object owner, we have to do something like say that request-username (from Auth) is matched against the rant in the request via a mapping outside of the protocol and under control of local policy in order to decide on the authorization of the request. > > In the SOAP binding document: > > The SPPP SOAP binding uses digest authentication over HTTPS as > specified in RFC 2617. The "username" parameter of the Authorization > header encodes the name of the registrar making the request, and MUST > be passed by the implementation along with the SOAP request body to > the application. Use of this username in the making of authorization > decisions is subject to local policy in the implementation. > > KJC4: The spec already has the first sentence in there. But I don't > think the rest of what you propose here is accurate. But we can > change what you propose to explain how digest authentication is/canBe > used to authorize (and therefore identify) the entity being > authorized, as is the case in all uses of Digest Authentication > (because that is what is exists to accomplish). ... Okay, what I have might need mods. But we need SOMETHING like it to pass security review. -- Dean From dean.willis@softarmor.com Wed Aug 31 08:58:13 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5AFB21F8CD9 for ; Wed, 31 Aug 2011 08:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.429 X-Spam-Level: X-Spam-Status: No, score=-103.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUxQn7ggnDUV for ; Wed, 31 Aug 2011 08:58:13 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id EF71721F877F for ; Wed, 31 Aug 2011 08:58:05 -0700 (PDT) Received: by yie12 with SMTP id 12so858422yie.31 for ; Wed, 31 Aug 2011 08:59:36 -0700 (PDT) Received: by 10.101.51.13 with SMTP id d13mr455834ank.101.1314806376303; Wed, 31 Aug 2011 08:59:36 -0700 (PDT) Received: from dwillis-mb1.local (cpe-66-25-15-110.tx.res.rr.com [66.25.15.110]) by mx.google.com with ESMTPS id p34sm7368768ann.17.2011.08.31.08.59.34 (version=SSLv3 cipher=OTHER); Wed, 31 Aug 2011 08:59:35 -0700 (PDT) Message-ID: <4E5E5A66.6070608@softarmor.com> Date: Wed, 31 Aug 2011 10:59:34 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "Cartwright, Ken" References: <4E5D719B.2020804@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDD5CF06@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA38DDD5CF06@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "drinks@ietf.org" Subject: Re: [drinks] security considerations... X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 15:58:14 -0000 On 8/31/11 8:53 AM, Cartwright, Ken wrote: >> Not according to what I think Ken is explaining to me. I think Ken >> is saying that the only authenticated party is the registrar, and >> that the registrar makes all requests on behalf of the registrant. >> Therefore it's the registrar who "owns", meaning "controls changes >> to" the data. > > KJC: Not correct, and not relevant. The concept of "ownership" here > is too vague to be valuable here. You continue to have difficulty > with the concept of registrar and registrant. Well apparently, Ken, I'm stupid. Quite possibly a lot of people who are going to read this spec are almost as stupid as I am. The protocol authors have to find a way to explain these simple concepts to us even simpler readers. So, how does a client anticipate whether or not it should have access to a given record on a server when we can't say whether access is controlled by the username in the digest auth's relationship to any specific element or set of elements in the data schema? -- Dean From kcartwright@tnsi.com Wed Aug 31 09:03:50 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0C021F8D00 for ; Wed, 31 Aug 2011 09:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIgrKlQctJ2b for ; Wed, 31 Aug 2011 09:03:50 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 25DB521F8D0A for ; Wed, 31 Aug 2011 09:03:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0AAA5bXk6sEQfn/2dsb2JhbAA5AQmYYJBhgUABAQQBOj8FBwQCAQgRBAEBFwEHCQcyFAkIAQEEDgMCCIdqumGDMAEaAYIpYASkSCA X-IronPort-AV: E=Sophos;i="4.68,308,1312153200"; d="scan'208";a="164201" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 31 Aug 2011 17:05:17 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Wed, 31 Aug 2011 12:05:56 -0400 From: "Cartwright, Ken" To: Dean Willis Date: Wed, 31 Aug 2011 12:05:16 -0400 Thread-Topic: Long Followup to Thoughts on "Organization" in draft-ietf-drinks-spprov-09 Thread-Index: Acxn9XuSzLzWCip4TieCxo3crBM65gAAREtQ Message-ID: <754963199212404AB8E9CFCA6C3D0CDA38DDD5D0E8@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <754963199212404AB8E9CFCA6C3D0CDA38DD5F2E9E@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E5651F2.2090307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8CDE8@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E56A264.50703@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8CFC5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E571FF3.1070308@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDB8D170@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E57F3A3.8010400@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDC748B8@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E582C8E.3090202@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDC74B29@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E5D7078.7050502@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDD5CEE4@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E5E57DF.5070102@softarmor.com> In-Reply-To: <4E5E57DF.5070102@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] Long Followup to Thoughts on "Organization" in draft-ietf-drinks-spprov-09 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 16:03:51 -0000 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Wednesday, August 31, 2011 11:49 AM To: Cartwright, Ken Cc: drinks@ietf.org Subject: Re: Long Followup to Thoughts on "Organization" in draft-ietf-drin= ks-spprov-09 On 8/31/11 8:44 AM, Cartwright, Ken wrote: > > EPP, RFC 4930, also discusses how the login" command is used to > establish authenticated identity. > > KJC4: There is no "login" command in SPPP, because it uses Digest > Authentication, at the explicit request of one of the participants. > So there is no login command to talk about. I am certainly not > apposed to having an explicit "login" operation. But you would need > to convince others. I'm not proposing an explicit login. I AM proposing that the data payload carry the validated username, which appears to be the registrar identity. I'll propose in further detail below. KJK4: I've already indicated that I am ok either way on this. > Some discussion of "how it works" with SPPP might be useful. Oddly > enough, EPP transports the authentication identity in the payload, > rather than leaving it fully to the transport binding. > > KJC4: Yes, it does. Because it has a direct login type command, not > using digest authentication. Dean, we've addressed this point at > least 5 times now with me proposing what can be done about this. It still hasn't quite resolved to what I think might be robustly implementable. Here's a proposal: We need some way to tie the "username" from Digest auth with the request and with the underlying database. 1) Add rar back into the BasicObjType 2) Say that the username expressed in the Digest MUST be matched against the request's rar by local policy to determine whether local policy will authorize the request. KJC4: Exactly, if I understand what you are saying. This is the typical i= mplementation approach. This gives us a model where local policy could say that rar A can only manipulate stored records owned by rar A, or it could manipulate records owned by rar A, B, or C but not D, E, F and so on. In other words, a full range of flexibility. Alternatively, if we really believe that "rant" is the object owner, we have to do something like say that request-username (from Auth) is matched against the rant in the request via a mapping outside of the protocol and under control of local policy in order to decide on the authorization of the request. KJC4: Nope. But again the term "owner" is not defined. The terms are reg= istrar and registrant, which are defined and in wide use. Whether you call= the registrar the "owner" or the registrant the "owner" is up to you. > > In the SOAP binding document: > > The SPPP SOAP binding uses digest authentication over HTTPS as > specified in RFC 2617. The "username" parameter of the Authorization > header encodes the name of the registrar making the request, and MUST > be passed by the implementation along with the SOAP request body to > the application. Use of this username in the making of authorization > decisions is subject to local policy in the implementation. > > KJC4: The spec already has the first sentence in there. But I don't > think the rest of what you propose here is accurate. But we can > change what you propose to explain how digest authentication is/canBe > used to authorize (and therefore identify) the entity being > authorized, as is the case in all uses of Digest Authentication > (because that is what is exists to accomplish). ... Okay, what I have might need mods. But we need SOMETHING like it to pass security review. KJC4: Ok. -- Dean This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From kcartwright@tnsi.com Wed Aug 31 09:08:37 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9DC21F8D10 for ; Wed, 31 Aug 2011 09:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiuQ-kT9YKnW for ; Wed, 31 Aug 2011 09:08:36 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id BBB0521F8D0F for ; Wed, 31 Aug 2011 09:08:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0AAD1cXk6sEQfn/2dsb2JhbABDmGCQYYFAAQEEATo4BwwEAgEIEQQBAR8JBzIUCQgBAQQOBQiHarpehXVgBKRI X-IronPort-AV: E=Sophos;i="4.68,308,1312153200"; d="scan'208";a="164225" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 31 Aug 2011 17:10:06 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Wed, 31 Aug 2011 12:10:45 -0400 From: "Cartwright, Ken" To: Dean Willis Date: Wed, 31 Aug 2011 12:10:05 -0400 Thread-Topic: [drinks] security considerations... Thread-Index: Acxn9v2MpdtGTr6iR2ayF6e8McvFYgAAN22w Message-ID: <754963199212404AB8E9CFCA6C3D0CDA38DDD5D0F0@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4E5D719B.2020804@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDD5CF06@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E5E5A66.6070608@softarmor.com> In-Reply-To: <4E5E5A66.6070608@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] security considerations... X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 16:08:37 -0000 See response to your other email. The term "owner" is not relevant because= it is not defined. We need to use registrar (or at least SPPP client) and= registrant so that we know what we are talking about. And we _can_ say wh= ether access is controlled by the authentication credentials of the registr= ar, they of course are. See my response to your other email. Ken -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Wednesday, August 31, 2011 12:00 PM To: Cartwright, Ken Cc: Ali, Syed Wasim; drinks@ietf.org Subject: Re: [drinks] security considerations... On 8/31/11 8:53 AM, Cartwright, Ken wrote: >> Not according to what I think Ken is explaining to me. I think Ken >> is saying that the only authenticated party is the registrar, and >> that the registrar makes all requests on behalf of the registrant. >> Therefore it's the registrar who "owns", meaning "controls changes >> to" the data. > > KJC: Not correct, and not relevant. The concept of "ownership" here > is too vague to be valuable here. You continue to have difficulty > with the concept of registrar and registrant. Well apparently, Ken, I'm stupid. Quite possibly a lot of people who are going to read this spec are almost as stupid as I am. The protocol authors have to find a way to explain these simple concepts to us even simpler readers. So, how does a client anticipate whether or not it should have access to a given record on a server when we can't say whether access is controlled by the username in the digest auth's relationship to any specific element or set of elements in the data schema? -- Dean This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From kcartwright@tnsi.com Wed Aug 31 09:43:14 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657CD21F8D3A for ; Wed, 31 Aug 2011 09:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJjN4mS-IWY6 for ; Wed, 31 Aug 2011 09:43:13 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id B98B021F8D2A for ; Wed, 31 Aug 2011 09:43:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0AAHlkXk6sEQfn/2dsb2JhbABDmGCQYYFAAQEBAQIBAQEBNzQEBwwEAgEIEQQBAR8JBycLFAkIAQEEAQ0FCIdqBLpPhXVgBKRI X-IronPort-AV: E=Sophos;i="4.68,308,1312153200"; d="scan'208";a="164434" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 31 Aug 2011 17:44:43 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Wed, 31 Aug 2011 12:45:22 -0400 From: "Cartwright, Ken" To: "Cartwright, Ken" , Dean Willis Date: Wed, 31 Aug 2011 12:44:42 -0400 Thread-Topic: [drinks] security considerations... Thread-Index: Acxn9v2MpdtGTr6iR2ayF6e8McvFYgAAN22wAAFUC9A= Message-ID: <754963199212404AB8E9CFCA6C3D0CDA38DDD5D13E@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4E5D719B.2020804@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDD5CF06@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E5E5A66.6070608@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDD5D0F0@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA38DDD5D0F0@TNS-MAIL-NA.win2k.corp.tnsi.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] security considerations... X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 16:43:14 -0000 And btw, you're definitely not what you called yourself. Ken -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Cartwright, Ken Sent: Wednesday, August 31, 2011 12:10 PM To: Dean Willis Cc: drinks@ietf.org Subject: Re: [drinks] security considerations... See response to your other email. The term "owner" is not relevant because= it is not defined. We need to use registrar (or at least SPPP client) and= registrant so that we know what we are talking about. And we _can_ say wh= ether access is controlled by the authentication credentials of the registr= ar, they of course are. See my response to your other email. Ken -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Wednesday, August 31, 2011 12:00 PM To: Cartwright, Ken Cc: Ali, Syed Wasim; drinks@ietf.org Subject: Re: [drinks] security considerations... On 8/31/11 8:53 AM, Cartwright, Ken wrote: >> Not according to what I think Ken is explaining to me. I think Ken >> is saying that the only authenticated party is the registrar, and >> that the registrar makes all requests on behalf of the registrant. >> Therefore it's the registrar who "owns", meaning "controls changes >> to" the data. > > KJC: Not correct, and not relevant. The concept of "ownership" here > is too vague to be valuable here. You continue to have difficulty > with the concept of registrar and registrant. Well apparently, Ken, I'm stupid. Quite possibly a lot of people who are going to read this spec are almost as stupid as I am. The protocol authors have to find a way to explain these simple concepts to us even simpler readers. So, how does a client anticipate whether or not it should have access to a given record on a server when we can't say whether access is controlled by the username in the digest auth's relationship to any specific element or set of elements in the data schema? -- Dean This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From dean.willis@softarmor.com Wed Aug 31 09:45:48 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F6321F8D47 for ; Wed, 31 Aug 2011 09:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.434 X-Spam-Level: X-Spam-Status: No, score=-103.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4z9q0f0cwOXZ for ; Wed, 31 Aug 2011 09:45:48 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2EA21F8D44 for ; Wed, 31 Aug 2011 09:45:48 -0700 (PDT) Received: by gwb20 with SMTP id 20so271216gwb.31 for ; Wed, 31 Aug 2011 09:47:16 -0700 (PDT) Received: by 10.91.163.27 with SMTP id q27mr528970ago.46.1314809236410; Wed, 31 Aug 2011 09:47:16 -0700 (PDT) Received: from dwillis-mb1.local (cpe-66-25-15-110.tx.res.rr.com [66.25.15.110]) by mx.google.com with ESMTPS id e4sm7408839anb.15.2011.08.31.09.47.15 (version=SSLv3 cipher=OTHER); Wed, 31 Aug 2011 09:47:15 -0700 (PDT) Message-ID: <4E5E6592.9000402@softarmor.com> Date: Wed, 31 Aug 2011 11:47:14 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "Cartwright, Ken" References: <4E5D719B.2020804@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDD5CF06@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E5E5A66.6070608@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDD5D0F0@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA38DDD5D0F0@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "drinks@ietf.org" Subject: Re: [drinks] security considerations... X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 16:45:48 -0000 On 8/31/11 11:10 AM, Cartwright, Ken wrote: > See response to your other email. The term "owner" is not relevant > because it is not defined. We need to use registrar (or at least > SPPP client) and registrant so that we know what we are talking > about. And we _can_ say whether access is controlled by the > authentication credentials of the registrar, they of course are. See > my response to your other email. Ok, who is the authenticated actor that potentially is authorized to delete or update an existing object? I currently believe that actor to be the "registrar". The "registrant" is only a passive actor at best, or more properly a non-actor. I now believe rant is merely an attribute of the object. So, action authorization decisions are made on an object, under locally policy, based on the authenticated rar of the request. However, "rant" is what we store in the objects now, according to the current schema. We don't store "rar". So somewhere OpenSPP needs a table that says, for a given rant, whether or not a specific rar has action-rights on records tagged with that rant. The problem with this approach is that I think (based on earlier email) that we have a use case where this is insufficient for policy to make a determination. Here's the case: Rant Alice uses rars A and B. Some of the rant Alice records in the database were added by rar A. Some were added by rar B. A MUST be able to delete/update records that were initially added by A, but MUST NOT be able to delete/update records that were added by B. To handle this case, we need to know which records were added by A, and which by B, both of which were acting on behalf of rant Alice. The easiest way to do this is to add rar back into the schema for BasicObjType. Another alternative would be to have yet another table that relates each object to a locally-defined rar identifier. This is a lot more code, and an expensive "join" at run-time. It's much easier to add rar to the schema. -- Dean From kcartwright@tnsi.com Wed Aug 31 09:59:13 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF7021F8DAC for ; Wed, 31 Aug 2011 09:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SqciWfWApRq for ; Wed, 31 Aug 2011 09:59:13 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4176C21F8DA9 for ; Wed, 31 Aug 2011 09:59:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0AAO5nXk6sEQfn/2dsb2JhbABDmGCQYYFAAQEFOj8MBAIBCBEEAQEBHgkHMhQJCAEBBA4FCMI3hXVgBKRI X-IronPort-AV: E=Sophos;i="4.68,308,1312153200"; d="scan'208";a="164517" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 31 Aug 2011 18:00:42 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Wed, 31 Aug 2011 13:01:21 -0400 From: "Cartwright, Ken" To: Dean Willis Date: Wed, 31 Aug 2011 13:00:41 -0400 Thread-Topic: [drinks] security considerations... Thread-Index: Acxn/aX3lOXH2/yJRWqByxbMzbMYmgAABF6w Message-ID: <754963199212404AB8E9CFCA6C3D0CDA38DDD5D165@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4E5D719B.2020804@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDD5CF06@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E5E5A66.6070608@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDD5D0F0@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E5E6592.9000402@softarmor.com> In-Reply-To: <4E5E6592.9000402@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] security considerations... X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 16:59:14 -0000 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Wednesday, August 31, 2011 12:47 PM To: Cartwright, Ken Cc: Ali, Syed Wasim; drinks@ietf.org Subject: Re: [drinks] security considerations... On 8/31/11 11:10 AM, Cartwright, Ken wrote: > See response to your other email. The term "owner" is not relevant > because it is not defined. We need to use registrar (or at least > SPPP client) and registrant so that we know what we are talking > about. And we _can_ say whether access is controlled by the > authentication credentials of the registrar, they of course are. See > my response to your other email. Ok, who is the authenticated actor that potentially is authorized to delete or update an existing object? I currently believe that actor to be the "registrar". KJC: Correct. The "registrant" is only a passive actor at best, or more properly a non-actor. I now believe rant is merely an attribute of the object. So, action authorization decisions are made on an object, under locally policy, based on the authenticated rar of the request. KJC: Yes, and based on whether that rar has been authorized to manage and/= or view objects of the given registrant. However, "rant" is what we store in the objects now, according to the current schema. We don't store "rar". KJC: Not correct. The protocol does not specify everything that is "store= d". SPPP does not define the DB schema. You are free to store anything ad= ditional that you want. In my implementation, regardless of what is in the= protocol, I would store/track the rar that created each individual object.= And I would do this for multiple reasons, my authorization policies being= one of the main ones. So somewhere OpenSPP needs a table that says, for a given rant, whether or not a specific rar has action-rights on records tagged with that rant. KJC: Yes. Inside the implementation DB schema that needs to exist. The problem with this approach is that I think (based on earlier email) that we have a use case where this is insufficient for policy to make a determination. Here's the case: Rant Alice uses rars A and B. Some of the rant Alice records in the database were added by rar A. Some were added by rar B. A MUST be able to delete/update records that were initially added by A, but MUST NOT be able to delete/update records that were added by B. KJC: Ok, that is an authorization policy that your SPPP implementation has= decided that it wants to support. Fine, I'm following you. To handle this case, we need to know which records were added by A, and which by B, both of which were acting on behalf of rant Alice. KJC: Correct. The easiest way to do this is to add rar back into the schema for BasicObjT= ype. KJC: Not so. As stated above, the internal implementation needs to keep t= rack of the registrar that created each object. This has nothing to do wit= h whether or not the registrar ID is passed as an object level element over= theprotocol. Another alternative would be to have yet another table that relates each object to a locally-defined rar identifier. This is a lot more code, and an expensive "join" at run-time. It's much easier to add rar to the schema. KJC: No, that is not a lot more code. You would have to store this rar ID= under either approach (the rar ID in the protocol objects approach or the = rar ID not in the protocol objects approach). It is also not _required_ th= at the rarID that created an object be in a separate table. IN fact most p= eople would implement the rarID as a column of the object level table. -- Dean This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From kcartwright@tnsi.com Wed Aug 31 13:26:42 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA7621F8DE1 for ; Wed, 31 Aug 2011 13:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpJSmfY2oadl for ; Wed, 31 Aug 2011 13:26:41 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3C37B21F8E67 for ; Wed, 31 Aug 2011 13:26:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIAAEKZXk6sEQfn/2dsb2JhbABCmGOQYYFAAQEFOj8MBAIBCBEEAQEBHgkHMhQJCAEBBAENBQjCOYV1YASkSg X-IronPort-AV: E=Sophos;i="4.68,309,1312153200"; d="scan'208";a="165501" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 31 Aug 2011 21:28:04 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Wed, 31 Aug 2011 16:28:42 -0400 From: "Cartwright, Ken" To: "Cartwright, Ken" , Dean Willis Date: Wed, 31 Aug 2011 16:28:03 -0400 Thread-Topic: [drinks] security considerations... Thread-Index: Acxn/aX3lOXH2/yJRWqByxbMzbMYmgAABF6wAAeFpIA= Message-ID: <754963199212404AB8E9CFCA6C3D0CDA38DDD5D3A0@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4E5D719B.2020804@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDD5CF06@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E5E5A66.6070608@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDD5D0F0@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E5E6592.9000402@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] security considerations... X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 20:26:42 -0000 Just to be clear, the spec already says these things, among others that spe= ak directly to these items: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
All SPPP objects are associated with a registrant identifier. S= PPP Clients provision SPPP objects on behalf of registrants. An authenticate= d SPP Client is a registrar. Therefore, the SPPP transport protocol MUST p= rovide means for an SPPP server to authenticate an SPPP Client.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
After successful authentication of the SPPP client as a registra= r the registry performs authorization checks to determine if the registrar = is authorized to act on behalf of the Registrant whose identifier is included in the SPPP request. Ref= er to the Security Considerations section for further guidance. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
To achieve integrity andprivacy, conforming SPPP SOAP Clients and = Servers MUST support SOAP over HTTP over TLS [] a= s the secure transport mechanism. This combination of HTTP and TLS is refe= rred to as HTTPS. And to accomplish authentication conformaing SOAP SPPP C= lients and Servers MUST use HTTP Digest Authentication as defined in . As a result, the communication session is establishe= d through the initial HTTP connection setup, the digest authentication, and= the TLS handshake. When the HTTP connection is broken down, the communica= tion session ends.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: Cartwright, Ken Sent: Wednesday, August 31, 2011 1:01 PM To: 'Dean Willis' Cc: Ali, Syed Wasim; drinks@ietf.org Subject: RE: [drinks] security considerations... -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Wednesday, August 31, 2011 12:47 PM To: Cartwright, Ken Cc: Ali, Syed Wasim; drinks@ietf.org Subject: Re: [drinks] security considerations... On 8/31/11 11:10 AM, Cartwright, Ken wrote: > See response to your other email. The term "owner" is not relevant > because it is not defined. We need to use registrar (or at least > SPPP client) and registrant so that we know what we are talking > about. And we _can_ say whether access is controlled by the > authentication credentials of the registrar, they of course are. See > my response to your other email. Ok, who is the authenticated actor that potentially is authorized to delete or update an existing object? I currently believe that actor to be the "registrar". KJC: Correct. The "registrant" is only a passive actor at best, or more properly a non-actor. I now believe rant is merely an attribute of the object. So, action authorization decisions are made on an object, under locally policy, based on the authenticated rar of the request. KJC: Yes, and based on whether that rar has been authorized to manage and/= or view objects of the given registrant. However, "rant" is what we store in the objects now, according to the current schema. We don't store "rar". KJC: Not correct. The protocol does not specify everything that is "store= d". SPPP does not define the DB schema. You are free to store anything ad= ditional that you want. In my implementation, regardless of what is in the= protocol, I would store/track the rar that created each individual object.= And I would do this for multiple reasons, my authorization policies being= one of the main ones. So somewhere OpenSPP needs a table that says, for a given rant, whether or not a specific rar has action-rights on records tagged with that rant. KJC: Yes. Inside the implementation DB schema that needs to exist. The problem with this approach is that I think (based on earlier email) that we have a use case where this is insufficient for policy to make a determination. Here's the case: Rant Alice uses rars A and B. Some of the rant Alice records in the database were added by rar A. Some were added by rar B. A MUST be able to delete/update records that were initially added by A, but MUST NOT be able to delete/update records that were added by B. KJC: Ok, that is an authorization policy that your SPPP implementation has= decided that it wants to support. Fine, I'm following you. To handle this case, we need to know which records were added by A, and which by B, both of which were acting on behalf of rant Alice. KJC: Correct. The easiest way to do this is to add rar back into the schema for BasicObjT= ype. KJC: Not so. As stated above, the internal implementation needs to keep t= rack of the registrar that created each object. This has nothing to do wit= h whether or not the registrar ID is passed as an object level element over= theprotocol. Another alternative would be to have yet another table that relates each object to a locally-defined rar identifier. This is a lot more code, and an expensive "join" at run-time. It's much easier to add rar to the schema. KJC: No, that is not a lot more code. You would have to store this rar ID= under either approach (the rar ID in the protocol objects approach or the = rar ID not in the protocol objects approach). It is also not _required_ th= at the rarID that created an object be in a separate table. IN fact most p= eople would implement the rarID as a column of the object level table. -- Dean This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From dean.willis@softarmor.com Wed Aug 31 22:53:00 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB54621F8AF4 for ; Wed, 31 Aug 2011 22:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.138 X-Spam-Level: X-Spam-Status: No, score=-103.138 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHg2J2BhPIKG for ; Wed, 31 Aug 2011 22:53:00 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5393D21F8888 for ; Wed, 31 Aug 2011 22:53:00 -0700 (PDT) Received: by yie12 with SMTP id 12so1453086yie.31 for ; Wed, 31 Aug 2011 22:54:29 -0700 (PDT) Received: by 10.101.136.30 with SMTP id o30mr1092863ann.22.1314856469354; Wed, 31 Aug 2011 22:54:29 -0700 (PDT) Received: from dwillis-mb1.local (cpe-66-25-15-110.tx.res.rr.com [66.25.15.110]) by mx.google.com with ESMTPS id c5sm310736anh.1.2011.08.31.22.54.28 (version=SSLv3 cipher=OTHER); Wed, 31 Aug 2011 22:54:28 -0700 (PDT) Message-ID: <4E5F1E13.7050001@softarmor.com> Date: Thu, 01 Sep 2011 00:54:27 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: "Cartwright, Ken" References: <4E5D719B.2020804@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDD5CF06@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E5E5A66.6070608@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDD5D0F0@TNS-MAIL-NA.win2k.corp.tnsi.com> <4E5E6592.9000402@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA38DDD5D165@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA38DDD5D165@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "drinks@ietf.org" Subject: Re: [drinks] security considerations... X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 05:53:01 -0000 On 8/31/11 12:00 PM, Cartwright, Ken wrote: > > KJC: Not correct. The protocol does not specify everything that is > "stored". SPPP does not define the DB schema. You are free to > store anything additional that you want. In my implementation, > regardless of what is in the protocol, I would store/track the rar > that created each individual object. And I would do this for > multiple reasons, my authorization policies being one of the main > ones. The protocol does define the XSD which in turn defines OpenSPP's programatically-generated inter-layer messaging, and in some cases the actual database schema or parts thereof. Jeremy can add details on this; perhaps I'm off-base. My gSOAP code definitely uses the data types defined programatically by gSOAP from the XSD. I can certainly add parallel tables and messages, but it'sa a lot easier to piggyback on the tool's automatic plumbing when the auth_ID is in the payload. -- Dean