+----------------------------------------------------+ Panda GateDefender has detected malicious content (Virus) in the following file: [Cat.cpl] W32/Bagle.AH.worm The file has been deleted to protect the network. 07/18/2005 08:05 +0100 www.pandasoftware.com +----------------------------------------------------+
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".]
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
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
 |
|
|
|
|
|
|
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 |
RSS Feed2 | |
|---|---|
2 | |
3 | |
10 | |
15 | |
1 | |
17 | |
46 | |
100 | |
1 | |
3 | |
1 | |
1 | |
1 | |
3 |
