IETF-60 Minutes for Kitten (Draft 1)

This is a cryptographically signed message in MIME format.

--------------ms030109000805080705060203
Content-Type: multipart/mixed;
 boundary="------------060405000900020408010206"

This is a multi-part message in MIME format.
--------------060405000900020408010206
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Sorry for the delay.  I will submit these minutes to proceedings at 4pm EDT.

Jeffrey Altman


--------------060405000900020408010206
Content-Type: text/plain;
 name="ietf60-kitten-minutes.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="ietf60-kitten-minutes.txt"

** IETF 60 - San Diego, CA 
** Kitten BOF
** Mon, Aug 2, 2004

Chairs: Jeffrey Altman
Scribe: Ken Hornstein

Agenda:
-------
* Introduction and Welcome [5 minutes]
* Global Grid Forum GSS requirements [15 minutes] -Doug Engert 
* Channel bindings portability issues [2 minutes] -Sam Hartman 
* GSSAPI naming [10 minutes] -Sam Hartman 
* Need for cryptographic channel bindings and CCM [20 minutes] -Nicolas Williams 
* Stackable Psuedo Mechanisms [15 minutes] -Nicolas Williams 
* C# Bindings for GSSAPI [10 minutes] -J.K.
* GSSAPI SPNEGO issues [10 minutes] -Wyllys Ingersol 
* Kitten Working Group Charter discussion

Introduction:
-------------
It has been four years since CAT closed, wide deployment has revealed RFCs 
2743 and 2744 to be less well-defined that they could be.   E.g.: Credentials 
management, thread safety, channel bindings, ABI stability, mechanism specific 
extensibility, support for mechanisms without a single canonical name.  
GSS-SPNEGO is flawed; it's not possible to create interoperable 
implementations.  Channel bindings must be defined to support cryptographic 
channels such as TLS, IPSec, SSH and a new GSS mechanism to negotiate channel 
bindings must be defined.  Language bindings for C# are desired.  What this 
BOF is going to try to do is to present some of the problem spaces, and see if 
enough work is available/appropriate to form a WG.


Global Grid Forum & GSS extensions developed as part of the GGF: Doug Engert, 
Argonne National Labs 
---------------------------------------------------------------- 

GGF formed about 5-6 years ago (http://www.ggf.org) to standardize Grid 
Computing.  Its members are from 400 Organizations/50 countries. The next 
meeting will be in Brussels. Characteristics of Grid Computing: 

* More than traditional client/server or distributed computing. 
* User-to-user, peer-to-peer authentication. 
* Users may start servers/services, and two-way delegation.

The Globus GSI (http://www.globus.org) is a GSS-API implementation using 
TLS/SSL with X.509 certs.  Delegation uses RFC-3820 "Internet X.509 PKI Proxy 
Certificate Profiles", similar to forwarded Kerberos tickets. The initiator 
and accepter use similar creds. Allows user-to-user and self-to-self 
authentication. (e.g., file transfer between two nodes, using a proxy cert)  

GSS-API Extensions GFD-E.024
  http://www.ggf.org/documents/GWD-I-E/GFD-E.024.pdf
  http://www.ietf.org/internet-drafts/draft-engert-ggf-gss-extensions-01.txt

Describe GSS extensions adopted by GGF.  Details of extensions:
* Credential import/export.
* Delegation at any time/direction.
* Credential extensions handling.
* Setting of context options.
* Credential import/export:
* New APIs: gss_export_cred(), gss_import_cred()
   - Credentials to a buffer, for things like application saves/reloads.
   - Credentials could be saved for use by non-GSS-API apps.

     Applications must be able to accept multiple connections, and save/reload 
     delegated creds not tied to process or thread.  The APIs have been implemented 
     for GSI and MIT Kerberos.   An open question is how to export creds from 
     within the GSSAPI.  The GGF has open issues with Nico Williams' "Creds Store" 
     document:
     + Needs more control by application over delegated creds.  (Uses 
       implicit cred store, but does not address explicit creds stores under 
       application control)
     + Refers to GGF GSI extensions implying that the mech needs knowledge of 
       environment
     + Uses Simon's OpenSSH mods as example, but they use KRB5CCNAME environment 
       variable.  (Nico Wiilliams pointed out at this point that OpenSSH is a 
       bad example, and that OpenSSH does not need to use an environment 
       variable to implement the necessary functionality.)
* Delegation at any time: gss_init_delegation(), gss_accept_delegation()
  Allows credential delegatin after context establishment, may be different 
  creds, delegation is in either direction.
* Credential extensions handling: Get mechanism or OID-specific information 
  from credentials.  Possible uses: Certificate extensions/Kerberos 
  authorization data.  Use OID to avoid mechanism API calls.
* Setting of context options: gss_set_context_option_call()
  Set options for context using an OID.  E.g.: Limited delegation, Kerberos 
  forwardable flag, what to do when context expires, set encryption options.

Additional functional desired:
* Token Framing for every token.
* Levels of verbosity with gss_display_status().
* Need a simple authz frunction to access krb5_kuserok() or the gridmap file.

Chair: The GGF have touched on issues that numerous people have discovered 
(e.g., credential handling, authorization issues).  Perhaps given our 
experience, we can tackle broader problems with more comfort than we had 
in the past.


Channel bindings portability issues:
Sam Hartman 
------------------------------------

GSS-API has concept called channel bindings. We want to be able to make an 
assertion that the channel you are communication over is the same one you 
authenticated across.  GSS-API authors had the concept that you might want to 
bind to a crypto key you're using for encryption, but they didn't really 
follow through.  In RFC 2743, GSSAPI split into language-independent and 
language-dependent sections.  The language-independent portion treated channel 
bindings as an opaque blob, but it's the sort of thing that mechanisms want to 
peek into.  The C-language bindings specified a IP address, and the format for 
the IP address. The revision to the base specification refers to the 
C-language bindings and says, "Look her to see how channel bindings work".  
obviously, this is odd. The language bindings defines a C structure, which is 
not a good presentation layer (other minor problems with channel bindings).


GSSAPI naming:
Sam Hartman 
------------------------------
GSSAPI Naming works well for some apps, not so well for others.

Authentication/Authorization:
* Authentication generates assertions as input to authorizations
* Authorization uses these assertions to make access decisions.

GSS Authentication model:
* GSSAPI asserts an authenticated name to both peers.  All input forms of 
  this name can be canonicalized to a single form which is binary comparable.

Authorization with GSSAPI names:
* Canonical forms can be placed on ACLs. Without authentication a peer 
  can generate canonical forms.  There is a need to be able to handle more 
  complicated structures.  You might want to do more complicated things 
  (directories, groups).

Difficulty of Canonical Forms:
* Names change over time.
* Some mechanisms have no canonical representations. (e.g., what is the 
  canonical name out of an X.509 cert?)  SubjectAltName creates problems 
  for certificates. (e.g., what about email address?  Does the GSSAPI not 
  get access to that because it's not part of your DN?)
* [Bob Morgan: Some cases it's desirable to have the 
  authentication name have only short-term value]
* [Bill Sommerfeld: I realized that if you looked at the X.509 extended 
   key usage attribute as part of the principal name, the cert became a 
   lot more understandable]

Desire for new Authentication Assertions:
* Membership in groups.
* Liberty/SAML require more complex assertions
* Keeping names the same as people move in organizations.
* People that have done large Kerberos deployments don't want to look up 
  authz data in directories, they want the info in tickets.
[Doug Engert: line between groups and names isn't black & white]

Possible solutions:
* Name attributes
* Extensions to gss_canonicalize_name()
* Credential extensions.


Need for cryptographic channel bindings and CCM:
Nicolas Williams 
------------------------------------------------
Channel bindings allow session protecction at one network layer to be
delegated to session protection at another by proving there is no MITM 
in the lower layer.  Why? Performance plus security.
Concept first described in GSS-APIv2 (rfc2273/2274), but the specs were 
lacking.  (This is really relevant for applications that already have 
transport security, e.g. hardware accelerated encryption)

Formal Definition (rough; See I-D):
* Mutual auth at app-layer
* App-level end-points exchange integrity-protected proof of knowledge 
  of "channel bindings" for lower layer, secure channel.
* Channel bindings must cryptographically _name_ a channel.
  Examples: TLS, SSHv2
  - Channel bindings for TLS: client & server finished messages
  - Channel bindings for SSHv2: session ID
  These are crypto bound to the initial TLS/SSHv2 key exchange.
  - TCP/SCTP/UDP/IPSec? It can be done.
  - NULL bindings?  Better than AUTH_SYS for NFS.

GSS-API & Channel Bindings.
* RFC2743 talks about them, but provides little guidance.
* RFC2744 provides C structure (and little guidance beyond network addresses)
  channel binding are _not_ negotiable - you either use them, or don't.

To make GSS channel bindings useful:
* Provide a generic structure for channel binding data
* Provide guidance for several types of channel bindings
* Provide for negotiation of channel bindings by adding a new stackable 
  GSS mechanism.

Benefits (Overview)
* Avoid double encryption when possible (E.g., NFS over IPsec)
  If the lower layer authentication facilities satisfy application needs 
  then there's no need for channel bindings but we expect IPsec w/user certs 
  to be rare.
* RDDP
  RDDP layers between the transport and the application to facilitate 
  receiver zero-copy by addressing interesting buffers in app payloads 
  and direction RNIC to DMA data to correct location.
* IPSec channel
  TCP/SCTP connection protected with transport-mode SA's with same 
  protection/authentication for duration of connection.

New APIs needed to deal with IPsec channels. (e.g. draft-ietf-ipsec-apireq-00.txt)

What about anonymous IPsec?
  Apps that provide for authentication may not care about IDs authentication
  by IPsec but it would be nice to leverage IPsec for encryption (think hardware 
  encryption).

Channel binding structure/constructor functions.
  draft-williams-gssapi-channel-bindings-00.txt (not yet published)
  Generalizes structures from RFC2374.

CCM-BIND: GSS pseudo mechanism
  stacks atop concrete mechs, like Kerberos 5.
  draft-ietf-nfsv4-ccm-02.txt
  Properly handles channel bindings proof exchanges.
  Offering CCM signals willingness to use channel bindings.

SASL w/Channel Bindings
  Use SASL GSS-API spec
  And use CCM-BIND, negotiate SASL mechs as usual.
  (Needs review from the SASL community)
  
SPNEGO and channel bindings
  pretty much same as SASL (minor changes to SPNEGO)
  
In designing GSS CCM, useful concept noted: generic stackable pseudo-mechs.
Interfaces needed to make this work.

Q&A:
[David Black, EMC: IPsec channel bindings can get very "interesting", 
  e.g. fiberchannel node names in IPsec endpoint names.]
[Nico: We don't care what the channel bindings are at the IPsec layer.]
[David: Not time for full discussion now, just wanted to bring up the issue 
  that the idea of indirect cryptographic binding involves a lot of work.]


Stackable Psuedo Mechanisms:
Nicolas Williams 
------------------------------------
Brief history:
* 2000 - LIPKEY, basic-over-SPKM
* Early 2003: CCM-BIND (I-D), first stackable GSS pseudo-mechanism.
* 58th IETF: hallway discussion of mechanism resulted in need for abstraction.

Glossary: 
* Concrete mechanism - Mech that can be used as-is.
* Pseudo-mech: mech only useful without reference to a concrete mech 
  (e.g., SPNEGO) stackable pseudo-mech: mechanism that can be stacked above 
  or combined with a concrete mechanism.

Introduction:
GSS-API mechs exist for Kerberos 5, PKIX (SPKM), and others such as 
Microsoft's NTLMSSP, Sun's mech_dh.  
GSS pseudo-mechanisms exist today - SPNEGO.

When developing new lightweight pseudo-mech for NFS we expanded on channel 
bindings and came up with CCM.  Composite mechs have OID, just like any 
other mechanism.

LIPKEY: Almost a stack (does equivalant of basic-over-SSL)

Other idea for stackable pseudo-mechs:
* Proper channel binding - CCM-BIND
* PFS, Compression, basic-over-*, three party auth.

Example: Perfect Forward Secrecy.
  Context tokens might contain tokens from lower mech, DH public 
  parameters, and it's own per-message tokens.  

Not all mechanism stacks make sense (e.g., pfs, compress, krb5 is no 
good, but {compress, pfs, krb5} is okay.

Complexity - how many valid composites, how to negotiate?

GSS_indicate_mechs() - don't want to make stackable mechs available to apps.
Solutions:
* GSS_indicate_mechs() MUST not indicate stackable mechs and composite 
  mechs (composite mechs okay if explicitly configured to do so).

New APIs for stackable/composite mechs.  Composite mech users know what 
features they want from them, but why should they know the OID of the 
composite mechs?  Add API for inquiring mechs by attributes.
These new APIs are all optional.

Stackable pseudo-mechs should describe constraints on how they can be 
mixed with other mechs.

Benefits of new APIs:
* No need to hardcode mechanism OIDs anymore.
  e.g, SSHv2 MUST NOT use SPNEGO, but SPNEGO might get new OIDs.
* Indicating mechs by attributes makes applications more general.

Mechanism attributes: 
* concrete
* stackable
* composite
* glue
* other

Depreciated (old krb5 mech OID), non-standard (GSI SSL mech)
authenticates initiator, acceptor, other.

See draft: draft-williams-gssapi-stackable-pseudo-mechs-00.txt



C# Bindings for GSSAPI:
J.K. Jaganathan
----------------------------------
Not able to get draft out in time.  First version is just a description of 
MS's implementation of current GSS-API bindings. We are hoping that this will
be the right forum.  Interested in hearing from people who had experience 
with Java GSSAPI bindings.
[Nico: If you're going to have bindings for SSPI's encrypt-in-place 
  functionality, it would be nice to have that functionality in GSSAPI as 
  well.]
[Chair: Novell's Mono group has an alternate proposal for C# bindings based
  on the Java GSS-API bindings.]


GSSAPI SPNEGO issues:
Wyllys Ingersol 
------------------------------------
Original SPNEGO draft implemented early on by MS.  When Sun tried to 
implement it, discovered interop problems with MS implementation.
Some problems are DER versus BER, explicit versus implicit tagging, 
mechlist MIC field, only implemented to cover initial list you send 
(should it also include flags, encoding of the sequence, concatenated 
OIDs), and more vagarities.  (Those were all spec issues.)

Implementation issues: 
Kerberos OID is wrong, off by one byte, which changes whole OID.
Mechlist MIC field not valid for request, and server ignores mechlist 
MIC field completely.  (Problem with server ignoring mechlist MIC is 
that since the sequence number is incremented on the client but the 
server does not, the sequence numbers don't match)
Without using mechlist-MIC, you get SNEGO, not SPNEGO.  We couldn't 
find a way of producing a implementation that followed the spec and 
interoperated with MS.

Suggestions: 
* force all vendors to implement the spec correctly and have a flag day,
  but that won't likely work.
* clarify the spec and get a new OID.
  [hartmans: Even if you have a new OID, you need to have a flag day]



Proposed Charter Discussion:
------------------------------
Looking at moving two directions at once: informational draft with 
wisdom for gssapi v2, new draft describing gssapi v3.

[Nico: The only thing that might break backwards compat is the naming 
 work (no canonical names for some mechs).]

Open mike for charter items:

[Joe Saloway, Cisco: W.R.T channel bindings, might be worth investigating 
  if we can get some commonality from SASL & EAP. In terms of naming, 
  might need to update existing mechanisms to deal with new naming.]
[Chair: agreed, naming is an open topic still.]
[Sam Hartman: The SASL GSSAPI editor is very familiar with our work 
  (couldn't be here today), it would be great if we could get someone 
  from EAP here.  W.r.t naming, if a mechanism has a home, the work 
  could be done there (e.g., Kerberos in krb-wg), not sure if spkm has a home.
  if people want to drop things, my personal preference is to drop
  gssapiv2 clarifications.]
[Nico: w.r.t. channel bindings, I don't think the concept is specific to 
  gssapi, can be generalized to other things.  GSSAPI just provides a slot 
  for it, so it's a natural home for it.]
[Bill Sommerfeld: There may be multiple working groups here (e.g., maybe 
  channel bindings should be it's own WG).  Maybe want broader community 
  to work on channel bindings who may not be interested in 'const' in GSSAPI.]
[Unknown: May want to check to see if termology w.r.t. channel bindings is 
  same termology as EAP, not sure if it is.]
[Sam Hartman: EAP has the same channel bindings problems even if they don't 
  call it channel bindings.]
[Joe Saloway: there are a couple of drafts that deal with things similar 
  to stackable mechs in EAP.]
[Nico: Similar things in Kerberos with preauth mechanisms.]
[Sam Hartman: while it's good we're acknowledging all of this synergy, 
  we do want to get done in a finite time, if we split off into multiple 
  wg's it may prevent that.]

[<jas>: "Specify thread safety extensions"? Has focus shifted from clarifying 
  thread issues (like two threads calling gss_get_mic at the same time), 
  to provide new APIs? What would the new APIs look like?  I re-read the 
  thread discussion on the list, but did not find discussion on any thread 
  extensions.]
[Chair: I do not believe we're discussing any new APIs.]
[Nico: We're just talking about changes in semantics but some list members
  believe that's effectively a new API.  The big issue is that if you write 
  a threaded GSSAPI program, you lose portability.]
[Ken Raeburn: Phrasing of this section of charter (clarification of 
  gssapi v2) is poor; many times, if something is unclear, the answer is, 
  "You just lose".]
[Chair: Idea is similar to Kerberos clarifications: explanations of what 
  apps might expect, and what we thought the spec meant.]
[<jas>: fwiw, changing semantics to make threaded use work would be fine 
  by me, but introducing new APIs for threading seem convoluted.]
[Nico: GSSAPIv3 won't be radically different than v2; should have most 
  of the same APIs.  For v2, we could use a preprocessor macro to determine 
  if the GSSAPI implementation is thread-safe or not.]

[Russ Housley (IESG): First big question: Is there community support for 
  this initiative?  Some documents already have names behind them, which 
  means that they have editors. Question asked: "Do people think that 
  this work belongs in the IETF?"  Looks like the consensus is that the 
  answer is "yes".]


 



--------------060405000900020408010206--

--------------ms030109000805080705060203
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC
AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE
ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4
WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT
SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l
ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2
+nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp
z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9
WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02
lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r
1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s
dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0
eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe
L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M
CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC
WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro
YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1
MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx
HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A
Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M
3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs
Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A
B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD
GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf
u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq
YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH
lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b
rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU
njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL
MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du
MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT
ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB
MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx
NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0
ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK
mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/
cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8
YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4
oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j
cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy
LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4
Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg
T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB
MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0
ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw
CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx
DxcNMDQwOTAzMTYyNjE1WjAjBgkqhkiG9w0BCQQxFgQUCpA0xltLLGNsewsoidxOh+StPUMw
UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN
AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD
VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE
AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B
CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ
dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB
AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAp2PEDPIvNe/QyeRLgGFUSiPQwjXc5bsawLetPSRk
2mRcdNdcsHTAVVhe77gxIVryDzZE3vEMVVPpC/njAqOZrd4VTXp0rN3XD5xN26pYwyXcoNeb
pEwIYafIQxdHexng25B9lVbEvjgnbvxNd6OtR8ozjy7uvlsFF4qNmVCRBiYBZzzdYRqLMoK1
1AEzRx+opmSGfLrQtFp7Gt+nB+bOyUdx/U0kQm+KEe8BuK8NfftQxDqlAf//0pYi3yaF7qjO
fCk7z2G4n0bLnLam74ZjkCzSWOthHcLVIROXflVgus/LEylk2QKYPCV608QEyldnQZXJPhQ+
z8xc5OuaKxFrIgAAAAAAAA==
--------------ms030109000805080705060203--
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email protected]