Subject: Proposed Minutes of IETF62 - Please review

From: Jeffrey Altman <[email-masked]>
Date: Fri, 08 Apr 2005 00:54:19 -0400

Thanks to Jeff, Nico, and Love for taking notes and scribing.
These minutes are really rough but then again the open discussion
went so fast that with recordings it was impossible to keep up.

Jeffrey Altman

IETF62 Minutes for Kitten Working Group
=======================================
Wednesday, March 9 2005 1:00-3:00 Central Standard Time.
Chairperson:  Jeffrey Altman

Thanks to Jeffrey Hutzelman and Nico Williams for Jabber Scribing
Thanks to Love Hörnquist Åstrand for taking notes.

agenda bashing:
        no comments

Larry Zhu updates on SPNEGO:
 - sent to IESG, Last Call ends March 22.
  
 - implementations include Longhorn beta 1, Heimdal, and a 
   future update to solaris 10

 - there is no open issues; please read draft

 - no questions

 - first document from kitten, beats the milestone.
 
 - a big thanks to Larry

Nico Williams update on several documents:

 - PRF extentions 
   * edits from last meeting folded into -01
   * PRF_READY added in -02
   * ready for last call (draft-ietf-kitten-gssapi-prf-02.txt)

 - Kerberos side of PRF, same comments
   * edits from last meeting folded into -01
   * No PRF_READY
   * don't use PROT_READY
   * can call PRF as soon as you want. if the PRF isn't ready,
     the function will return gss_not_avaible.
   * ready for last call (draft-ietf-kitten-krb5-gssapi-prf-02.txt)
	
 - GSS Domain based names
   * folded in edits from last meeting
   * Seems to be ready for last call, less review then the PRF
     documents. should wait if there are some comments.

 - Kerberos domain names
   * folded in edits from last meeting
   * realm derivation changed - realm is derived from the domain
     part of the domain-based name, not the host part
   * Seems to be ready for last call, less review then the PRF
     documents. should wait if there are some comments.

 - Stackable pseudeo mech and extended mech inquiry APIs
   * originally a single documetn individual submission
       draft-williams-gssapi-stackable-pseudo-mechs-00.txt
     now split into to two:
       draft-ietf-kitten-extended-mech-inquiry-00.txt
       draft-ietf-kitten-stackable-pseudo-mechs-00.txt
   * Both drafts needs review. Esp with the some issues from the
     document split.
   * Stackable mechs very simple concept.	

 - Guide to the GSS-APIv3
   * Not many changes; just naming draft.

 - IANA registry draft
   * currently only has text about what submissions look like. 
     no rules, no initial content.
   * talked to IANA - they would like to see a section with allocation rules,
     and an appendix with initial content.
   * overloading all the information into a single registry may or may not 
     be the right way to do it; I don't know.
   * like to get some feedback on document
   * Nico will work with the chair to work out IANA details

 - Channel bindings draft from NFSv4 WG
   * for ipsec, we still need to decide what channel bindings are going to be.
     draft in kitten tells you.  this needs some review.
   * draft not ready for last call
   * lots of discussion about where the definition of protocol specific 
     bindings belong
     + hartmans: defining protocol specific channel bindings not in the 
                 charter for Kitten or BTNS; and Russ has objected.
                 IPSec is not accepting new work.
                 I think it should be done as ain individual submission.
       nico: OK, but not what we discussed before.

 - Comments for Nico:
   * channel bindings
     + Love: how can a protocol running on top of gss do channel
	     bindings to gss?
     + Nico reply: its there in the NFSv4 draft, but could be done better.
   * IANA
     + hartmans: uneasy about having to register every gss_ symbol with iana
     + Chair: this topic needs to go to list, not enough people have read 
              the draft
     + Matt Peterson: what was IANA's response to being asked to do
                      api registry
     + Nico: IANA doesn't care about what being registered, then just want
             to be told how to do it.
     + Chair: The question is "what do we want to have done by standards 
              actions?"
              One benefit of registries is having a place people can look
     + Nico: part of this discussion is to allow for vendor-specific extensions

Sam Hartman updates GSS Naming:
 - draft-ietf-kitten-gss-naming-01.txt
 - the goal is to be a direction statement to describe the problems we're trying
   to solve, and approaches we're considering
 - received a lot of comments from nico
 - hoping to get comments from Martin Rex, but so far he has never actually
   responded directly to this draft
 - I think -02 will be ready for last call.  There is one issue I'd like to get some
   discussion on today.
   * currrently today, names are atoms - indivisible strings with no structure
   * one proposal is to turn them into sets and/or sequences
     + <missed discussion>
     + nico & I think we'll probably need to do that anyway
   * another proposal... allow us to choose the initiator name based on
     what target we're talking to.  can't currently do that.  there is some desire
     in kerberos to be able to do that
   * another issue that came up, which we have no closure on yet...
     + mechanisms that can assert multiple identities
     + example - X.509 mech, you may have multiple subjectAltName
       you may want to say which of these names you want to claim for a given 
       context for pure (GSSAPI) v3 mechanisms being used by V3 apps (understand
       composite names), you probably don't need it do we want something like this 
       for v2 applications
     + I believe if we can solve that issue, we can last call -02
     + nico: how to do that is easy. whether we want to do that is another story
             I believe spkm had a thing where you could assert a Name in its tokens
             from a v3 POV, that's irrelevant
     + unless someone comes forward and says they want to do that,
       we're not going to.  If you care, you need to speak up by end of WGLC.
     + nico: your draft is informational...
     + at this time, it doesn't make sense for me to be editor of a document...
       maybe if my day job had less management work...
       do we want to poll the room, see people interested in being doc editors?
       Nico would do a good job, but have lots of docs on your plate
     + jaltman: I as chair would be more comfortable with load spread out.
     + matt peterson volunteering someone from his organization
     + jaltman: no other volunteers

Update java and C# bindings
 - neither of the authors were able to come to this ietf
 - two new documents:
   * draft-ietf-kitten-gssapi-rfc2853-update-for-csharp-00.txt
   * draft-ietf-kitten-rfc2853bis-00.txt
 - c# - submitted from novell, new editor
   * describes how to morph 2853 java bindings for c#
   * very little discussion of this doc.  novell is in the process of implementing;
     if others are interested, we'd love to hear your opinions
 - second doc (RFC2853bis) describes what things in RFC2853 were
   implemented differently in the Java Class Libraries from what's in the spec.
 - the document is in good shape.
 - next step is to merge the two drafts.
 - nico: do you have an editor for that?
 - yes; one from Sun (Seema Malkani), one from Novell (Juan Carlos Luciani)
 - hartmans: a little concerned about style/format of these docs
             I don't think IETF spec by diff works
 - the next step is to merge these and rfc2853 into a new doc that would obsolete 
   the old one

Open mike: 
[Editor's note - This discussion did not belong in Kitten]
[The contents of this section are stolen from the Jabber logs]

joe salowey: 

the topics that have been coming up lately.
ISM WG, enhancements to EAP, EAP has been held to be not applicable
we're looking to see if the GSS-API is applicable
this is a heads up about interest in this
also I'm looking at a number of IETF auth frameworks (SASL, GSS, EAP...), 
at some point we should look at merging these things
some of the GSS v3 enhancements could help (PRF, Naming, ...)

sam hartman:
so we seem to have some time left
joe brought up some interesting points
this is very much half-baked, joe's the primary instigator
we have a miserable situation in the IETF w/ sec mechs
(long list of technologies)
and one-off mechs too
you know, hash stuff
and SSH!
and so there's a kind of matrix: if I pick this protocol, what auth techs can 
I use some are very limited (HTTP has ...) blah, blah
and really, the way I want the matrix to look is: regardless of what protocol 
I pick I can use any mech I want
because if I do that I only have to get security right once
in my organization
so, to get folks thinking about this
all these mechs do roughly the same thing
you're stopped by small problems of standardization and programming
we can do the standardization here
so I'm going to compare everything to GSS cause we're here now
EAP is like GSS but the server send first token
no wrap/unwrap
the mechs folks use today have a "key fallout"
two keys, actually
EAP has a better developed sense of ....
naming/channel binding
their concept of channel binding may map onto our concept of naming
their client ID is weaker than our names but more useful
there are stackable pseudo-mechs for EAP
and when you do that you need channel bindings between layers
they call that cryptographic binding
they have a description language for the sec properties of their mechs
SASL is like GSS but lacks the PRF, its concept of naming is not as well 
developed, except when doing GSS
it has this funky thing called an authorization ID
SASL supports either the client or server as initiators of the exchange
this depends on the protocol and the mechanism
I think this is even as bad as implementation dependent
GSS is a lot like GSS
(laughter)
For EAP the negotiation model is that the server decides what mech to use
for SASL the client generally picks from a list offered by the server w/o 
downgrade attack ("bidding down")
you can abort in the middle of auth
for GSS we have SPENGO
SPNEGO if you don't know how it works, now's the time to find out!
SSH I like
the client and server shout at each other offers
the client picks one and the server rejects or the key exchange fails the 
client loses
the key exchange ends in two things: a key and an exchange hash
and ssh authenticates the server to the client
this protocol doesn't have a good concept of naming
pubkeys are not named
then there's the ssh user authentication protocol
this has something like the SASL authz IDthe client tries one mech
then the server tells whether we can do this or are done or how to continue
the client needs to know what it's tried so it doesn't try again

Jeffrey Hutzelman:
this is all implementation dependent
the client has to keep trying until it can't go on or succeeds

Sam:
TLS supports pubkey certs, PSK
and it supports Kerberos, sortof (details)
are there any other actual authentication frameworks in IETF...?
MIKEY has some authentication goop

Uri Blumenthal:
MIKEY is good, but it's multicast specific
it's auth deals in multicast key distribution -- Kerberos, EAP, etc... 
wouldn't be aplicable

[details lost]

Sam: 
consider using certs to get access to the multicast stream
and consider that MMUSIC uses MIKEY to configure unicast streams
if I was an admin I'd be annoyed if MIKEY didn't support the mechanism I wanted

[details lost]

Sam: 
I want to be able to use any mechanism in any app

Jeffrey Hutzelman: 
so you want developers to be able to pick the most applicable framework for 
their protocol, but be able to use any mech

Sam: 
exactly

jhutz: 
so mech gateways

Sam: 
that's one way
I want a solution, but I'm not particularly interested in any one of them

Joe: 
I'd rather see these mechs (new mechs) developed together for all frameworks 
rather than rely on 'gateways'
...

Sam: 
long term I'd like to live in a world where ppl know about gateways and new 
mechs will work through them all
but basically I agree with you that if the gateways are not easily workable, 
then it might not fly
so my assumption is that we can get the gateways to get to the point where 
they'll meet most folks' needs
and then look at mechs-all-at-once

Joe: 
it would be more efficient to design the mechs with these different frameworks 
in mind

Mark: 
I don't necessarily want to know what mechs I'll be using, I need to know what 
capabilities I need and what caps each mech offers
nico's draft may be a start point
it goes a bit deeper than that
we need to be able to plug-in mechs
the framework implementations have to be pluggable
I'm wondering if the WG can do anything about this
and refining the semantics of the default mech (GSS_C_NULL_OID)

Sam and Mark argue about sysadmin vs. app policy

Sam:
I think this is moving into a different topic
I'm happy to do that, but...

Chair: 
Joe, any more questions?

Joe: 
I'd like to explore the idea of developing mechs in parallel.

Sam:
want to be able to reuse as much of the mech spec and implementation as possible
don't want to have case statements in spec

Uri:
it would be good if mechs would just perform a few extra tasks
export identities, exact crypto protections it uses, key material
this is why people are looking at eap

Sam:
we think we have the generic keying material in the GSS PRF
we'd like your review

Uri: 
already sent some comments

Nico:
quick response to uri
for some mechs, we won't know in advance what it uses.
e.g. kerberos
for others, we know up front what it will use
current gssapi qop concept is badly broken

Uri: 
in some protocols, access control is based on identity, accessed object,
and under what sort of protection

Nico: 
wow, this is an interesting meeting!

Chair:
what I was hearing is there's a desire to define a base set of
operations on which things can be built
is that right? if so, where?  not in kitten's charter

Bob Morgan: 
another distinguishing factor is integration model
one of sasl's successes is it makes it clear how to integrate into app proto
gssapi - not sure what integration model is

Sam:
gss is clearly a lot of rope
all of these frameworks meet different app domains
it's interesting that the mechs are very similar, even though the frameworks
are very different

Bob Morgan: 
maybe different frameworks come from different needed integration models

Sam:
if you want an easy integration model, use sasl
if you understand your needs really well and have complex requirements, use gss

Nico: 
matt, the default mech/mech set don't have to be global config file as in Solaris
the right default is "whatever mechs you have credentials for"
the right default mech is "the first one for which you have credentials"

Matt Peterson: 
what if you have creds for more than one mech

Nico: 
either it's nondeterministic or its the first one
I know you want this to be app-specific config, but I don't feel
not sympathetic - you can make app provide the right oid

Matt: ...

Nico: 
what I hear you saying is you want pluggable mechanisms
we can't tell people to do that.  there are monolithic and pluggable multi-mech implementations, and ther eare single-mech implementations

Chair:
do you have specific platforms in mind?

Matt: 
for example, aix or some mobile thing, where I want to port my app

Chair: 
you're always going to have something older that doesn't have the functionality

Milestones (Chair):
 - we're not making the milestone on GSS-API _v2_ clarifications
   * hartmans: as an individual, it's not clear we want to do v2 clarifications
   * is it worth reviewing and clarifying GSS-APIv2 update 1
   * wyllys: It  seems like an extra step and maybe not necessary.
   * jhutz: are you asking if GSS-APIv2 update 2 is worth doing?
   * no, the clarifications would be for inclusion into the v3 document
   * wyllys: oh, thats a little different.
   * all the various little issues that we talked about on the list
   * we need someone to volunteer to go through the CAT and KRB mailing 
     lists and collect all of the details from the discussions which lead
     to the formation of this working group
   * Matt Peterson will assign one of Vintela's people to go over the 
     archive and compile the complaints.
   * Update this milestone to May 2005.
 - No need to revise the other milestones since we are making
   good progress.

Done.

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten