更多相关文档[][][][][][]
Forwarded mail.... (fwd)
(William P. O'Bryan)
Subject: Forwarded mail.... (fwd)
From: Melanie S. Irvin &&
Date: Wed, 1 Feb 95 1:02:12 EST
Cc: eng3dbh
Forwarded message:
&From mac4bww Tue Jan 31 21:22:59 1995
Subject: Forwarded mail.... (fwd)
To: mac4msi (Melanie S. Irvin)
Date: Tue, 31 Jan 95 21:22:58 EST
From: Brian W. Whitson &mac4bww&
X-Mailer: ELM-MIME [version 1.0 PL0]
Forwarded message:
&From ted4adp Tue Jan 31 16:43:42 1995
Subject: Forwarded mail.... (fwd)
To: mac4bww (Brian W. Whitson)
Date: Tue, 31 Jan 95 16:43:39 EST
From: Amy D. Petersek &ted4adp&
X-Mailer: ELM-MIME [version 1.0 PL0]
Forwarded message:
&From eng4dgb at hibbs.vcu.edu Thu Jan 26 13:57:24 1995
Message-Id: &.AA28794 at hibbs.vcu.edu&
Subject: Forwarded mail.... (fwd)
To: ted4adp
Date: Thu, 26 Jan 95 13:57:22 EST
From: Donna G. Bryant &eng4dgb at hibbs.vcu.edu&
X-Mailer: ELM-MIME [version 1.0 PL0]
Forwarded message:
&From rarust at hamlet.uncg.edu Thu Jan 26 12:40:24 1995
Date: Thu, 26 Jan :16 -0500 (EST)
From: &Rachel A. Rust& &rarust at hamlet.uncg.edu&
X-Sender: rarust at hamlet
To: Donna Bryant &eng4dgb&
Cc: larson at turing.uncg.edu
Subject: Forwarded mail.... (fwd)
Message-Id: &Pine.SOL.3.91..2 at hamlet&
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
---------- Forwarded message ----------
Date: Wed, 25 Jan :07 -0500 (EST)
From: JAMES D. SPROUSE &jdsprous at hamlet.uncg.edu&
To: &Rachel A. Rust& &rarust at hamlet.uncg.edu&
Subject: Forwarded mail.... (fwd)
---------- Forwarded message ----------
Date: Mon, 23 Jan :30 -0500 (EST)
From: Heather A. Worthington &haworthi at hamlet.uncg.edu&
To: jdsprous at hamlet.uncg.edu
Subject: Forwarded mail.... (fwd)
---------- Forwarded message ----------
Date: Mon, 23 Jan :40 -0500 (EST)
From: Jill Renee Snyder &jrs12 at acpub.duke.edu&
To: heather worthington &haworthi at hamlet.uncg.edu&
Subject: Forwarded mail.... (fwd)
---------- Forwarded message ----------
Date: Sun, 22 Jan :40 -0500 (EST)
From: Sonal Dinesh Thekdi &sdt1 at acpub.duke.edu&
To: Michael Adam Bolch &mab8 at acpub.duke.edu&
Cc: Jill Renee Snyder &jrs12 at acpub.duke.edu&
Subject: Forwarded mail.... (fwd)
---------- Forwarded message ----------
Date: Sun, 22 Jan :30 -0500 (EST)
From: Lindsay Brooke Renner &lbr1 at acpub.duke.edu&
To: Sonal Dinesh Thekdi &sdt1 at acpub.duke.edu&
Subject: Forwarded mail.... (fwd)
Now you have it!
I HATE chain letters, don't you.
this one is easier than most because you only have to forward it instead
of making copies and sending them through the mail.
Sorry anyways!
---------- Forwarded message ----------
Date: Thu, 19 Jan 95 11:32:39 EST
From: Jennifer Lea Rhawn &jlr7y at curry.edschool.virginia.edu&
To: lbr1 at acpub.duke.edu
Cc: dancap at aol.com
Subject: Forwarded mail.... (fwd)
I'm out to plague your life now.
I haven't sent a chain
mail letter in ages, but I thought you might enjoy this!
Jenn Rhawn
According to Kristen Marie Anonick:
& From kma3x Sun Nov 13 15:28:19 1994
& From: Kristen Marie Anonick &kma3x&
& Message-Id: &.PAA45766 at curry.edschool.Virginia.EDU&
& Subject: Forwarded mail.... (fwd)
& To: jmm3u at Virginia.EDU (Julia MacMillan)
& Date: Sun, 13 Nov 94 15:28:18 EST
& Cc: jlr7y (Jennifer Rhawn)
& X-Mailer: ELM [version 2.3.1 PL11]
& According to Teresa Lynn Divers:
& &From daemon Mon Nov
7 15:12:49 1994
& From: Teresa Lynn Divers &tld6h at fermi.clas.Virginia.EDU&
& Message-Id: &.PAA114431 at fermi.clas.Virginia.EDU&
& Subject: Forwarded mail.... (fwd)
& To: tdd2n at curry.edschool.Virginia.EDU (Todd Douglas Divers)
& Date: Mon, 7 Nov 94 15:12:47 EST
& Cc: kma3x at curry.edschool.Virginia.EDU (Kristen Marie Anonick),
bem2b at uva.pcmail.virginia.edu (Brooke McMinn),
mjallard at mail.vt.edu (Jonathan Mallard)
& X-Mailer: PENELM [version 2.3.1 PL11]
& According to Theodora Lippitt Gongaware:
& &From daemon Mon Nov
7 13:31:14 1994
& Resent-From: &Leslie D. Edwards& &lpe8y at uva.pcmail.virginia.edu&
& Resent-Date: Mon, 7 Nov 94 12:53:06 EST
& X-Mailer: UVa PCMail 1.7.1
& Resent-To: tld6h at fermi.clas.virginia.edu
& Resent-Date: Sat, 5 Nov :25 -0500
& Resent-From: djm5a at uva.pcmail.virginia.edu
& Resent-Message-Id: &.PAA02014 at uva.pcmail.Virginia.EDU&
& X-Mailer: Mail User's Shell (7.2.3 5/22/91)
& Resent-To: lpe8y at uva.pcmail.virginia.edu
& Date: Thu, 3 Nov :41 -0500 (EST)
& From: Theodora Lippitt Gongaware &theodora at phoenix.princeton.edu&
& To: djm5a at virginia.edu
& Subject: Forwarded mail.... (fwd)
& Message-Id: &Pine.SUN.3.90..1 at phoenix.Princeton.EDU&
& Mime-Version: 1.0
& Content-Type: TEXT/PLAIN; charset=US-ASCII
& ---------- Forwarded message ----------
& Date: Sun, 30 Oct :18 -0400 (EDT)
& From: Allyson Chari Goldstein &allysong at phoenix&
& To: theodora at princeton.edu
& Subject: Forwarded mail....
& ---------- Forwarded message ----------
& Date: Thu, 27 Oct :11 -0500
& From: Elissa M. Blum &emblum at afar.med.cornell.edu&
& To: allysong at Princeton.EDU
#\//|* *|\\
#\//|* *|\\
#\//|* *|\\
.#---'| |----.
.#---'| |----.
.#---'| |----.
#----' -----'
#----' -----'
#----' -----'
& &&& && This message has been sent to you for good luck. The original
& &&& && is in New England.
It has been sent around the world nine times. The
& &&& && luck has now been sent to you.You will receive good luck within four
& &&& && days of receiving this message - Provided you, in turn send it on.
& &&& && This is no joke. You will receive good luck in the mail. But no
& &&& && money.
& &&& && Send copies to people you think need good luck. Don't send money as
& &&& && fate has no price.Do not keep this message. This message must leave
& &&& && your hands in 96 hours.
& &&& && A United States Air Force Officer received 470,000 Dollars.
& &&& && Another Man received 40,000 Dollars and lost it because he broke the
& &&& && chain.
& &&& && Whereas in the Philippines, Gene Welch lost his wife 51 days after
& &&& && receiving the message. He failed to circulate the message. However,
& &&& && before his death, he received 7,555,000 dollars.
& &&& && Please send twenty copies and see what happen in four days.
& &&& && The chain comes from Venezuela and has written by Saul De Groda,
& &&& && A Missionary from South America. Since the copy must tour
& &&& && the world, you must make twenty copies and send them to friends and
& &&& && associates - After a few days you will get a surprise
& &&& && This is true, even if you are not superstitious.
& &&& && Do not the following: Constantine Dias received this chain in 1958.
& &&& && He asked his secretary to make twenty copies and send them out. A few
& &&& && days later he won a lottery of two million dollars. Carlos Daditt, an
& &&& && office employee, received the message and forgot that it had to leave his
& &&& && hands in 96 hours.He lost his job.
& &&& && Later, after finding that message again, He mailed twentycopies. A
& &&& && few days later he got a better job.
Dalan Fairchild recege
& &&& && and, not believing - Threw the message away. Nine days later he died.
& &&& && In 1987, The message received by a young woman in California
& &&& && was very faded and barely readable. She promised herself that she
& &&& && would retype the message and send it on, But she t leave her hands within
& &&& &&hours. She finally typed
& &&& && the letter as promised and got a new car.
& &&& && Good Luck but please remember: 20 copies of this message must leave
& &&& && your hands in
96 hours... You must not sign on this message...
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13581;
1 Feb 95 21:04 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13577;
1 Feb 95 21:04 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa21063;
1 Feb 95 21:04 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id &UAA25324 at pad-thai.cam.ov.com&; Wed, 1 Feb :47 -0500
Received: from YAZ-PISTACHIO.MIT.EDU by MIT.EDU with SMTP
id AA02522; Wed, 1 Feb 95 20:33:41 EST
Received: by yaz-pistachio.MIT.EDU (5.57/4.7) id AA20362; Wed, 1 Feb 95 20:33:39 -0500
Message-Id: &.AA20362 at yaz-pistachio.MIT.EDU&
To: &John Wray, Digital DPE,
(508) 486-5210 01-Feb-& &wray at tuxedo.enet.dec.com&
Cc: danisch at ira.uka.de, cat-ietf at mit.edu
Subject: Re: Anonymity by mechanism ?
In-Reply-To: Your message of &Wed, 01 Feb :55 EST.&
&.AA11778 at us1rmc.bb.dec.com&
Date: Wed, 01 Feb :37 EST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Marc Horowitz &marc at mit.edu&
&& Or it could ignore out-of-sequence major-status codes completely (I
&& believe they're supposed to be informational, so that the other output
&& parameters from GSSAPI functions should still be valid).
If RFC-1509
&& doesn't explicitly state this, I think that the new version should.
&& Does anyone have any problem with this?
They are currently not informational.
I've been saying for months
that they should be (and I think you were disagreeing with me, but if
you're changing your mind, I'm not going to hold you to your old
opinion :-), and that rfc1508 should be updated to say so.
I'd change the sequencing indicators to be supplementary info bits in
the C bindings.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22322;
2 Feb 95 0:18 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22318;
2 Feb 95 0:18 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa24079;
2 Feb 95 0:18 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id &XAA28910 at pad-thai.cam.ov.com&; Wed, 1 Feb :28 -0500
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA13213; Wed, 1 Feb 95 23:50:00 EST
Received: by dcl.MIT.EDU (5.0/4.7) id AA28398; Wed, 1 Feb :01 +0500
Date: Wed, 1 Feb :01 +0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o &tytso at mit.edu&
Message-Id: &.AA28398 at dcl.MIT.EDU&
To: danisch at ira.uka.de
Cc: danisch at ira.uka.de, wray at tuxedo.enet.dec.com, cat-ietf at mit.edu
In-Reply-To: Hadmut Danisch's message of Wed, 1 Feb :10 --100,
&.AA02126 at elysion.iaks.ira.uka.de&
Subject: Re: Anonymity by mechanism ?
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Content-Length: 810
Date: Wed, 1 Feb :10 --100
From: danisch at ira.uka.de (Hadmut Danisch)
& GSSAPI would certainly support this, but it would all be hidden from the
& application programmer, and it would all be localized in the GSSAPI
& mechanism implementation.
If a mechanism wants to constantly be
& negotiating new subkeys to protect messages sent via gss_seal(), that's
& certainly the mechanism's perogatative.
I do not agree with that (at least at the moment :-)
This model forces the application using GSSAPI to use a linear logical
structure.
Well, that just means that you have sequencing, which is a GSSAPI
provided service.
You're right that if you want to be able to accept
messages out of order, constantly changing subkeys would tend to defeat
this goal.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00642;
2 Feb 95 5:00 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00636;
2 Feb 95 5:00 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01804;
2 Feb 95 5:00 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00605;
2 Feb 95 5:00 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00538;
2 Feb 95 4:45 EST
Received: from nova.unix.portal.com by CNRI.Reston.VA.US id aa01567;
2 Feb 95 4:45 EST
Received: from jobe.shell.portal.com (dwm at jobe.shell.portal.com [156.151.3.4]) by nova.unix.portal.com (8.6.9/8.6.5) with ESMTP id BAA24252; Thu, 2 Feb :45 -0800
Received: (dwm at localhost) by jobe.shell.portal.com (8.6.9/8.6.5) id BAA25384; Thu, 2 Feb :44 -0800
Date: Thu, 2 Feb :43 -0800 (PST)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: David - Morris &dwm at shell.portal.com&
To: Jerry Peek &jerry at ora.com&
cc: ietf at CNRI.Reston.VA.US
Subject: Re: URLs for RFCs and more (sigh!) on HTML RFCs
In-Reply-To: &.LAA02124 at ruby.ora.com&
Message-ID: &Pine.SUN.3.90..2 at jobe.shell.portal.com&
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 1 Feb 1995, Jerry Peek wrote:
& One easy thing to do, for a start, is to make that URL a *navigation*
& document that points to *instances of* the RFC.
Also, if an RFC needed
& to be updated, the navigation document could be modified to point to
& This would make life a lot easier for casual RFC users, like me,
& who don't know what the latest versions are.
A great idea ... I second third forth etc the suggestion.
David Morris
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01299;
2 Feb 95 7:11 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01291;
2 Feb 95 7:11 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03492;
2 Feb 95 7:11 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01268;
2 Feb 95 7:11 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01188;
2 Feb 95 7:08 EST
Received: from mail02.mail.aol.com by CNRI.Reston.VA.US id aa03428;
2 Feb 95 7:08 EST
Received: by mail02.mail.aol.com
(1.38.193.5/16.2) id AA01085; Thu, 2 Feb :42 -0500
Date: Thu, 2 Feb :42 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Telford001 at aol.com
Message-Id: &_ at aol.com&
To: snmpv2 at tis.com, snmp at psi.com, egypt-net at cs.sunysb.edu, iab at isi.edu,
ietf at CNRI.Reston.VA.US, anf-announce at netcom.com, anf-disc at netcom.com,
ipng at sunroof.eng.sun.com, rolc at maelstrom.acton.timeplex.com,
cisco at spot.colorado.edu
Cc: Telford001 at aol.com, Joseph_S._Ayoub at gmlaw.com
Subject: Severance of Relationships
As of January 26, 1995,
Telford Tools, Inc.,
formerly known as
Tudor Technology, Inc.
a Massachusetts corporation in good standing,
which was founded in 1993
Joachim Martillo
which sells
services related to software development and network debugging
as well as
communications equipment
has severed all relationships with
Penril Datability Networks,
Penril Datacomm Networks, Inc
Penril Datacomm, Inc.
All inquiries should be directed to:
Telford001 at aol.com
617-298-1617
617-298-1745
US-MAIL: 17 Pleasant Hill Avenue
Dorchester, MA
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01309;
2 Feb 95 7:11 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01296;
2 Feb 95 7:11 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03494;
2 Feb 95 7:11 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01269;
2 Feb 95 7:11 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01190;
2 Feb 95 7:08 EST
Received: from mail04.mail.aol.com by CNRI.Reston.VA.US id aa03433;
2 Feb 95 7:08 EST
Received: by mail04.mail.aol.com
(1.37.109.11/16.2) id AA; Thu, 2 Feb :41 -0500
Date: Thu, 2 Feb :41 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Telford001 at aol.com
Message-Id: &_ at aol.com&
To: snmpv2 at tis.com, snmp at psi.com, egypt-net at cs.sunysb.edu, iab at isi.edu,
ietf at CNRI.Reston.VA.US, anf-announce at netcom.com, anf-disc at netcom.com,
ipng at sunroof.eng.sun.com, rolc at maelstrom.acton.timeplex.com,
cisco at spot.colorado.edu, jcurran at nic.near.net, nomcom at nic.near.net
Cc: Telford001 at aol.com, Joseph_S._Ayoub at gmlaw.com
Subject: Announcement
As of January 26, 1995,
Joachim Martillo
(Joachim Carlo Santos Martillo Ajami)
Manager of Internetworking Research
Penril Datability Networks
190 North Main Street
Natick, MA 01760
Corporate Headquarters
1300 Quince Orchard Boulevard
Gaithersburg, Maryland
no longer works for
Penril Datability Networks.
Joachim Martillo may be reached as follows:
617-298-4107
martillo at delphi.com
US-MAIL: 15 Pleasant Hill Ave
Dorchester, MA
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03209;
2 Feb 95 10:16 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03205;
2 Feb 95 10:16 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa07137;
2 Feb 95 10:16 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id &JAA07796 at pad-thai.cam.ov.com&; Thu, 2 Feb :41 -0500
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA24679; Thu, 2 Feb 95 09:27:47 EST
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.6.8/) with SMTP
id &JAA07566 at pad-thai.cam.ov.com&; Thu, 2 Feb :38 -0500
Received: by winkl.cam.ov.com (4.1/4.7) id AA18079; Thu, 2 Feb 95 09:30:25 EST
Message-Id: &.AA18079 at winkl.cam.ov.com&
To: Dan Nessett &Danny.Nessett at eng.sun.com&
Cc: jim at bilbo.suite.com, kerberos at mit.edu, cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: Interoperability questions regarding the Kerberos GSS-API Mechanism
In-Reply-To: Your message of &Wed, 01 Feb :46 PST.&
&.OAA05923 at elrond.ss-eng.eng.sun.com&
Date: Thu, 02 Feb :24 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn &linn at cam.ov.com&
Dan writes:
&Unfortunately, it is very hard to guess whether this sort of replay detection
&would be appropriate for all apps. Consequently, I am currently of the
&opinion that both GSSAPI and Kerberos should provide a way for an application
&to provide a sequence number on a seal/mk_priv and sign/mk_safe call, as
&well as return a sequence number on a unseal/rd_priv and verify/rd_safe
&call and to set up the security context so the underlying mechanism doesn't
&perform sequencing checks. This would allow the application to do its own
&replay detection and sequencing in case the underlying mechanism's method
&is inappropriate.
A desirous application is completely free to set up and manage whatever
sequencing and/or replay detection scheme it seems appropriate and
represent the corresponding sequence numbers, timestamps, or other
data elements within its tokens.
Such application-managed data would
be uninterpreted by GSS-API or K it would just be a part of
the token and doesn't need to be visible as a distinguished item at
the interface.
The only conflict potential I can see would arise
if the application were layered atop a mechanism which performed its
own sequencing and/or replay detection (in a conflicting fashion)
even when the caller requested that these optional services not
be enabled for the context.
RFC-1508 strongly recommends that
mechanisms honor a caller's request to disable the message stream
integrity services on a per- if mechanisms honor
this recommendation, I think a pure application-level approach,
wholly independent of GSS-API and Kerberos, should &just work& today.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04021;
2 Feb 95 11:00 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04009;
2 Feb 95 11:00 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa08166;
2 Feb 95 11:00 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id &KAA08490 at pad-thai.cam.ov.com&; Thu, 2 Feb :37 -0500
Received: from inet-gw-1.pa.dec.com by MIT.EDU with SMTP
id AA28146; Thu, 2 Feb 95 10:00:32 EST
Received: from us1rmc.bb.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94)
id AA00313; Thu, 2 Feb 95 06:50:33 -0800
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA11994; Thu, 2 Feb 95 09:50:57 -0500
Message-Id: &.AA11994 at us1rmc.bb.dec.com&
Received: from tuxedo. by us1rmc. Thu, 2 Feb 95 09:50:57 EST
Date: Thu, 2 Feb 95 09:50:57 EST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: &John Wray, Digital DPE, (508) 486-5210
02-Feb-& &wray at tuxedo.enet.dec.com&
To: marc at mit.edu
Cc: &cat-ietf at mit.edu&@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, marc at mit.edu
Subject: Re: Anonymity by mechanism ?
&&& Or it could ignore out-of-sequence major-status codes completely (I
&&& believe they're supposed to be informational, so that the other output
&&& parameters from GSSAPI functions should still be valid).
If RFC-1509
&&& doesn't explicitly state this, I think that the new version should.
&&& Does anyone have any problem with this?
&They are currently not informational.
I've been saying for months
&that they should be (and I think you were disagreeing with me, but if
&you're changing your mind, I'm not going to hold you to your old
&opinion :-), and that rfc1508 should be updated to say so.
Oh yes - I remember why I may have said that (I think) :-)
It was precisely because you can't decrypt out-of-order packets if the
underlying mechanism uses cipher-chaining between packets, rather than
re-syncing at the start of each packet.
Such mechanisms wouldn't be able to
provide any integrity or confidentiality services on out-of-order packets.
So it looks like we have a choice:
Continue to treat out-of-order packet receipt as an error (which means
that out-of-order gss_seal/wrap packets won't be decoded for the
recipient).
Treat out-of-order notifications as informational only, and require that
gss_unseal/unwrap correctly return the packet content to the user
(assuming that the integrity check passed) for out-of-sequence
This would mean that GSSAPI couldn't support mechanisms that
use inter-packet crypto-chaining for integrity and/or confidentiality,
or at least for these mechanisms, out-of-sequence notification would
always be accompanied by an GSS_S_BAD_SIG error status (and
gss_unseal/unwrap would never return content data for out-of-sequence
Option (i) has the advantage that all mechanisms behave the same at the GSSAPI
Option (ii) has the advantage that mechanisms that re-sync on every
packet will allow the application to choose whether to use out-of-sequence
data, but not all mechanisms will allow this.
I guess I'm leaning towards option (ii) at the moment.
Maybe desired treatment
of out-of-sequence packets should be an extra input into the mechanism
negotiation process, so that if the application really wants this behavior,
then it can request a mechanism that provides it.
One other question is, is it worth changing?
What sort of application would
request out-of-order notification, and still want to deal with out-of-order
I don't think that the examples discussed recently (apps using a main
data-channel and a seldom-used control channel for out-of-band signalling) are
really appropriate here, since GSSAPI doesn't constrain the behavior of the
mechanism's sequencing detection after receipt of an out-of-sequence packet.
For example, let's say I'm the receiver part of such an application.
data-channel has five packets sitting in it, waiting for me to process.
a priority message on my control channel, so I process that ahead of the
data-channel messages, and get an out-of-sequence notification from GSSAPI
(which is OK, as I know the packet's out of sequence).
However, when I go back
to my first data-channel message and pass that to gss_unseal/unwrap, I may or
may not (GSSAPI doesn't specify) get an out-of-sequence error on that packet,
and on the remaining four.
I think the only model than makes sense for this
sort of application is to use two contexts, with independent sequencing.
is there a class of application that would want GSSAPI to determine whether a
gss_wrap packet is out-of-sequence (along with GSSAPI's undefined recovery
behavior), but might still want to use the data in the packet?
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06779;
2 Feb 95 11:47 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06775;
2 Feb 95 11:47 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa09264;
2 Feb 95 11:47 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id &LAA10047 at pad-thai.cam.ov.com&; Thu, 2 Feb :21 -0500
Received: from inet-gw-3.pa.dec.com by MIT.EDU with SMTP
id AA05769; Thu, 2 Feb 95 10:57:38 EST
Received: from us1rmc.bb.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94)
id AA05926; Thu, 2 Feb 95 07:07:50 -0800
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA12823; Thu, 2 Feb 95 10:07:29 -0500
Message-Id: &.AA12823 at us1rmc.bb.dec.com&
Received: from tuxedo. by us1rmc. Thu, 2 Feb 95 10:07:29 EST
Date: Thu, 2 Feb 95 10:07:29 EST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: &John Wray, Digital DPE, (508) 486-5210
02-Feb-& &wray at tuxedo.enet.dec.com&
To: danisch at ira.uka.de
Cc: &cat-ietf at mit.edu&@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, danisch at ira.uka.de
Subject: Re: Anonymity by mechanism ?
&& An application that wanted to do this could use two different GSSAPI security
&& contexts.
&So you want to use two different contexts for programs like rsh and rlogin ?
&Uuugh. :-(
The service you seem to be asking for is independent packet-sequencing on two
separate channels.
The GSSAPI way to do that is to use two separate security
Now, some mechanisms might be able to create one context from
another (e.g. by spinning off a derived key from the session key) via a method
that's less expensive than re-authenticating.
There was some talk of adding
such a service (creation of a new context from an existing context) to the base
If such a service were to allow the possibility of token-exchange, it
could be implemented above any mechanism (reverting to re-authenticating if the
mechanism doesn't support derived keys).
Maybe we should consider specifying
such a service for GSSAPI-V2?
In general, though, I'd have thought that if your application creates two
logical channels over a single transport connection, then you can avoid the use
of two security contexts, provided you make your calls to gss_wrap after you've
multiplexed your two logical channels down to the single transport-stream (and
gss_unwrap before you de-multiplex).
It's really only if you're using two
independent transport connections that you're forced into using two security
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07268;
2 Feb 95 12:34 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07264;
2 Feb 95 12:34 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa10314;
2 Feb 95 12:34 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id &LAA11124 at pad-thai.cam.ov.com&; Thu, 2 Feb :17 -0500
Received: from Sun.COM by MIT.EDU with SMTP
id AA10906; Thu, 2 Feb 95 11:36:18 EST
Received: from Eng.Sun.COM ([129.145.1.18]) by Sun.COM (sun-barr.Sun.COM)
id AA00360; Thu, 2 Feb 95 08:36:12 PST
Received: from jurassic.Eng.Sun.COM (jurassic-52) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1)
id AA10689; Thu, 2 Feb 95 08:35:55 PST
Received: from elrond.ss-eng.eng.sun.com by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4)
id IAA18287; Thu, 2 Feb :50 -0800
Received: by elrond.ss-eng.eng.sun.com (SMI-8.6.9/SMI-SVR4)
id IAA06372; Thu, 2 Feb :45 -0800
Date: Thu, 2 Feb :45 -0800
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dan Nessett &Danny.Nessett at eng.sun.com&
Message-Id: &.IAA06372 at elrond.ss-eng.eng.sun.com&
To: linn at cam.ov.com
Subject: Re: Interoperability questions regarding the Kerberos GSS-API Mechanism
Cc: jim at bilbo.suite.com, kerberos at mit.edu, cat-ietf at mit.edu
X-Sun-Charset: US-ASCII
A desirous application is completely free to set up and manage whatever
sequencing and/or replay detection scheme it seems appropriate and
represent the corresponding sequence numbers, timestamps, or other
data elements within its tokens.
Such application-managed data would
be uninterpreted by GSS-API or K it would just be a part of
the token and doesn't need to be visible as a distinguished item at
the interface.
The only conflict potential I can see would arise
if the application were layered atop a mechanism which performed its
own sequencing and/or replay detection (in a conflicting fashion)
even when the caller requested that these optional services not
be enabled for the context.
RFC-1508 strongly recommends that
mechanisms honor a caller's request to disable the message stream
integrity services on a per- if mechanisms honor
this recommendation, I think a pure application-level approach,
wholly independent of GSS-API and Kerberos, should &just work& today.
Your suggestion that applications could place sequence number data within
their own messages is a valid workaround, given the existing interface.
In fact, while exploring the gssapi code in the MIT Kerberos distribution
it appears to me that sequence number checking is not carried out by either
verify() or unseal(), so the application is going to have to do this for
the existing implementation anyway.
[ the bit of code I am looking at is in k5unseal.c and it is the comment :
/* XXX this is where the seq_num check would go */
NB: both verify and unseal call the routines in k5unseal.c]
However, I think someone else has said during the discussion of this issue that
sequencing is a security service and is naturally part of the services that
would be offered by GSSAPI. While I would not suggest changing the existing
definitions, I think it is appropriate to consider adding a way to get
consistent and useful sequence number / timestamp checking using the interfaces
being developed for GSSAPIv2.
This is why I suggested adding something to the seal/unseal/sign/verify
[or whatever their new names will be] that allows the application to pass
in sequence number or timestamp data that will be included in the associated
tokens. The advantage is it relieves the application programmer from defining
a field in the application protocol messages to carry what might be considered
&lower layer& data. For example, if the sign/seal routines allowed the
application to pass in an opaque 64-bit quantity and verify/unseal returned
this quantity, then the application could use it for sequencing (whether
it carried sequence number or timestamp data).
I am not ready to draw swords on this suggestion, I merely mention it as a
possibility. As someone who will be using GSSAPI, I always can use the
workaround you described. However, the GSSAPI interface MUST then have a
way for the application programmer to specify that NO sequence number or
timestamp checking should be carried out. Otherwise, the mechanism will
report errors when none exist (e.g., in the multi-threading cases I have
mentioned in previous messages).
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07377;
2 Feb 95 12:38 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07373;
2 Feb 95 12:38 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa10414;
2 Feb 95 12:38 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id &MAA11672 at pad-thai.cam.ov.com&; Thu, 2 Feb :15 -0500
Received: from Sun.COM by MIT.EDU with SMTP
id AA15246; Thu, 2 Feb 95 12:05:19 EST
Received: from Eng.Sun.COM ([129.145.1.18]) by Sun.COM (sun-barr.Sun.COM)
id AA07184; Thu, 2 Feb 95 09:05:14 PST
Received: from jurassic.Eng.Sun.COM (jurassic-52) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1)
id AA10795; Thu, 2 Feb 95 09:04:56 PST
Received: from elrond.ss-eng.eng.sun.com by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4)
id JAA20096; Thu, 2 Feb :59 -0800
Received: by elrond.ss-eng.eng.sun.com (SMI-8.6.9/SMI-SVR4)
id JAA06392; Thu, 2 Feb :56 -0800
Date: Thu, 2 Feb :56 -0800
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dan Nessett &Danny.Nessett at eng.sun.com&
Message-Id: &.JAA06392 at elrond.ss-eng.eng.sun.com&
To: Jim_Miller at suite.com
Subject: Re: Interoperability questions regarding the Kerberos GSS-API Mechanism
Cc: kerberos at mit.edu, cat-ietf at mit.edu
X-Sun-Charset: US-ASCII
From jim at bilbo.suite.com Wed Feb
1 15:21:59 1995
To: Danny.Nessett at Eng
Subject: Re: Interoperability questions regarding the Kerberos GSS-API Mechanism
Cc: kerberos at ATHENA.MIT.EDU, cat-ietf at MIT.EDU
[text deleted]
I can see how your window mechanism would work.
Just for grins, here's an expanded description on the idea in my previous
Each ticket would describe a range of sequence numbers using an initial
random number and a message count.
In this way a ticket would be &good
for& a certain number of messages, in addition to being valid a certain
length of time.
Client Side:
Each time a client sends a message, it would get the &next number& from
the ticket (credential, actually) and use it as the message sequence
If the &next number& & (initial number + message count), then the
client would have to get a new ticket.
Server Side:
Server receives the message, decodes/decrypts it and examines the endtime
of the appropriate ticket.
If the ticket has expired, then the message is
rejected (i.e. Messages secured using these kinds of sequence numbers
would expire when the ticket used to secure them expires.).
Assuming the
ticket has not expired, and the other checks pass, the server examines the
sequence number.
The sequence number must fall within the range of
numbers described in the ticket used to secure the message (duh).
To cut down on the amount of replay information that would have to be
searched, the server maintains a number (N) indicating the lowest number
in the range below which all numbers have already been received.
Hmm, that doesn't sound very clear.
Assume that all sequence numbers from
&initial number & through N have arrived.
Now, if a message comes in with
a sequence number & N you don't have to search through the replay cache to
know its a replay.
So, instead of simply searching the replay cache, you first compare the
message's sequence number with N.
If the sequence number &= N you know
its a replay.
If the sequence number is & N, you search the replay cache.
If a replay record exists that contains a matching client, server, and
sequence number, then the message is a replay.
The replay cache search
will also tell you when it is time to increment N.
My N is kind of like your sliding window, but it only tracks the lower-end
of the window.
Finally, the replay cache expunge code could be modified to remove records
with sequence numbers & N.
Of course, this implies the various Ns
associated with the tickets are somehow stored in the replay file.
an idea on how to do this, but I don't feel like going into details in
this post.
I think both schemes are similar. Let me try to analyze them from a strengths
and weaknesses point of view :
Fixed Sequence Number Range Scheme
----------------------------------
Strength : Packets will never be discarded erroneously because they arrive
very late. This is a weakness of the Sliding Window scheme, although the
probability of this happening can be made small by an appropriate choice
of window size.
Weakness : The application will have to guess the rate at which packets will
be generated during the ticket validity period. However, using sufficiently
large validity periods should mitigate the performace hit of resynchronizing by
resending a ticket.
For sufficiently large sequence number spans, the amount of space
allocated by the server to handle the book keeping associated with keeping track
of which packets have arrived and which haven't could be large. Since the
span length is under the client's control, the server would loose control
of its resources. Of course, the server could impose a maximum limit to
the span size, but then for certain client packet rates, this might
induce an unacceptible performance hit on the application.
Sliding Window
--------------
Stength : No need to estimate the rate of packet traffic and optimize by
computing a sufficiently large sequence number span.
Weakness : Packets could be dropped, requiring a resynch by the application,
if they arrive too late.
If the window value becomes large, the amount of server memory
required to handle the book keeping could become large. The server could
limit the window values as it could with a window span, but again this might
not be appropriate for certain clients. Since the window slides both at
the bottom and the top in this approach (as opposed to just the bottom
in the fixed range approach), the amount of resources should be somewhat
less for a given packet generation rate and delay distribution.
The above analysis doesn't demonstrate one approach is significantly better
than the other. The only additional argument I will make for the sliding
window approach is it follows accepted practice in sequencing for reliable
transport and link-level protocols.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07472;
2 Feb 95 12:44 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10510;
2 Feb 95 12:44 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07437;
2 Feb 95 12:44 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07183;
2 Feb 95 12:33 EST
Mime-Version: 1.0
Content-Type: Multipart/M Boundary=&NextPart&
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-levinson-multipart-related-00.txt
Date: Thu, 02 Feb 95 12:33:02 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID:
&.aa07183 at IETF.CNRI.Reston.VA.US&
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
: The MIME Multipart/Related Content-type
Author(s) : E. Levinson, H. Alvestrand
: draft-levinson-multipart-related-00.txt
: 01/31/1995
The Multipart/Related content-type provides a common mechanism for
representing objects that are aggregates of related MIME body parts.
document defines the Multipart/Related content-type and provides examples
of its use.
Internet-Drafts are available by anonymous FTP.
Login with the username
&anonymous& and a password of your e-mail address.
After logging in,
type &cd internet-drafts& and then
&get draft-levinson-multipart-related-00.txt&.
A URL for the Internet-Draft is:
Internet-Drafts directories are located at:
ftp.is.co.za (196.4.160.2)
nic.nordu.net (192.36.148.17)
Pacific Rim
munnari.oz.au (128.250.1.21)
US East Coast
ds.internic.net (198.49.45.10)
US West Coast
ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to:
mailserv at ds.internic.net. In the body type:
&FILE /internet-drafts/draft-levinson-multipart-related-00.txt&.
NOTE: The mail server at ds.internic.net 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&
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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/A Boundary=&OtherAccess&
--OtherAccess
Content-Type:
Message/External-
access-type=&mail-server&;
server=&mailserv at ds.internic.net&
Content-Type: text/plain
Content-ID: &00.I-D at CNRI.Reston.VA.US&
ENCODING mime
FILE /internet-drafts/draft-levinson-multipart-related-00.txt
--OtherAccess
Content-Type:
Message/External-
name=&draft-levinson-multipart-related-00.txt&;
site=&ds.internic.net&;
access-type=&anon-ftp&;
directory=&internet-drafts&
Content-Type: text/plain
Content-ID: &00.I-D at CNRI.Reston.VA.US&
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07964;
2 Feb 95 13:31 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11287;
2 Feb 95 13:31 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07949;
2 Feb 95 13:30 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07202;
2 Feb 95 12:33 EST
Mime-Version: 1.0
Content-Type: Multipart/M Boundary=&NextPart&
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-levinson-cid-00.txt
Date: Thu, 02 Feb 95 12:33:06 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID:
&.aa07202 at IETF.CNRI.Reston.VA.US&
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
: CID: The Content-ID Uniform Resource Locator
Author(s) : E. Levinson
: draft-levinson-cid-00.txt
: 01/31/1995
The Uniform Resource Locator (URL) scheme, &cid&, allows compound or
aggregate objects in a multipart mail message to refer to one another by
their body part labels.
Internet-Drafts are available by anonymous FTP.
Login with the username
&anonymous& and a password of your e-mail address.
After logging in,
type &cd internet-drafts& and then
&get draft-levinson-cid-00.txt&.
A URL for the Internet-Draft is:
Internet-Drafts directories are located at:
ftp.is.co.za (196.4.160.2)
nic.nordu.net (192.36.148.17)
Pacific Rim
munnari.oz.au (128.250.1.21)
US East Coast
ds.internic.net (198.49.45.10)
US West Coast
ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to:
mailserv at ds.internic.net. In the body type:
&FILE /internet-drafts/draft-levinson-cid-00.txt&.
NOTE: The mail server at ds.internic.net 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&
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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/A Boundary=&OtherAccess&
--OtherAccess
Content-Type:
Message/External-
access-type=&mail-server&;
server=&mailserv at ds.internic.net&
Content-Type: text/plain
Content-ID: &25.I-D at CNRI.Reston.VA.US&
ENCODING mime
FILE /internet-drafts/draft-levinson-cid-00.txt
--OtherAccess
Content-Type:
Message/External-
name=&draft-levinson-cid-00.txt&;
site=&ds.internic.net&;
access-type=&anon-ftp&;
directory=&internet-drafts&
Content-Type: text/plain
Content-ID: &25.I-D at CNRI.Reston.VA.US&
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09921;
2 Feb 95 15:25 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09917;
2 Feb 95 15:25 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13648;
2 Feb 95 15:25 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id &OAA15245 at pad-thai.cam.ov.com&; Thu, 2 Feb :55 -0500
Received: from kerby.ocsg.com by MIT.EDU with SMTP
id AA08101; Thu, 2 Feb 95 14:44:58 EST
Received: (uucp at localhost) by kerby.ocsg.com (8.6.9/8.6.4 + 8.6.9, dpg hack 5dec94) with UUCP id LAA19480; Thu, 2 Feb :32 -0800
Received: by war04.ocsg.com (NX5.67d/NX3.0M, dpg hack 15dec93)
id AA19359; Thu, 2 Feb 95 11:44:31 -0800
Date: Thu, 2 Feb 95 11:44:31 -0800
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dennis Glatting &war04!dennisg at kerby.ocsg.com&
Message-Id: &.AA19359 at war04.ocsg.com&
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
To: John Linn &linn at cam.ov.com&
Subject: A difference in the use of channel bindings
Cc: cat-ietf at mit.edu
Reply-To: dpg at ocsg.com
I discovered that channel bindings are used in the MIT
GSS-API code in a way not covered in
draft-ietf-cat-kerb5gss-01.txt. If the code is doing
the right thing then the draft needs to reflect the code's
The difference is associated with the GSS-API function
gss_accept_sec_context(). The GSS channel bindings
passed to gss_accept_sec_context() are passed through
to the function krb5_gss_accept_sec_context().
There, if the bindings are not NULL, the binding's
initiator address is used to verify the AP-REQ token's
sender address.
The draft specifies the channel binding's role in the GSS
authenticator but not in address verification. Also,
since krb5_gss_accept_sec_context() is using the
initiator address to verify the token's sender address,
the contents and byte ordering of channel bindings need
to be specified.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10235;
2 Feb 95 15:33 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13835;
2 Feb 95 15:33 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10189;
2 Feb 95 15:33 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10035;
2 Feb 95 15:29 EST
Mime-Version: 1.0
Content-Type: Multipart/M Boundary=&NextPart&
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-rekhter-IPv6-address-format-01.txt
Date: Thu, 02 Feb 95 15:29:39 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID:
&.aa10035 at IETF.CNRI.Reston.VA.US&
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
: An IPv6 Global Unicast Address Format
Author(s) : Y. Rekhter, P. Lothberg
: draft-rekhter-IPv6-address-format-01.txt
: 01/31/1995
This document defines an IPv6 global unicast address format for use in the
The address format defined in this document is consistent with
the IPv6 address allocation architecture [1], and is intended to facilitate
scalable Internet routing.
The format defined in this document doesn't preclude the use
of other address formats.
Internet-Drafts are available by anonymous FTP.
Login with the username
&anonymous& and a password of your e-mail address.
After logging in,
type &cd internet-drafts& and then
&get draft-rekhter-IPv6-address-format-01.txt&.
A URL for the Internet-Draft is:
Internet-Drafts directories are located at:
ftp.is.co.za (196.4.160.2)
nic.nordu.net (192.36.148.17)
Pacific Rim
munnari.oz.au (128.250.1.21)
US East Coast
ds.internic.net (198.49.45.10)
US West Coast
ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to:
mailserv at ds.internic.net. In the body type:
&FILE /internet-drafts/draft-rekhter-IPv6-address-format-01.txt&.
NOTE: The mail server at ds.internic.net 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&
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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/A Boundary=&OtherAccess&
--OtherAccess
Content-Type:
Message/External-
access-type=&mail-server&;
server=&mailserv at ds.internic.net&
Content-Type: text/plain
Content-ID: &43.I-D at CNRI.Reston.VA.US&
ENCODING mime
FILE /internet-drafts/draft-rekhter-IPv6-address-format-01.txt
--OtherAccess
Content-Type:
Message/External-
name=&draft-rekhter-IPv6-address-format-01.txt&;
site=&ds.internic.net&;
access-type=&anon-ftp&;
directory=&internet-drafts&
Content-Type: text/plain
Content-ID: &43.I-D at CNRI.Reston.VA.US&
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10236;
2 Feb 95 15:33 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13836;
2 Feb 95 15:33 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10188;
2 Feb 95 15:33 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10008;
2 Feb 95 15:29 EST
Mime-Version: 1.0
Content-Type: Multipart/M Boundary=&NextPart&
To: IETF-Announce: ;
cc: mailext at cs.wisc.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mailext-lang-tag-02.txt
Date: Thu, 02 Feb 95 15:29:11 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID:
&.aa10008 at IETF.CNRI.Reston.VA.US&
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail Extensions Working Group
of the IETF.
Note: This revision reflects comments received during the last call period.
: Tags for the identification of languages
Author(s) : H. Alvestrand
: draft-ietf-mailext-lang-tag-02.txt
: 02/01/1995
This document describes a language tag for use in cases where it is
desired to indicate the language used in an information object.
It also defines a Content-language: header, for use in the case where
one desires to indicate the language of something that has RFC-822-like
headers, like MIME body parts or Web documents, and a new parameter
to the Multipart/Alternative type, to aid in the usage of the
Content-Language: header.
Internet-Drafts are available by anonymous FTP.
Login with the username
&anonymous& and a password of your e-mail address.
After logging in,
type &cd internet-drafts& and then
&get draft-ietf-mailext-lang-tag-02.txt&.
A URL for the Internet-Draft is:
Internet-Drafts directories are located at:
ftp.is.co.za (196.4.160.2)
nic.nordu.net (192.36.148.17)
Pacific Rim
munnari.oz.au (128.250.1.21)
US East Coast
ds.internic.net (198.49.45.10)
US West Coast
ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to:
mailserv at ds.internic.net. In the body type:
&FILE /internet-drafts/draft-ietf-mailext-lang-tag-02.txt&.
NOTE: The mail server at ds.internic.net 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&
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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/A Boundary=&OtherAccess&
--OtherAccess
Content-Type:
Message/External-
access-type=&mail-server&;
server=&mailserv at ds.internic.net&
Content-Type: text/plain
Content-ID: &13.I-D at CNRI.Reston.VA.US&
ENCODING mime
FILE /internet-drafts/draft-ietf-mailext-lang-tag-02.txt
--OtherAccess
Content-Type:
Message/External-
name=&draft-ietf-mailext-lang-tag-02.txt&;
site=&ds.internic.net&;
access-type=&anon-ftp&;
directory=&internet-drafts&
Content-Type: text/plain
Content-ID: &13.I-D at CNRI.Reston.VA.US&
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10287;
2 Feb 95 15:34 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13867;
2 Feb 95 15:34 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10270;
2 Feb 95 15:34 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10116;
2 Feb 95 15:31 EST
Mime-Version: 1.0
Content-Type: Multipart/M Boundary=&NextPart&
To: IETF-Announce: ;
cc: host-conf at sol.cs.bucknell.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-dhc-dhcpv6-00.txt
Date: Thu, 02 Feb 95 15:31:23 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID:
&.aa10116 at IETF.CNRI.Reston.VA.US&
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Dynamic Host Configuration
Working Group of the IETF.
: Dynamic Host Configuration Protocol for IPv6
Author(s) : J. Bound, Y. Rekhter, S. Thomson
: draft-ietf-dhc-dhcpv6-00.txt
: 02/01/1995
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6): provides a
mechanism to autoconfigure inter-link Host IPv6 addresseses [IPv6-ADDR],
provides parameters to autoregister [DYN-DNS-UPD] and receive Domain Name
System (DNS) [RFC-] Host names, and provides a mechanism to
specify additional configuration options in the protocol.
Internet-Drafts are available by anonymous FTP.
Login with the username
&anonymous& and a password of your e-mail address.
After logging in,
type &cd internet-drafts& and then
&get draft-ietf-dhc-dhcpv6-00.txt&.
A URL for the Internet-Draft is:
Internet-Drafts directories are located at:
ftp.is.co.za (196.4.160.2)
nic.nordu.net (192.36.148.17)
Pacific Rim
munnari.oz.au (128.250.1.21)
US East Coast
ds.internic.net (198.49.45.10)
US West Coast
ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to:
mailserv at ds.internic.net. In the body type:
&FILE /internet-drafts/draft-ietf-dhc-dhcpv6-00.txt&.
NOTE: The mail server at ds.internic.net 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&
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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/A Boundary=&OtherAccess&
--OtherAccess
Content-Type:
Message/External-
access-type=&mail-server&;
server=&mailserv at ds.internic.net&
Content-Type: text/plain
Content-ID: &42.I-D at CNRI.Reston.VA.US&
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-dhcpv6-00.txt
--OtherAccess
Content-Type:
Message/External-
name=&draft-ietf-dhc-dhcpv6-00.txt&;
site=&ds.internic.net&;
access-type=&anon-ftp&;
directory=&internet-drafts&
Content-Type: text/plain
Content-ID: &42.I-D at CNRI.Reston.VA.US&
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10492;
2 Feb 95 15:41 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14071;
2 Feb 95 15:41 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10461;
2 Feb 95 15:41 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10453;
2 Feb 95 15:40 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14049;
2 Feb 95 15:40 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10448;
2 Feb 95 15:40 EST
To: IETF-Announce: ;
cc: mailext at cs.wisc.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary &iesg-secretary at CNRI.Reston.VA.US&
Subject: Last Call2: Tags for the identification of languages to Proposed
Date: Thu, 02 Feb 95 15:40:41 -0500
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID:
&.aa10448 at IETF.CNRI.Reston.VA.US&
The IESG has received a request from the Mail Extensions Working Group
to consider &Tags for the identification of languages&
&draft-ietf-mailext-lang-tag-02.txt& for the status of Proposed
This is the second last call for the Language Tag document as there
were substantive changes made during the previous last call period.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at cnri.reston.va.us or ietf at cnri.reston.va.us mailing lists by
February 16, 1995.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11936;
2 Feb 95 16:55 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11930;
2 Feb 95 16:55 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16191;
2 Feb 95 16:55 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11904;
2 Feb 95 16:55 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11868;
2 Feb 95 16:53 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa16139; 2 Feb 95 16:53 EST
Received: from Bill.Simpson.DialUp.Mich.Net (pm012-20.dialip.mich.net [141.211.7.188]) by merit.edu (8.6.9/merit-2.0) with SMTP id QAA24814; Thu, 2 Feb :37 -0500
Date: Thu, 2 Feb 95 21:05:06 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: William Allen Simpson &bill.simpson at um.cc.umich.edu&
Message-ID: &3859.bill.simpson at um.cc.umich.edu&
To: ipng at sunroof.eng.sun.com
Cc: ietf at CNRI.Reston.VA.US
Reply-to: bsimpson at morningstar.com
Subject: Re: Severance of Relationships
& From: Brad Wilson &wilson at cps201.cps.cmich.edu&
& Come on ... what it REALLY necessary to make some people who PAY for email
& to read that you had quit?
8 times here!
Now we know which mailing lists haven't thrown him off, yet.
& From: another user who apologized for accidentally sending it to the list
Like, why do I care, you worthless little vandal?
My feelings, exactly.
Seems more like a commercial advertisement.
Against our Acceptable Use
Let's all ask for his Delphi account to be closed.
Bill.Simpson at um.cc.umich.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18009;
2 Feb 95 22:41 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18005;
2 Feb 95 22:41 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa22366;
2 Feb 95 22:41 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id &VAA23590 at pad-thai.cam.ov.com&; Thu, 2 Feb :29 -0500
Received: from Sun.COM by MIT.EDU with SMTP
id AA26376; Thu, 2 Feb 95 21:25:28 EST
Received: from Eng.Sun.COM ([129.145.1.18]) by Sun.COM (sun-barr.Sun.COM)
id AA03147; Thu, 2 Feb 95 18:25:16 PST
Received: from jurassic.Eng.Sun.COM (jurassic-52) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1)
id AA14978; Thu, 2 Feb 95 18:25:01 PST
Received: from icenine.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4)
id SAA00820; Thu, 2 Feb :08 -0800
Received: by icenine.Eng.Sun.COM (5.0/SMI-SVR4)
id AA05001; Thu, 2 Feb :54 +0800
Date: Thu, 2 Feb :54 +0800
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Don Stephenson &Don.Stephenson at eng.sun.com&
Message-Id: &.AA05001 at icenine.Eng.Sun.COM&
To: cat-ietf at mit.edu
Subject: SNP - session oriented overlay for GSS-API
Content-Type: X-sun-attachment
----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 10
Attached is the USENIX paper on the SNP work done at the Univ.
of Texas, Austin.
This is a possible alternate interface to
provide a session oriented overlay for GSS-API, similar in
some respects to Ted Ts'o's CATS proposal and P. Rajaram e-mail
These are attempts to provide a simpler interface to
GSS-API that might have greater potential for widespread use.
----------
X-Sun-Data-Type: compress
X-Sun-Data-Description: compress
X-Sun-Data-Name: snp.ps.Z
X-Sun-Encoding-Info: uuencode
X-Sun-Content-Lines: 2173
X-Sun-Content-Length: 134529
begin 600 snp.ps.Z
M'YV0)4) F=(B&)DW8LJTD.$&AH(2)8;(*1.&SALY.D&0L9,&SAP0-5S4D!$#
MQ) W&/+(27,&#1T0,7+ at L,$&9HX&,T!(&4,FS9 at P;$ 4R5,&Q)0W9NC&&3/Q
M80DJ:&BP*9.QSIPR;M+@&;$QC5.)%.FD&&.&2$6J(*B at J0,B&!PY($#&@&E#
M!PT8=FO8S$'#*90P9\K,R1BC+\2_ at 9_((5,&8]LY8[&2&2KD31TW/=V&J8PG
M(PP0GVW$D&$WAPRG1-Z,J=,&*QTC9.D,3INF]9P64MZT&&.&MNT62&@ ]&E;
M&(O*;,B8M+RRL=,BF$^V:&U&]D,B5I(,E+X;,Y,T;M!V]0BBA1805K%J+?_F
M&O:!1^O(B9PQ;1DL(&S3 at 5/G94R^#='0T TZQ&####E05L89X$$AAVI3E$%'
M1G24@&&8+KS5W at M4W$&$3R_)4,-G/8WQ$F-FV(?%AR:&D!&#O;W at Q!XH]H$B
M&&\(L8&8X&E7HQ,X3K&'A6. at T8&3&KR Q1Y3 at .!$'T+ at 2(44&] A!V]SL''6
MD3BFD&5'9 at !UE9,XVC%'&GH4%4-)-Y#61AU! ?D&&F&F&0(.(LEUVIMQXJ at E
M9G&P854.,.P1)AM7V5A&BB\ L1*,&WB)Z!Y;?/8G&8$.6FA)+&30QQZ=PM2'
M FF840:B17VF:A=CD/43'7V4JJ=. at KTAJ%AD:92&';-:(46MMX[56T^\AG&&
M&) !50:I7^YQ::9S$+J'K\#V)^RLQ()@)II%\0D:&$0:N&&O&]AJ;:XMM*FK
M'0K0R2T(WL(0JZFHIB7%O+26&VRNU.I[;F_;VIDN:=F6Q)-R?&HP);P5K80'
M&*O),5%UNUFY'AEUP*%1QB#0 $)@+SUXF7(&APL&?R=RC+'&&H&L@,B8 at 03N
MA6B&W!^R$E;L,)&-7IHL'&7L\8*D'UE91U%/1MEH=W4 96H99.RAP!S&T6%5
MB2^]P+3394 - at M%%H0PECD&T&D&:@@D] at MEH?X3%V&\8T41%6Y2D:GEV*P!#
M%W(:(800E7Z[JIQN]/:9G$D4\:V&)L)U.(YDF-&&&&FP(73A=^K:(I&%*_ B
M&#C&5AT5&0 -0DY]QS:WQ0^;49T&#Z=&W=]O/.QWE$!2O9)F.(H1QIA8*,#4
ME7G at *$14&Y.'7XYU5$[&$&@PM0?T3 G1?'*-\0Q=JYD=FSB9DFT,A]!FO-'&
M57247UT?I T?1O%FPV]'[&&P\09/WV*.,HZ-+[X%W)$3VAQ25!(YN&Y*&%&
MW&I&ILA-+ at R5 Z 9YD&C7&%H@&!8W at %AMP4,W at V#QA(&WS0B.&JQ 6Y%D!H&
M4 (&S*U,(XL&SZ)B at [/TQ09N16K!'=) !CJ at 80\Y)$-%PB&^^F'E##Z4V1SJ
M((:/26A42LLA&LK $I& $0TM$*)PBC at 5S2318TML(LAPB$4\(,4,&Q at -#B&&
M12T2&64*Z&(2:Y:3,#KQ)6$D8POR&,8K9G&(7#QB$DEC1Y#!1 9SR:,0DA1$
M//C1C8'T8LU*4L at G1A&+M0%,T(((R!?2H73+&H'NP(-$4+9PDU:Z(_]2V3^#
MD4$Y3RH5W'BX.!S)X0ZU?,%\&GD&..B-3&\8 at \8&]X(CY-*#P*2&'*SGO,;L
M80YAL$-1&E*2![$A*$UZX0M\-R9#GJ9'%E)EDW*$O#&0QY!-,F0PVPA(_*Q0
M8\%,Y&,:^:T&FM$,9E! #OF(3S:V8(I5Q&,3_7G/%.5PASVLV&'\R&\4H&\G
M18):&3 at 2&7UB$:%)E&(56_(2L-5-&'@KCPM*8L\S(FN at ^S3I2$%PL&X,;3(Y
MS&1@@'E+?V*T9G-9Z!IY:,%1\DY.NR1F+W,IS,5)+:BGW,,N*3E078XA at R&X
MY:&.,*]3)4JF9=C-'-805&%89&)P.\(&(J6&H;KL!6;5F&MA6&08K+$-;U!.
MD]P* I[R*E!&4:6%RC&&/M@/)7#CB1V J+&%!M.7;[OD&92*RZ+2&J@& ^?#
M0 :&&LG!#D&QF5BJTQC,!N6%0S7L4(,G6+AA1FA%?5Q-+105N&'JAS4M*FGB
MI\H7?J8,&=C#.T5%HXPI0$1ZP:UN62 at B&GSJA2]&*'!9&K.Y,E&Y%ZDJJJ0[
MIOVYT at Y0M.4&8-M8C&T6)&4SI&W!E=O=JO&X'%NN&,V+2/1ZMZ[$4L!&9;!&
MWD!7#M0M0WXU&Q.6;@2';) #8R'V7LDBRV*:40#**MO9S)96:&@;&%'-4#E$
MR;-C=&5,.&G+V&MF=L$=]JSP_JLT&E]3=S!9HT^/]9F2Q. &&_AN2D&PW/V]
MLP_E at XN& K6%/0BVOT4ZPZA\O!$ at H^%8F/G46MDHY#3Z5SE!;B$9/O7CUU*Y
MR*^5\I5Y)8?M?FK$7-ZNEIV\T-(*;9?X23*97UE#)3\98@'&,HV9+.?31%G-
MNTUR%U:VHQZ=#+ Y!DJ?7D $U#X5/YXTI2 at 17$K3A6&/75
OC&WS=\5Q9!C
M&&K_]D?IX]$A&1]!)\12V20,EN31R/6M')/(U&:^D#0&3J&$D)6B;(E-5ON+
M)UQ:^&:DX2@)4LMT?Q=*!+B) 25[2,]B0-0[E/S3?%Q= at QO&& &W[,C9:( V
MOEXPA20 at *YI( X&C6 *&7WX&KM*T&(ZLP##604P^$Z.#SB[&L9*(EV/&,MEG
M[JVQA&W4!3&I'QV$% at 4K?.H%4C!XJ:Q:%/OA[T:[O;&&RH#L;G&5:A&IRG:I
M#0=-*D#96,,1Q&'P[#=$&]K5'A*VM2U+.0&!:DP9.,B9O&B8EWP-&I VM:T-
M&SG0X&;XVNT+^F4N7/5F&&0J^K7P$P,8.'U=.,).$G9SK.&]X'LBL at %+)?8^
M,K68QC6HP1Z^Y]P5%_$S.3'P_L9 at A]Z(+&&*L$$-;H&#&+C at !EK/U at L&5A3\
MR)WN=L&[U.=4I[[S;'P;OP//I+&ZC]XM5 [9FYR$D)H0V& S9@&JG,))3#EL
MOGC$'*PN/P_5T4_E8? at QN-*LH( ]P&WA!Z[(U9C]N1AI&&,MNL,4)S)&C=V^
M#BUZX:IQZL0]?.8&&N&P93TK/A1\: Z!&E\*&#NS(GW+8\IO,!M0X(3[4&'Z
M&&@/?GL/@D,EBE3T2I2AQ*3?A==+,F,] S2E:2^1&FJE&W,QLGXRE:AN_F&&
M-Q5YH #F5Q2,5Q%[0'EO &M8I55&=083 at 7%@]2E[('_ at 5G\ML%(96!(+$X#A
MY($#F&S]IW\%J!.KDX&5%RM4EU6_\X 1^%7ZM5]*4W 5.'_+8B58DF-M$%66
M$3,F S/*83)1&25N,$ 7L8/H)B%OX'^G]RURP 8RI&X. 8*G=&Q/&(5+Z($/
M$T*?&87AH6XF%A00Z%49%UA[D(06 4&G(AR_)&&FU%OPQ!ALL$7XT85H^ 9P
MTP1,&C(P-(=$M% F9&Q[J#&!J !1!&H&TP0 !&HYH8A*$S0+ 0*.B&-H%&J3
MB%;&)XEP\T,E&8EI$&.:J#1J(#6-&#=KL &)&#=WD(ER&(&NI5OEX3&*IS1M
M (LMD!.SB&/6IC&1F(LO\ :ZI0&AXHOEU5^^*&#OY8L4I#&X&#&#IS&R&#&.
M]!E-THIOD&YXJ#1Y0(IS9DU!45C&] at 84Q&VE=H&^]@(41T%34(UD&%91(AG/
M at 1D. B$2HB P,H]C$&$3\C46XA$9\B *XR&TMR&@HTMH1&&8H3XIHS'#-VQL
M%G*UYV0&%C=)0 2G1&.DHF$/\P)5D!5Q&#05&9'V12.+\BD1!UCNERB!=DT?
M96&A$5+&J ![]52W13,R$RK&& )$MR^]D70\&77&PH6 at X5)-(&$K,09S(),V
M&2,029&]L3UQ14I#LI0&\TFF,S2&%1 at ^9TJ/=I)J=5)BH #C-16]]RG_DY+Z
MM0&B\VD-LQ[[-FO94I06 at Y3?(EX65&/HQW X=A&&)HE&Z1,?\0)R&90?$3'Q
M%G+A at R); &L:^6X2XQI8(Y,Q at R(RI)&G Y.V$A2[L08S5!T7)&&6Z7!DP&KS
M T-FH&CY] )/( 90^)%E, 5_,G O=&:]T22M\A'98BQP YN\\1JQ at 8H9QA@/
MXRT'@YI)4 at 1X4&&8L99[D!,XF9GP B?59R0W at G!E )6,P9PO@)VD-)VF:9SP
M&!'000;XJ(_VV& /DH\2DA'0QU=I !3_V!X=LB(#&2-!PB(A\G0A!R13@)\N
MXI1D,P5 ,P;OR09$L&AA &&R(31T @*B01I(LG&?&0.F 4S9EDMVL(3$1&=/
M54!E AG])2&\P6+)Q 3:D4NWE 81 at A4$R'XTA08JVC6]48)R,A5T8%FN1S at +
M&#0\$P8TD*-^LB! D:-0DB0OQW]E&!E1 1-/YW(&JBQ[&*3*HJ0G8D&$=VAP
M P1F at J11*H))FA5T()96NJ49E*7NDB8,ZC8X,@0F&@4AFJ5\)S1F4GIL&J(%
ME*5C (7CDR1UZJ80:J9G%&%SLH2)1389BD^&FJ%EJC1 ,*)D^0(CNJADDZ)2
MTW2#EZ*EEZ(KVAM at XR19*@&PFD8D8J6 at F@:9&J.;^C6&AS1%VC-LX$ at O&$VH
MEZ77M(VQR@;%4ZB-(A^PRJN2NJMR8*ORD:MP0W5&J@&=&B/ATRASHYYT4 7C
M,W,MHC7*H7,I)ZU9TP9E-6M6&4I8TZWDE6Q7L6PM4GOPHAP-::D+I:T,@P&-
M&1A&PZ[L&D&-*0.?L5 A1ULU(BOAPZ[F&JL2 at J,\,VT5 J0 &P9#.BIR$E=5
M@@&K-&9V R]T\# HDJ!S.&\4BX-%J(-Y-41N\ (=!U7A&0&=YT/ZI*&E6S.[
M(0&GJ+%&V(J1XK(&ZXJ?(K-'&+-$^+([&(5?B(&2M at =:%XDY:;.MZ*#E01I#
MF[,&&[1(&YU$6XND\K1&V[375%=2JW54&Q1#F(-'.+4\6+41 at XU]0($G*XYE
MD+)CF[(K&10CF[(0TX,WJAM,P57N4SR_ X,X&@9/A0&1\V&:TR((\DO6]1EF
MH ??,D%S9 at 0OP =?T+B.&Q+R at 39P&4 9)DT^9P9:LEA_45E&H&5CL ;S&B1)
M,K$/&S1P@ &?D1(?X:4G\Q8L)9I^^V&&-FV8VQ'+R$)-$D)-LC#FA3=3 at Z3X
M@@&UJS%Y,+S/17ZYNR!YE7\XT(4+&!;]%2JL&P&NFQ,N0[UP86^S%D)V%$+8
M.V&&]+UO^1+&.U A-&7!:[S%JZ&*0+#'NUO)&RR[*P6QZU;.6S5A4[VJ]+W:
M2[[*V[W*ZQ#H*ROKVQ$@(+QZVD(+^+ZNV[]5V+J.HTKG&R^RM &TJZ&4-&4*
MQD*[A4