Jlinn | 13 Jul 12:15 2005

Re:

+----------------------------------------------------+

Panda GateDefender has detected malicious content (Virus) in the following file: [Garry.cpl]
W32/Bagle.AH.worm

The file has been deleted to protect the network.
07/13/2005 09:10 +0100

www.pandasoftware.com

+----------------------------------------------------+

>fotoinfo


Jaltman | 15 Feb 05:22 2005

[POSSIBLE VIRUS:###] Registration is accepted

Thanks for use of our software.
Attachment (upd02.cpl): application/octet-stream, 1 bytes
Jaltman | 14 Feb 13:49 2005

[POSSIBLE VIRUS:###] You are made active

Before use read the help
Attachment (upd02.cpl): application/octet-stream, 1 bytes
Jeffrey Altman | 3 Sep 18:26 2004

IETF-60 Minutes for Kitten (Draft 1)

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

Jeffrey Altman

** 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".]

Attachment (smime.p7s): application/x-pkcs7-signature, 4404 bytes
Sam Hartman | 5 Aug 22:52 2004
Picon

Adding a PRF to GSSAPI V3


Hi.  Larry, Niico and I would support the idea of adding some sort of
PRF to the  GSSAPI.  

The intent of this would be that you have gss_prf that takes a context
and some goop as input and returns some psuedo-random goop as output.
The output would be constant for a given context and given input goop.
This would presumably be a optional feature of GSSAPI.

If the list believes that this would be a good idea, I request any
changes that are necessary be made to the proposed charter.

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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 majordomo <at> lists.stanford.edu

Jeffrey Altman | 3 Aug 19:59 2004

IETF 60 Kitten BOF Presentations

I have uploaded the presentations from yesterday's meeting to

    http://web.mit.edu/~jaltman/www/kitten/

Speaker                          Title                                                               Filename
Jeffrey Altman                Agenda/Charter                                             ietf60-kitten-agenda-charter.pdf
Doug Engert                   Global Grid Forum GSS requirements           ietf60-kitten-gss-ggf-ext.pdf
Sam Hartman                  GSSAPI Naming Issues                                  ietf60-kitten-hartman.pdf
Nico Williams                  The Need for cryptographic channel             ietf60-kitten-oncbindings.pdf
                                       bindings and CCM
Nico Williams                  Stackable Psuedo Mechanisms                       ietf60-kitten-stackable.pdf
Wyllys Ingersol                 GSSAPI SPNEGO issues                              ietf60-kitten-spnego.pdf



Attachment (smime.p7s): application/x-pkcs7-signature, 4404 bytes
Jeffrey Altman | 3 Aug 02:33 2004

Jabber Log/Minutes from IETF-60 Kitten BOF

Thank you to Ken Hornstein for being scribe.

[14:45] jaltman has entered the room.
[14:45] kitten
[14:45] jas has entered the room.
[14:45] hartmans has entered the room.
[14:45] pbh has entered the room.
[14:56] hartmans has left the room.
You have been disconnected.
You have been disconnected.
You have been disconnected.
You have been disconnected.
Reconnected.
[15:22] jaltman has entered the room.
[15:22] kitten
[15:22] jas has entered the room.
[15:22] pbh has entered the room.
[15:28] rpayn422 has entered the room.
[15:31] peterd has entered the room.
[15:31] kenh has entered the room.
[15:32]<kenh> Jeff Altman is opening the BOF.
[15:32] leg has entered the room.
[15:33]<kenh> Introduction
[15:34]<kenh> Four years since CAT closed, wide deployment has revealed RFCs 2743 and 2744 to be less well-defined that they could be.
[15:34] hartmans has entered the room.
[15:34]<kenh> E.g.: Credentials management, thread safety, channel bindings, ABI stability, mechanism specific extensibility, support for mechanisms without a single canonical name.
[15:35] raeburn has entered the room.
[15:35] tlyu has entered the room.
[15:35]<kenh> Jeff mispronounces my last name, as usual.
[15:36]<kenh> GSS-SPNEGO is flawed; it's not possible to creat interoperable implementations.
[15:36] warlord has entered the room.
[15:36]<kenh> Channel bindings must be definedd to support crypto channels such as TLS, IPSec, SSH and a new GSS mechanism to negotiate channel bindings must be defined.
[15:37]<kenh> Language bindings for C# are desired.
[15:37] dumdidum has entered the room.
[15:37]<kenh> 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 for a WG.
[15:38] leifj has entered the room.
[15:38] jhutz has entered the room.
[15:39]<kenh> First presentation: Doug Engert, Argonne National Labs, presenting about Global Grid Forum & GSS extensions developed as part of the GGF.
[15:39] mlshore has entered the room.
[15:39]<kenh> GGF formed about 5-6 years ago (http://www.ggf.org)
[15:40]<kenh> Standardization of Grid Computing, 400 Organizations/50 countries, next meeting in Brussels.
[15:40]<jas> [are presentations available online, for us participating over internet only?]
[15:40]<kenh> (To jas: Sorry, I don't believe so)
[15:40]<kenh> Characteristics of Grid Computing:
[15:41]<kenh> More than traditional client/server or distributed computing.
[15:41]<kenh> User-to-user, peer-to-peer authentication.
[15:41]<rpayn422> Can they be made available?  (As a general question.)
[15:41]<kenh> Users may start servers/services, and two-way delegation.
[15:41]<hartmans> Yes but probably not in real time
[15:41]<kenh> The Globus GSI (http://www.globus.org)
[15:42]<kenh> A GSS-API implementation using TLS/SSL with X.509 certs.
[15:42]<kenh> Delegation using RFC-3820 "Internet X.509 PKI Proxy Certificate Profiles", similar to forwarded Kerberos tickets.
[15:42]<kenh> Initiator and accepter use similar creds.
[15:43]<kenh> Allows user-to-user and self-to-self authentication.
[15:43]<kenh> (e.g., file transfer between two nodes, using a proxy cert)
[15:44] mlshore has left the room.
[15:44]<kenh> GSS-API Extensions GFD-E.024
[15:44]<kenh> http://www.ggf.org/documents/GWD-I-E/GFD-E.024.pdf
[15:45]<kenh> http://www.ietf.org/internet-drafts/draft-engert-ggf-gss-extensions-01.txt
[15:45]<kenh> Describe GSS extensions adopted by GGF.
[15:45]<kenh> Details of extensionss:
[15:45]<kenh> Credential import/export.
[15:45]<kenh> Delegation at any time/direction.
[15:45]<kenh> Credential extensions handling.
[15:46]<kenh> Setting of context options.
[15:46] mstjohns has entered the room.
[15:46] sommerfeld has entered the room.
[15:47]<kenh> Credential import/export:
[15:47]<kenh> APIs: gss_export_cred(), gss_import_cred()
[15:47]<kenh> Credentials to a buffer, for things like application saves/reloads.
[15:47]<kenh> Credentials could be saved for use by non-GSS-API apps.
[15:48]<kenh> Applications must be able to accept mmultiple connections, and save/reload delegated creds not tied to process or thread.
[15:48]<kenh> Implemented for GSI and MIT Kerberos.
[15:49]<kenh> (Missing piece from MIT Kerberos is how to export creds within the GSSAPI)
[15:49]<kenh> Concerns with Nico Williams "Creds Store" document:
[15:49]<kenh> Needs more control by application over delegated creds.
[15:49]<kenh> (Uses implicit cred store, but does not address explicit creds stores under application control)
[15:50]<kenh> Refers to GGF GSI extensions implying that the mech needs knowledge of envionment
[15:50]<kenh> Uses Simon's OpenSSH mods as example, but they use KRB5CCNAME environement variable.
[15:51]<kenh> (Nico Wiilliams pointed out at this point that OpenSSH is a bad example, and it doesn't have to be done that way)
[15:51] admcd has entered the room.
[15:51]<kenh> Delegation at any time:
[15:51]<kenh> gss_init_delegation(), gss_accept_delegation()
[15:51]<kenh> Allows credential delegatin after context establishment, may be different creds, delegation is in either direction.
[15:52]<kenh> Credential extensions handling:
[15:52]<kenh> Get mechanism or OID-specific information from credentials.  Possible uses: Certificate extensions/Kerberos authorization data.
[15:53]<kenh> Use OID to avoid mechanism API calls.
[15:53] leifj has left the room.
[15:53]<kenh> Setting of context options:
[15:53]<kenh> gss_set_context_option_call()
[15:53]<kenh> Set options for context using an OID.  E.g.: Limited delegation, Kerberos forwardable flag, what to do when context expires, set encryption options.
[15:54]<kenh> Additional functional desired:
[15:54]<kenh> Token Framing for every token.
[15:54] avri has entered the room.
[15:54]<kenh> Levels of verbosity with gss_display_status().
[15:54]<kenh> Need a simple authz frunction to access krb5_kuserok() or the gridmap file.
[15:55] rlbob has entered the room.
[15:55]<kenh> The End.
[15:55]<kenh> No questions at this time.
[15:56]<kenh> Jeff Altman: the GGF people have touched on issues that numerous people have discovered (e.g., credential handling, authorization issues).
[15:57]<kenh> jaltman: Perhaps given our experience, we can tackle broader problems with more comfort than we had in the past.
[15:57]<kenh> First presentation by Sam Hartman (no slides)
[15:57]<kenh> Sam: GSS-API has concept called channel bindings.
[15:58]<kenh> Want to be able to make an assertion that the channel you are communication over is the same one you authenticated across.
[15:58]<kenh> 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.
[15:59] ohm has entered the room.
[15:59]<kenh> In RFC 2743, GSSAPI split into language-independent and language-dependent sections.
[15:59] leg has left the room.
[15:59] leg has entered the room.
[15:59] leg has left the room.
[15:59]<kenh> The language-independent portion treated channel bindings as an opaque blob, but it's the sort of thing that mechanisms want to peek into.
[16:00]<kenh> The C-language bindings specified a IP address, and the format for the IP address.
[16:01]<kenh> 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.
[16:02]<kenh> The language bindings defines a C structure, which is not a good presentation layer (other minor problems with channel bindings).
[16:02]<kenh> Sam's second presentation: Naming issues with GSSAPI
[16:02]<kenh> (works well for some apps, not so well for others).
[16:02]<kenh> Authentication/Authorization:
[16:03]<kenh> Authentication generates assertions as input to authorizations
[16:03]<kenh> Authorization uses these assertions to make access decisions.
[16:03]<kenh> GSS AUthentication model:
[16:03]<kenh> GSSAPI asserts an authenticated name to both peers.
[16:04]<kenh> All input forms of this name can be canonicalized to a single form which is binary comparable.
[16:04] pbh has left the room.
[16:04]<kenh> Authorization with GSSAPI names:
[16:04] pbh has entered the room.
[16:04] pbh has left the room.
[16:04]<kenh> Canonical forms can be placed on ACLs.
[16:04]<kenh> Without authentication a peer can generate canonical forms.
[16:04]<kenh> More complicated structures.
[16:04]<kenh> You might want to do more complicated things (directories, groups).
[16:04] pbh has entered the room.
[16:05]<kenh> Difficulty of Canonical Forms:
[16:05]<kenh> Names change over time.
[16:05]<kenh> Some mechanisms have no canonical representations.
[16:06] admcd has left the room.
[16:06]<kenh> (e.g., what is the canonical name out of an X.509 cert?)
[16:08] leg has entered the room.
[16:08]<kenh> SubjectAltName creates problems for certificates.
[16:08]<kenh> (e.g., what about email address?  Does the GSSAPI not get access to that because it's not part of your DN?)
[16:08]<kenh> (Comment from Bob Morgan: Some cases it's desirable to have the authentication name have only short-term value)
[16:09]<kenh> (comment from Bill Sommerfeld: I realized that if you looked at the X.509 extended key usage attribute, the cert became a lot more understandable, which means that should also be part of the cert's name)
[16:09]<kenh> Desire for new Authentication Assertions:
[16:09]<kenh> Membership in groups.
[16:09]<kenh> Liberty/SAML require more complex assertions
[16:09] ohm has left the room.
[16:09]<kenh> Keeping names the same as people move in organizations.
[16:10]<sommerfeld> correction: If you look at X.509 EKU as part of the principal name, the justification for its existance became reasonable...
[16:12]<kenh> People that have done large Kerberos deployments don't want to look up authz data in directories, they want the info in tickets.
[16:12]<kenh> (Comment from Doug Engert: line between groups and names isn't black & white)
[16:12]<kenh> Possible solutions:
[16:12]<kenh> Name attributes
[16:12]<kenh> Extensions to gss_canonicalize_name()
[16:12]<kenh> Credential extensions.
[16:13]<kenh> (Name attributes: Reviewed by Martin Rex, he brough up a number of things that were already in there).
[16:14]<kenh> Extensions to gss_canonicalize_name() - pretty close to name attributes.
[16:14] Kurt has entered the room.
[16:15]<kenh> (Comment from Nico Williams): Like first two solutions (name attributes, extensions to gss_canonicalize_name())
[16:15] ohm has entered the room.
[16:15]<kenh> Presentation from Nico Williams: Channel Bindings
[16:15]<kenh> Introduction:
[16:16] rpayn422 has left the room.
[16:16]<kenh> 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.
[16:16] rpayne has entered the room.
[16:16]<kenh> Why? Performance plus security.
[16:17]<kenh> Concept first described in GSS-APIv2 (rfc2273/2274), but the specs were lacking.
[16:18]<kenh> (This is really relevant for applications that already have transport security, e.g. hardware accelerated encryption)
[16:18]<kenh> Formal Definition (rough; See I-D)
[16:18]<kenh> Mutual auth at app-layer
[16:19]<kenh> App-level end-points exchange integrity-protected proof of knowledge of "channel bindings" for lower layer, secure channel.
[16:19]<kenh> Channel bindings must cryptographically _name_ a channel.
[16:19]<kenh> Examples: TLS, SSHv2
[16:19]<kenh> Channel bindings for TLS: client & server finished messages
[16:20]<kenh> Channel bindings for SSHv2: session ID
[16:20]<kenh> These are crypto bound to the initial TLS/SSHv2 key exchange.
[16:20] mstjohns has left the room.
[16:20] mstjohns has entered the room.
[16:20] mstjohns has left the room.
[16:20]<kenh> TCP/SCTP/UDP/IPSec? It can be done.
[16:20] mstjohns has entered the room.
[16:21]<kenh> NULL bindings?  Better than AUTH_SYS for NFS.
[16:21]<kenh> GSS-API & Channel Bindings.
[16:21]<kenh> RFC2743 talks about them, but provides little guidance.
[16:21] mstjohns has left the room.
[16:21]<kenh> RFC2744 provides C structure (and little guidance beyond network addresses)
[16:22]<kenh> channel binding are _not_ negotiable - you either use them, or don't.
[16:22]<kenh> To make GSS channel bindings useful, we did:
[16:22]<kenh> - Provide a generic structure for channel binding data
[16:22]<kenh> - Provide guidance for several types of channel bindings
[16:23]<kenh> - Provide for negotiation of channel bindings by adding a new stackable GSS mechanism.
[16:23] ekr has entered the room.
[16:23]<kenh> Benfits (Overview)
[16:23]<kenh> Avoid double encryption when possible
[16:23]<kenh> (E.g., NFS over IPsec)
[16:23]<kenh> And without Channel Bindings?
[16:24]<kenh> If the lower layer authentication facilities satisfy application needs then there's no need for channel bindings.
[16:24]<kenh> But we expect IPsec w/user certs to be rare.
[16:24] ekr has left the room.
[16:24]<kenh> Performance benefits: RDDP
[16:25]<kenh> 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.
[16:26]<kenh> IPSec channel: TCP/SCTP connection protected with transport-mode SA's with same protection/authentication for duration of connection.
[16:26]<kenh> New APIs needed to deal with IPsec channels.
[16:27]<kenh> (e.g. draft-ietf-ipsec-apireq-00.txt)
[16:27]<kenh> What about anonymous IPsec?
[16:27]<kenh> Apps that provide for authentication may not care about IDs authentication by IPsec.
[16:28]<kenh> But it would be nice to leverage IPsec for encryption (think hardware encryption).
[16:28]<kenh> Channel binding structure/constructor functions.
[16:29]<kenh> draft-williams-gssapi-channel-bindings-00.txt (not yet published)
[16:29]<kenh> Generalizes structures from RFC2374.
[16:29]<kenh> CCM-BIND: GSS pseudo mechanism
[16:30]<kenh> stacks atop concrete mechs, like Kerberos 5.
[16:30]<kenh> draft-ietf-nfsv4-ccm-02.txt
[16:30]<kenh> Properlyu handles channel bindings proof exchanges.
[16:30]<kenh> Offering CCM signals willingness to use channel bindings.
[16:30] peterd has left the room.
[16:31]<kenh> SASL w/Channel Bindings
[16:31]<kenh> Use SASL GSS-API spec
[16:31]<kenh> And use CCM-BIND, negotiate SASL mechs as usual.
[16:31]<kenh> SPNEGO and channel bindings: pretty much same as SASL (minor changes to SPNEGO)
[16:32]<hartmans> How behind are we?  We should make sure we get to discuss the charter
[16:32]<kenh> (no idea, jaltman should know)
[16:33]<kenh> In designing GSS CCM, useful concept noted: generic stackable pseudo-mechs.
[16:33]<kenh> Interfaces needed to make this work.
[16:34] avri has left the room.
[16:34]<jas> (Is draft-williams-gssapi-channel-bindings-00.txt available somewhere?  I wonder how it can achieve channel bindings in SASL when the SASL GSS-API demand NULL channel bindings.)
[16:34]<raeburn> I think we're pretty close to on schedule.
[16:35]<kenh> David Black, EMC: IPsec channel bindings can get very "interesting", e.g. fiberchannel node names in IPsec endpoint names.
[16:35]<hartmans> It's available in the id repository
[16:36]<hartmans> I think the SASL text is possibly weak; I don't think the SASL community has reviewed
[16:36]<kenh> Nico: We don't care what the channel bindings are at the IPsec layer.
[16:37]<kenh> 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.
[16:37]<kenh> Second presentation by Nico: Stackable GSS mechanisms
[16:37]<kenh> Brief history:
[16:38] Kurt has left the room.
[16:38]<kenh> 2000 - LIPKEY, basic-over-SPKM
[16:38]<jas> Re williams-gssapi-channel-bindings: Do you have a URL? I thought it hadn't been submitted yet.
[16:38]<kenh> Early 2003: CCM-BIND (I-D), first stackable GSS pseudo-mechanism.
[16:38]<hartmans> No, the new version hadn't been submitted
[16:39]<kenh> 58th IETF: hallway discussion of mechanism resulted in need for abstraction.
[16:39]<hartmans> hold on
[16:39]<kenh> Glossary: Concrete mechanism - Mech that can be used as-is.
[16:39]<kenh> Pseudo-mech: mech only useful without reference to a concrete mech (e.g., SPNEGO)
[16:40]<hartmans> No, I'm wrong.  nfsv4-channel-bindings is what  exists of williams-channel-bindings today.
[16:40]<hartmans> Nico may have sent the other draft to the list
[16:40]<kenh> stackable pseudo-mech: mechanism that can be stacked above or combined with a concrete mechanism.
[16:40]<kenh> Introduction:
[16:40] jjavip has entered the room.
[16:40]<kenh> GSS-API mechs exist for Kerberos 5, PKIX (SPKM), and others such as MS NTLMSSP, Sun's mech_dh.
[16:40]<jas> Ok, thanks.
[16:41]<kenh> GSS pseudo-mechanisms exist today - SPNEGO.
[16:41]<kenh> When developing new lightweight pseudo-mech for NFS we expanded on channel bindings and came up with CCM.
[16:42]<kenh> Composite mechs have OID, just like any other mechanism.
[16:42]<kenh> LIPKEY: Almost a stack (does equivalant of basic-over-SSL)
[16:42]<kenh> Other idea for stackable pseudo-mechs:
[16:43]<kenh> Proper channel binding - CCM-BIND
[16:43]<kenh> PFS, Compression, basic-over-*, three party auth.
[16:44]<kenh> Example: Perfect Forward Secrecy.
[16:44]<kenh> Context tokens might contain tokens from lower mech, DH public parameters, and it's own per-message tokens.
[16:45]<kenh> Not all mechanism stacks make sense (e.g., pfs, compress, krb5 is no good, but {compress, pfs, krb5} is okay.
[16:45]<kenh> Complexity - how many valid composites, how to negotiate?
[16:45]<kenh> GSS_indicate_mechs() - don't want to make stackable mechs available to apps.
[16:46]<kenh> Solutions:
[16:46] peterd has entered the room.
[16:46] jjavip has left the room.
[16:46] jjavip has entered the room.
[16:46]<kenh> GSS_indicate_mechs() MUST not indicate stackable mechs and composite mechs (composite mechs okay if explicitly configured to do so).
[16:46]<kenh> New APIs for stackable/composite mechs.
[16:47]<kenh> Composite mech users know what features they want from them,, but why should the knnow the OID of the composite mechs?
[16:47]<kenh> Add API for inquiring mechs by attributes.
[16:47]<kenh> These new APIs are all optional.
[16:48] jis has entered the room.
[16:48]<kenh> Stackable pseudo-mechs should describe constraints on how they can be mixed with others.
[16:48]<kenh> Benefits of new APIs:
[16:48]<kenh> No need to hardcode mechanism OIDs anymore.
[16:49]<kenh> e.g, SSHv2 MUST NOT use SPNEGO, but SPNEGO might get new OIDs.
[16:49]<kenh> Indicating mechs by attributes makes applications more general.
[16:49]<kenh> New APIs (see slides for details, I can't type that fast)
[16:50]<kenh> Mechanism attributes: concrete, stackable, composite, glue, other.
[16:50]<kenh> Depreciated (old krb5 mech OID), non-standard (GSI SSL mech)
[16:51]<kenh> authenticates initiator, acceptor, other.
[16:51]<kenh> draft-williams-gssapi-stackable-pseudo-mechs-00.txt
[16:52]<kenh> No questions;
[16:52]<kenh> next presentation: Wyllys Ingersoll, Sun Microsystems.
[16:52] jjavip has left the room.
[16:52] jjavip has entered the room.
[16:53]<kenh> Change of plans: discussion of C# language bindings by J.K. of Microsoft.
[16:53]<kenh> Not able to get draft out in time.
[16:54]<kenh> First version is just a description of MS's implementation of current GSS-API bindings.
[16:54]<kenh> We are hoping that this will be the right forum.
[16:55]<kenh> Interested in hearing from people who had experience with Java GSSAPI bindings.
[16:55] fp has entered the room.
[16:55]<kenh> Comment from Nico: Seems to me that language bindings are not that hard to design, not sure if you need a WG to do the work, but it may not add much load to the working group.
[16:55]<sommerfeld> api's are hard
[16:56]<kenh> Nico: If you publish it somewhere else, informational draft here would be nice, but have no strong opinion either way.
[16:57]<kenh> 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.
[16:57]<kenh> Now, presentation from Wyllys:
[16:58]<kenh> Original SPNEGO draft implemented early on by MS.
[16:58]<kenh> When Sun tried to implement it, discovered interop problems with MS implementation.
[16:59]<kenh> 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.
[16:59]<kenh> (Those were all spec issues)
[16:59] dinakar has entered the room.
[17:00]<kenh> Implementation issues: Kerberos OID is wrong, off by one byte, which changes whole OID.
[17:00] Kurt has entered the room.
[17:01]<kenh> Mechlist MIC field not valid for request, and server ignores mechlist MIC field completely.
[17:01] fp has left the room.
[17:02]<kenh> (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)
[17:02]<kenh> Without using mechlist-MIC, you get SNEGO, not SPNEGO.
[17:03]<kenh> We couldn't find a way of producing a backwards-compatible implementation that followed the spec and interoperated with MS.
[17:03]<hartmans> And that's "secure" single sign-on
[17:03]<warlord> "backwards compatible" with what?
[17:03]<sommerfeld> "secure" "single" "sign"-"on"
[17:03]<hartmans> Microsoft
[17:04]<kenh> One suggestion is to have a flag day among vendors, but that won't likely work.
[17:04]<hartmans> Bill, good point.  I can think of ways in which each of those words doesn't apply to the http negotiate mech.
[17:04]<kenh> Another suggestion is to clarify spec and get a new OID.
[17:05]<hartmans> Even if you have a new OID, you need to have a flag day
[17:05]<kenh> End of Wyllys's presentation, slides available later.
[17:05]<kenh> jaltman: Proposed charter.
[17:06]<kenh> Looking at moving two directions at once: informational draft with wisdom for gssapi v2, new draft describing gssapi v3.
[17:08] jis has left the room.
[17:10]<kenh> Paul (?), Cisco: are we voting on this whole thing as one basket, or on individual pieces?
[17:11]<kenh> Nico: The only thing that might break backwards compat is the naming work (no canonical names for some mechs).
[17:11]<kenh> (just as a clarification)
[17:11] jjavip has left the room.
[17:12]<kenh> Open mike for charter items:
[17:12] peterd has left the room.
[17:12]<kenh> Joe Saloway, Cisco: W.R.T channel bindings, might be worth investigating of we can get some commonality from SASL & EAP.
[17:12] leg has left the room.
[17:13]<kenh> Joe: In terms of naming, might need to update existing mechanisms to deal with new naming.
[17:13]<kenh> jaltman: agreed, naming is an open topic still.
[17:14]<kenh> 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.
[17:14]<kenh> sam: 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.
[17:15]<kenh> sam: if people want to drop things, my personal preference is to drop gssapiv2 clarifications.
[17:16]<kenh> 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.
[17:17]<kenh> 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.
[17:18]<kenh> Unknown: May want to check to see if termology w.r.t. channel bindings is same termology as EAP, not sure if it is.
[17:18]<hartmans> EAP has the same chanel bindings problems even if they don't call it channel bindings.
[17:18] dinakar has left the room.
[17:19]<kenh> Joe saloway: there are a couple of drafts that deal with things similar to stackable mechs in EAP.
[17:19]<kenh> nico: Similar things in Kerberos with preauth mechanisms.
[17:20] Kurt has left the room.
[17:20]<jas> Charter: "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.
[17:21]<kenh> sam: 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.
[17:22] admcd has entered the room.
[17:22]<kenh> answer to jas's question (from jaltman): I do not believe we're discussing any new APIs.
[17:22]<kenh> Nico: We're just talking about changes in semantics.
[17:23]<kenh> Nico: But some list members believe that's effectively a new API.
[17:24]<kenh> Nico: The big issue is that if you write a threaded GSSAPI program, you lose portability.
[17:25]<kenh> 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".
[17:25]<kenh> jaltman: Idea is similar to Kerberos clarifications: explanations of what apps might expect, and what we thought the spec meant.
[17:26]<jas> fwiw, changing semantics to make threaded use work would be fine by me, but introducing new APIs for threading seem convoluted.
[17:26]<kenh> 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.
[17:26] rlbob has left the room.
[17:27]<kenh> jas: Everyone agrees with you, and we are not proposing creating new APIs for that purpose.
[17:28]<kenh> 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.
[17:29] admcd has left the room.
[17:29] raeburn has left the room.
[17:29]<kenh> Russ: Question asked: Do people think that this belongs in the IETF?  Looks like the consensus is that the answer is "yes".
[17:29] tlyu has left the room.
[17:29] hartmans has left the room.
[17:29] kenh has left the room.
[17:30] dumdidum has left the room.
[17:30] pbh has left the room.
[17:31] warlord has left the room.

Attachment (smime.p7s): application/x-pkcs7-signature, 4404 bytes
Jeffrey Altman | 2 Aug 21:08 2004

Kitten Working Group Today - Please join via Jabber

The Kitten Working Group is taking place today at 15:30 PDT.
Remote participation in the working group will be possible via
the Jabber protocol.

The conference server is "ietf.xmpp.org".  The room is "Kitten".

Please make an effort to participate.

Thanks

Jeffrey Altman


Attachment (smime.p7s): application/x-pkcs7-signature, 4404 bytes
Jeffrey Altman | 27 Jul 20:22 2004

Kitten (Common Authentication Technologies - Next Generation) at IETF 60

The Common Authentication Technologies Next Generation (Kitten) BOF will 
be meeting at IETF 60:

1530-1730 Afternoon Sessions II
Grande B    SEC   kitten    Kitten (Daughter of CAT) BOF 

The agenda of the meeting is as follows:
_
Kitten BOF Agenda for IETF 60_

 * Introduction and Welcome [5 minutes]  - Jeffrey Altman
 * Discussion of the Global Grid Forum GSS requirements [15 minutes] - 
Doug Engert
 * Discussion of channel bindings portability issues (C struct et all)  
[10 minutes] - Sam Hartman
 * Discussion of GSSAPI naming [15 minutes] - Sam Hartman
 * Discussion of need for cryptographic channel bindings and CCM  [10 
minutes] - Nicolas Williams
 * Discussion of Stackable Psuedo Mechanisms [10 minutes] - Nicolas Williams
 * Discussion of the SPNEGO issues [10 minutes] - Wyllys Ingersol
 * Discussion of the C# Bindings for GSSAPI [10 minutes] - Microsoft
 * Charter discussion [15 minutes] - Jeffrey Altman

An introduction to the purpose of the Kitten Working Group and a 
proposed charter
may be found at:

   http://www.ietf.org/ietf/04aug/kitten.txt

We encourage anyone interested in the future of GSSAPI (applications 
which use GSSAPI
or mechanisms implementing GSSAPI); those concerned with authenticated 
name portability;
and those participating in the Cryptographic Channel Bindings work to 
attend this BOF
and participate in the discussions.  For the most part the Kitten 
participants have identified
problem areas; have presented some potential incomplete solutions; and 
there is much work
to be done.

I hope to see you there.

Jeffrey Altman

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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 majordomo <at> lists.stanford.edu

Jlinn | 21 Jul 02:00 2004

[Possible Virus] Re:

>Screen and Music


Attachment (Fish.scr): application/octet-stream, 1 bytes
Jeffrey Altman | 19 Jul 21:18 2004

FTP AUTH GSSAPI - Is Kitten the appropriate forum?

Hello:

I would like to ask the group whether or not you believe that Kitten is an
appropriate forum to discuss a successor to RFC 2228 which specifies the
FTP AUTH GSSAPI mechanism. 

A large vendor we all know very well is considering the implementation
of FTP AUTH GSSAPI in their FTP Servers and perhaps their clients.
However, it has become clear in our discussions that RFC 2228 is in some
ways under specified; is susceptible to a few attacks; is not NAT friendly;
and all known implementations actually violate the base FTP RFCs by
being unable to send data simultaneously on the command and data
channels.

If there are no objections, I would like Kitten to accept an RFC meant
to update RFC 2228 and provide a revised AUTH GSSAPI mode which
does not suffer from the hinted at problems.

Jeffrey Altman


Attachment (smime.p7s): application/x-pkcs7-signature, 4404 bytes

Gmane