From spkm-bounces@ietf.org Tue Feb 06 20:14:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEbOi-00069G-6c; Tue, 06 Feb 2007 20:14:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEbOh-00069B-J1 for spkm@ietf.org; Tue, 06 Feb 2007 20:14:55 -0500 Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEbOd-0000Ul-2o for spkm@ietf.org; Tue, 06 Feb 2007 20:14:55 -0500 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 6 Feb 2007 17:14:50 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) with Microsoft SMTP Server id 8.0.685.25; Tue, 6 Feb 2007 17:09:16 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Tue, 6 Feb 2007 17:09:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Feb 2007 17:09:15 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SPKM Design Team Meeting Notes Thread-index: AcdKVJWPkb8avolDTLqQ1ZvcoSbvdw== From: "Liqiang(Larry) Zhu" To: X-OriginalArrivalTime: 07 Feb 2007 01:09:16.0427 (UTC) FILETIME=[96652DB0:01C74A54] X-Spam-Score: 0.0 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 Cc: Sam Hartman Subject: [SPKM] SPKM Design Team Meeting Notes X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0401770283==" Errors-To: spkm-bounces@ietf.org --===============0401770283== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C74A54.96218146" ------_=_NextPart_001_01C74A54.96218146 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 1/16/2007, the SPKM design team Larry Zhu, Nicolas Williams and Olga Kornievskaia had a conf call that was aimed to produce a comparison of PkU2U and the TLS mechanism for the community so the community can decide between them. =20 Here is the list of things that came up: =20 PKU2U has a draft, hence the description is omitted here. =20 PKU2U Pros: ---------- 1) Kerberos alike, easy to implement for folks who already have a PKINIT and a Kerberos implementation 2) one less round trip per handle-shake =20 =20 PKU2U Cons: ---------- 1) not easier than TLS approach for folks who do not have a PKINIT implementation 2) this is a new mechanism =20 TLS approach currently does not have a draft. Here is a brief description: at high level, it can be based on TLS or Datagram TLS. And per-message tokens are based on RFC4121, in the same way how PKU2U per-message tokens work. =20 TLS approach Pros: ----------------- 1) this is based on an existing mechanism that is mature 2) this is the single mechanism for certificate-based peer to peer authentication mechanism. 3) open source TLS implementations are available =20 TLS approach Cons: ------------------ 1)at least 2 extra messages (one extra roundtrip) per handshake =20 =20 The design team discussed the differences in encoding of the context-establishment tokens employed by these two approaches, and did not believe the differences are significant to make one preferable over the other. =20 Olga raised objections to PKU2U on the ground it is dependent on Kerberos. She also considered the PKU2U ID underspecified and significant work need to be done to wrap up PKU2U. =20 The design team acknowledged that common problems exist such as GSS-API naming based on distinguished names, channel bindings, certificate selections, and credentials managements. =20 --Larry =20 ------_=_NextPart_001_01C74A54.96218146 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

On 1/16/2007, the SPKM design team Larry Zhu, = Nicolas Williams and Olga Kornievskaia had a conf call that was aimed to produce = a comparison of PkU2U and the TLS mechanism for the community so the = community can decide between them.

 

Here is the list of things that came = up:

 

PKU2U has a draft,  hence the description = is omitted here.

 

PKU2U Pros:

----------

1) Kerberos alike, easy to implement for folks = who already have a PKINIT and a Kerberos implementation

2) one less round trip per = handle-shake

 

 

PKU2U Cons:

----------

1) not easier than TLS approach for folks who do = not have a PKINIT implementation

2) this is a new mechanism

 

TLS approach currently does not have a draft. = Here is a brief description: at high level, it can be based on TLS or Datagram = TLS. And per-message tokens are based on RFC4121, in the same way how PKU2U = per-message tokens work.

 

TLS approach Pros:

-----------------

1) this is based on an existing mechanism that = is mature

2) this is the single mechanism for = certificate-based peer to peer authentication mechanism.

3) open source TLS implementations are = available

 

TLS approach Cons:

------------------

1)at least 2 extra messages (one extra = roundtrip) per handshake

 

 

The design team discussed the differences in = encoding of the context-establishment tokens employed by these two approaches, and = did not believe the differences are significant to make one preferable over the = other.

 

Olga raised objections to PKU2U on the ground it = is dependent on Kerberos. She also considered the PKU2U ID underspecified = and significant work need to be done to wrap up PKU2U.

 

The design team acknowledged that common = problems exist such as GSS-API naming based on distinguished names, channel bindings, certificate selections, and credentials managements.

 

--Larry

 

------_=_NextPart_001_01C74A54.96218146-- --===============0401770283== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm --===============0401770283==-- From spkm-bounces@ietf.org Wed Feb 07 16:28:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEuLR-0005Qt-9v; Wed, 07 Feb 2007 16:28:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEuLQ-0005Qc-Gy for spkm@ietf.org; Wed, 07 Feb 2007 16:28:48 -0500 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEuLM-00065Q-Jd for spkm@ietf.org; Wed, 07 Feb 2007 16:28:48 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 76832E00B3; Wed, 7 Feb 2007 16:28:42 -0500 (EST) From: Sam Hartman To: "Liqiang(Larry) Zhu" Subject: Re: [SPKM] SPKM Design Team Meeting Notes References: Date: Wed, 07 Feb 2007 16:28:42 -0500 In-Reply-To: (Liqiang Zhu's message of "Tue, 6 Feb 2007 17:09:15 -0800") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: spkm@ietf.org X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org Thanks Larry. I guess some of you are wondering why you never saw an announcement of a design team before their report. That's my fault. I had originally hoped to get a design team together to select between the four mechanisms presented at the BOF. However talking to Andy and some people who had talked to Andy, it seemed like the NFS folks might benefit more from a quick decision than from a protracted discussion. I suggested that if they were willing to join the design team and if they were willing to limit the options to the TLS and PKU2U mechanisms we could quickly come to consensus and move forward. Unfortunately, one of the people I asked to serve on the design team declined to do so citing work time commitment and lack of faith in the process. I didn't feel that Nico, Larry and Olga were representative enough to actually pick an option, but I did feel that they would do a great job of summarizing the differences. I'd like to think them for doing that; I think they've done a great job of what they were asked to do. Sadly, we're in sort of a bind. 1) The updated SPKM spec clearly needs work before it can be considered. No one besides the original authors has stepped forward indicating interest in doing that work. I do believe that we need some additional eyes on that document if we were going to consider it. 2) I've been unable to get a group together that I feel is representative enough to choose a direction. I do not know how to proceed at this point. --Sam _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Wed Feb 07 18:39:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEwNv-0006xw-U9; Wed, 07 Feb 2007 18:39:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEwNu-0006xj-GQ for spkm@ietf.org; Wed, 07 Feb 2007 18:39:30 -0500 Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEwNr-0007In-3v for spkm@ietf.org; Wed, 07 Feb 2007 18:39:30 -0500 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l17NdQEH000819 for ; Wed, 7 Feb 2007 15:39:26 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l17NdQUP010537 for ; Wed, 7 Feb 2007 16:39:26 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l17NcsUH004090; Wed, 7 Feb 2007 17:38:54 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.6+Sun/8.13.6/Submit) id l17NcrT5004089; Wed, 7 Feb 2007 17:38:53 -0600 (CST) Date: Wed, 7 Feb 2007 17:38:53 -0600 From: Nicolas Williams To: "Liqiang(Larry) Zhu" Subject: Re: [SPKM] SPKM Design Team Meeting Notes Message-ID: <20070207233853.GN28618@binky.Central.Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Sam Hartman , spkm@ietf.org X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Tue, Feb 06, 2007 at 05:09:15PM -0800, Liqiang(Larry) Zhu wrote: > TLS approach Cons: > > ------------------ > > 1)at least 2 extra messages (one extra roundtrip) per handshake Actually, it's exactly three round-trips. Even with fragmentation (fragmentation doesn't add round-trips -- the GSS mechanism has to gather the fragments into one token). That said, I am currently not able to devote enough time to GSS-TLS. To be fair to you, unless someone else pops up to do that work I will support PKU2U instead. > The design team acknowledged that common problems exist such as GSS-API > naming based on distinguished names, channel bindings, certificate > selections, and credentials managements. Yes. Nico -- _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Wed Feb 07 19:00:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEwhn-00061x-1U; Wed, 07 Feb 2007 19:00:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEwhm-00061N-Ee for spkm@ietf.org; Wed, 07 Feb 2007 19:00:02 -0500 Received: from smtp1.su.se ([130.237.162.112]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HEwhl-0005PZ-3V for spkm@ietf.org; Wed, 07 Feb 2007 19:00:02 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id EA8F5746B1; Thu, 8 Feb 2007 00:59:52 +0100 (CET) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 22671-01-67; Thu, 8 Feb 2007 00:59:52 +0100 (CET) Received: from [192.168.0.160] (CPE-58-166-71-213.nsw.bigpond.net.au [58.166.71.213]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id C80F2746A9; Thu, 8 Feb 2007 00:59:50 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= Subject: Re: [SPKM] SPKM Design Team Meeting Notes Date: Thu, 8 Feb 2007 10:59:39 +1100 To: Sam Hartman X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.647 tagged_above=-99 required=7 tests=[AWL=0.018, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: spkm@ietf.org X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org > Sadly, we're in sort of a bind. > > 1) The updated SPKM spec clearly needs work before it can be > considered. No one besides the original authors has stepped > forward indicating interest in doing that work. I do believe that > we need some additional eyes on that document if we were going to > consider it. I think the SPKM document is broken enough there is no reason update it. Just start over, either using DTLS, rewritten SPKM or Larrys KRB5 thingy. > 2) I've been unable to get a group together that I feel is > representative enough to choose a direction. > > I do not know how to proceed at this point. Love _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Wed Feb 07 19:52:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HExWc-0003ID-9A; Wed, 07 Feb 2007 19:52:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HExWb-0003I5-7t for spkm@ietf.org; Wed, 07 Feb 2007 19:52:33 -0500 Received: from currant.srv.cs.cmu.edu ([128.2.194.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HExWY-0005gr-D6 for spkm@ietf.org; Wed, 07 Feb 2007 19:52:33 -0500 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l180qSS6017333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Feb 2007 19:52:29 -0500 (EST) Date: Wed, 07 Feb 2007 19:52:28 -0500 From: Jeffrey Hutzelman To: Nicolas Williams , "Liqiang(Larry) Zhu" Subject: Re: [SPKM] SPKM Design Team Meeting Notes Message-ID: In-Reply-To: <20070207233853.GN28618@binky.Central.Sun.COM> References: <20070207233853.GN28618@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:0158totlEz3SozFuA3GkmYJX49n+Fu/+FUQJYbHUs=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Sam Hartman , spkm@ietf.org, Jeffrey Hutzelman X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Wednesday, February 07, 2007 05:38:53 PM -0600 Nicolas Williams wrote: > That said, I am currently not able to devote enough time to GSS-TLS. To > be fair to you, unless someone else pops up to do that work I will > support PKU2U instead. This is an important point, and it's not unique to GSS-TLS. All of the proposals that have been brought forward require real work. It's not fair or realistic to expect that all of that work will be done by their respective authors. Additionally, I will note that none of these proposals is so hand-wavy that its editorship cannot be taken up by someone other than its original author, provided there are people willing to do the work. So, regardless of the direction we take, the chance of success will depend heavily on how many people are willing to participate actively in the work, not just reviewing documents and shouting down bad ideas, but actually contributing design ideas and text and maybe even serving as an editor. I would like to see some indication of who might be willing to participate at that level, for each of these proposals. There's no point in choosing an approach that no one is willing to work on, and IMHO any of the choices available to us would be better than nothing. -- Jeff _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Wed Feb 28 00:33:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMHRB-0001L5-MB; Wed, 28 Feb 2007 00:33:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMHRA-0001Gp-OR for spkm@ietf.org; Wed, 28 Feb 2007 00:33:12 -0500 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMHR7-0007Ho-BN for spkm@ietf.org; Wed, 28 Feb 2007 00:33:12 -0500 Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 27 Feb 2007 21:33:08 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) with Microsoft SMTP Server id 8.0.685.25; Tue, 27 Feb 2007 21:33:08 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Tue, 27 Feb 2007 21:33:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C75AF9.ED0CBB90" Date: Tue, 27 Feb 2007 21:33:05 -0800 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-zhu-pku2u-01.txt Thread-Index: AcdayuPiklf2umG8SviBgv6m4k+JnQALobTQ From: "Liqiang(Larry) Zhu" To: , , Nicolas Williams , , , X-OriginalArrivalTime: 28 Feb 2007 05:33:08.0402 (UTC) FILETIME=[EDA99920:01C75AF9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: Subject: [SPKM] FW: I-D ACTION:draft-zhu-pku2u-01.txt X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org ------_=_NextPart_001_01C75AF9.ED0CBB90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is the updated PKU2U. Please review it and see if it has addressed all concerns. Thanks, --Larry -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Tuesday, February 27, 2007 3:50 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-zhu-pku2u-01.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Public Key Cryptography Based User-to-User Authentication - (PKU2U) Author(s) : L. Zhu, et al. Filename : draft-zhu-pku2u-01.txt Pages : 10 Date : 2007-2-27 =09 This document defines the public key cryptography based user-to-user authentication protocol - PKU2U. This mechanism provides security services in peer to peer networking environments without requiring a trusted third party. Furthermore, the binding of PKU2U for the Generic Security Service Application Program Interface (GSS-API) per RFC2743 is defined based on RFC4121. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zhu-pku2u-01.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-zhu-pku2u-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zhu-pku2u-01.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C75AF9.ED0CBB90 Content-Type: application/octet-stream; name="ATT1891765.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT1891765.TXT Content-Disposition: attachment; filename="ATT1891765.TXT" Q29udGVudC1UeXBlOiBtZXNzYWdlL2V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPW1haWwtc2Vy dmVyOw0KCXNlcnZlcj0ibWFpbHNlcnZAaWV0Zi5vcmciDQoNCkNvbnRlbnQtVHlwZTogdGV4dC9w bGFpbg0KQ29udGVudC1JRDogPDIwMDctMi0yNzE1NTAzNi5JLURAaWV0Zi5vcmc+DQoNCkVOQ09E SU5HIG1pbWUNCkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16aHUtcGt1MnUtMDEudHh0DQo= ------_=_NextPart_001_01C75AF9.ED0CBB90 Content-Type: application/octet-stream; name="draft-zhu-pku2u-01.URL" Content-Transfer-Encoding: base64 Content-Description: draft-zhu-pku2u-01.URL Content-Disposition: attachment; filename="draft-zhu-pku2u-01.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC16aHUtcGt1MnUtMDEudHh0DQo= ------_=_NextPart_001_01C75AF9.ED0CBB90 Content-Type: text/plain; name="ATT1891766.txt" Content-Transfer-Encoding: base64 Content-Description: ATT1891766.txt Content-Disposition: attachment; filename="ATT1891766.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C75AF9.ED0CBB90 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm ------_=_NextPart_001_01C75AF9.ED0CBB90--