73rd IETF - Kitten Working Group Minutes
========================================

Location: Minneapolis, Minnesota USA - Hilton Minneapolis Hotel
Time: 11/18/08 at 17:10-18:10 Local time

Co-Chairs:
Alexey Melnikov <alexey.melnikov@isdoecom>
Shawn Emery <shawn.emery@sun.com>

Scribe: Tom Yu <tlyu@MIT.EDU>

Security Area Director: Tim Polk <tim.polk@nist.gov>

Action Items:
=============

Co-chairs: PROTO write-up for draft-ietf-kitten-gssapi-extensions-iana
Co-chairs: PROTO write-up for draft-ietf-kitten-rfc2853bis

Leif Johansson: Send to list for discussion on naming extensions draft for the
following questions:
	Should we keep the mapping flag?
	Is there a need for a negative attribute?
	How we should register OIDs?	
Nico Williams: Resolve WGLC comments on draft-ietf-kitten-extended-mech-inquiry

WG: In regards to draft-zhu-negoex-01, resolve issues on list for 3961 endcoding
vs GSS_Get_MIC()/GSS_Pseudo_random().

Co-chairs: Send notice for WGLC on draft-ietf-kitten-gssapi-store-cred 12/1/08
Co-chairs: Send notice for WGLC on draft-ietf-kitten-gssapi-naming-exts on 2/1/09

Conference Session:
===================

Slides for this meeting can be found here:
http://www.ietf.org/proceedings/08nov/kitten.html

[gss-extensions-iana]
Needs cleanup of idnits before PROTO-writeup.

[channel-bindings]
ASN.1 nit sent to AD.
GenART-comment to clarify document and dicusss history, will be addressed by Nico
Nico: will handle updates for this draft soon.

[ext-mech-inq]
WGLC expires first wk dec.
Comment by Love; memory mgmt concern with respect to buffer and oid sets.
Co-Chairs will followup issue with Nico.
Please comment or at least acknowledge.

[naming-ext]
Leifj: missed deadline; apologies.
Leifj: details to mailing list shorly.
Leifj: all of things we were going to talk about we did last ietf.
Leifj: might be better if i just make sure things we brought up last time are
dealt with on the list.

[store-cred]
Shawn: have implementations? One.
Shawn: Nico, also has id-nits, so good reason to refresh.

[2853bis]
Shawn: person who brought up wglc comment said they would pursue with Sun.
Shawn: believe we have no blocking comments on that.
Shawn: will start PROTO-writeup for this now.

[deleg-policy]
Shawn: indiv. submission by Love Astrand.  New flag to honor policy (ok-as-delegate
in krb)
Shawn: not too controversial; anyone have issues?
Shawn: one issue - can distinguish old servers from the case when the ticket
doesn't have Ok-to-delegate flag.  In either case the client will still delegate.
Shawn: we'll talk about adopting it as WG item in a few minutes.

[gss negoex presentation]
Larry Zhu presents list issues on his individual submission of NegoEx:
draft-zhu-negoex-01

lzhu: primarily 2 categories of comment
<tlyu@jis.mit.edu> (1) encoding
<tlyu@jis.mit.edu> (2) how to do checksum?
<tlyu@jis.mit.edu> pros and cons
<tlyu@jis.mit.edu> asn.1 - complex but if you have library is easy
<tlyu@jis.mit.edu> tls - simple, but only if stuff you're encoding is simple
<tlyu@jis.mit.edu> currently using tls approach but little-endian
<Ken Raeburn> Why not build on something like XDR instead of rolling your own?
<tlyu@jis.mit.edu> cons (tls) - length needed in type names (cmt from mrex) ULONG
vs USHORT, etc.
<tlyu@jis.mit.edu> what about alignments, paddings? doc says don't assume
anything; if not specified, it's not there
<tlyu@jis.mit.edu> so no padding, no alignments
<tlyu@jis.mit.edu> someone sugg. XDR, which is similar to what we have but
slightly different in a few ways.
<tlyu@jis.mit.edu> already have impl so really don't want change unless completely
nec.
<tlyu@jis.mit.edu> leifj: pros and cons on slide? referring to what?
<tlyu@jis.mit.edu> lzhu: pros and cons of asn.1 vs tls style encoding
<tlyu@jis.mit.edu> leifj: curious why you chose to use another style in this case
<tlyu@jis.mit.edu> lzhu: have reason; cannot tell.
<nico> I don't care about the encoding, BUT
<nico> I do mind the "mechs must support RFC3961" part
<tlyu@jis.mit.edu> lzhu: what reason for me doesn't matter. protocols as simple as
negoex doesn't need much from encoding.
<nico> use GSS_Pseudo_random() to disassociate NegoEx from that requirement
<tlyu@jis.mit.edu> shawn: compat with spnego?
<tlyu@jis.mit.edu> lzhu: spnego uses asn.1.  backwards compat not a concern for
this (negoex)
<nico> OR
<Ken Raeburn> 3961 compatibility sounds like a really bad idea unless you're
constraining to krb5-related mechs
<nico> use GSS MIC tokens
<tlyu@jis.mit.edu> lzhu: how do we do checksums?
<tlyu@jis.mit.edu> lzhu: follows style of tls.  at end, checksum.  how do we
encode this checksum?
<tlyu@jis.mit.edu> 3961 as checksum scheme
<tlyu@jis.mit.edu> sam complained is unnecessary violation of abstraction
<nico> I really don't like GSS_Query_context_attr(NEGOEX_SESSION_KEYS)
<tlyu@jis.mit.edu> ken said 3961 too krb specific
<lha> if you say 3961 is bad, tell what is good instead
<nico> please don't do any of that stuff
<tlyu@jis.mit.edu> [use of rfc3961]
<nico> just use GSS_Get_MIC() or GSS_Pseudo_random()
<tlyu@jis.mit.edu> lzhu: pros - component reuse
<nico> GSS MIC tokens are an existing component too!
<nico> it's not that I don't like RFC3961!
<tlyu@jis.mit.edu> protocol already define extension fields.  ChecksumScheme field.
<nico> irrelevant
<tlyu@jis.mit.edu> do we really care whether 3961 is used or some other frmwk used
<nico> yes, we do care
<Ken Raeburn> Specify a particular subset of 3961 if necessary.  Probably better
to just specify the particular ops needed, directly
<tlyu@jis.mit.edu> sam: don't care about framework.  what i don't like is you
require a new things for all mechs. don't understand why you don't use getmic
<nico> what Sam said
<tlyu@jis.mit.edu> lzhu: unfortunately gss has number of problems.  designer of
negoex very concerned with efficiency
<tlyu@jis.mit.edu> using getmic will cause us lots of problems in other direction
<tlyu@jis.mit.edu> context nego inside process; switch process to do getmic/vfymic
<tlyu@jis.mit.edu> historical reasons why we feel is much better to 3961 instead
of getmic/vfymic
<nico> don't you have to establish a sec context?
<nico> if you don't, then where do you get keys from?
<tlyu@jis.mit.edu> sam: think is unacceptable to require new frob for your gss mech
<nico> if you do, then why not use GSS_Get_MIC()?
<tlyu@jis.mit.edu> requiring a new way to get a new key out of every gss mech is
not acceptable
<tlyu@jis.mit.edu> lzhu: prf? orthogonal...
<nico> the keying *is* an issue
<tlyu@jis.mit.edu> jhutz: if you and i don't do it the same way it won't interop
nico sighs
<tlyu@jis.mit.edu> sam: everything else in ietf assumes mic
<tlyu@jis.mit.edu> lzhu: meanwhile export this key; how you do checksum is
orthogonal
<tlyu@jis.mit.edu> sam: use gss for cksums, get better support for cksums.
<nico> q1: are sec contexts being established?
<nico> q2: if no, whence the keys?
<nico> q3: if you do, then how does GSS_Get_MIC() hurt????!
<tlyu@jis.mit.edu> lzhu: works similar to prot_ready. can get key before have
fully estab. context
<nico> GSS_Get_MIC() works with PROT_READY
<nico> even beyond that, why not use GSS_Pseudo_random()
<tlyu@jis.mit.edu> jhutz: seems to me that you could use PRF isn't good enough.
You need to present compelling reason why you don't use existing facility for
checksums.
<nico> instead of extracting keys
<tlyu@jis.mit.edu> lzhu: spnego specifically prohibits prot_ready
<Ken Raeburn> And "we already wrote the code" isn't a compelling reason...
<nico> SPNEGO need not be PROT_READY BUT the underlying mech can be and NegoEx can
use that
<tlyu@jis.mit.edu> leifj: exporting unfinished context for http?
<tlyu@jis.mit.edu> leifj: mrex had similar probs with that.  said "how can you do
this". sam said in some mechs you can export unfinished ctx and get key from it.
<tlyu@jis.mit.edu> jhutz: you're muddying the waters.
<nico> let's get to exported contexts *later*
<tlyu@jis.mit.edu> jhutz: who prohibits prot_ready in what?
<tlyu@jis.mit.edu> lzhu: 4178 spnego?
<nico> that's SPNEGO
<nico> not the underlying mech
<tlyu@jis.mit.edu> jhutz: spnego will never advertise prot_ready before ctx is
complete? or spnego prohibits underlying mech from doing prot_ready
<tlyu@jis.mit.edu> lzhu: prot_ready influences seq num
<lha> To avoid conflicts with the use of MIC tokens by SPNEGO, partially -
established contexts MUST NOT be used for per-message calls. To  guarantee this,
the prot_ready_state [RFC2743 [http://tools.ietf.org/html/rfc2743]] MUST be set
to false on return from GSS_Init_sec_context() and GSS_Accept_sec_context(),
even if the underlying mechanism returned true. rfc4178
<nico> yes you can the fact that SPNEGO can't export PROT_READY does not prevent
<nico> NegoEx from using the underlying mech's PROT_READYness
<tlyu@jis.mit.edu> sam: spnego says it uses mic tokens. would be problematic if it
adv prot_ready to its caller
<mrex> When SPNEGO is used PROT_READY is no longer to its callers
<tlyu@jis.mit.edu> jhutz: reason why spnego can't advertise prot_ready to its
caller is it uses underlying mech's mic
<lha> but that is true for NegoEx too, it also wants to use getmic()
<tlyu@jis.mit.edu> sam: can use prot_ready because we are in the nego
<tlyu@jis.mit.edu> sam: restriction in spnego on prot_ready to callers can be
relaxed.
<tlyu@jis.mit.edu> sam: can do prot_ready once it has consumed the token it needs
for its cksum.
<tlyu@jis.mit.edu> sam: more problematic for spnego to do prot_ready to its
caller, but not to use prot_ready of its underlying mech
<mrex> SPNEGO itself could use PROT_READY -- however, PROT_READY came a little
late into the game and is usually an implementation feature (if the protocol
supports it at all)
<nico> the underlying mech couldn't possibly know it's being called in SPNEGO
context, so if it can be PROT_READY, it will be
<lha> the question is that fits larrys requirement of not causing an extra
roundtrip
<nico> mrex: perhaps, but that's completely irrelevant here
<tlyu@jis.mit.edu> jhutz: not clear why this has effect on q that is being asked.
sounds like you're saying "we don't want to depend on underlying being prot_ready
so we will instead require underlying to give us new thing...."
<tlyu@jis.mit.edu> jhutz: any new frob you could be adding isn't going to be
available any sooner than when underlying is prot_ready anyway
<tlyu@jis.mit.edu> lzhu: trying to achieve same thing as prot_ready
<tlyu@jis.mit.edu> jhutz: what new indication do you need?
<tlyu@jis.mit.edu> lzhu: bunch of apis.  read draft.
<tlyu@jis.mit.edu> alexey: Mailing list.  Or get small group to discuss after
meeting.
<nico> there's no details on the API
<Ken Raeburn> I'd kind of prefer the list, but whatever.
<tlyu@jis.mit.edu> alexey: too early to adopt as wg item?
<tlyu@jis.mit.edu> alexey: targ std trk or info?
<mrex> PROT_READY is a very optional feature, and I think it is not even
negotiated in rfc1964/rfc4121
<nico> mrex: irrelevant
<tlyu@jis.mit.edu> lzhu: targ info. repeatedly requested by elsewhere that it be
std trk.
<nico> mrex: you can deal with optionality
<tlyu@jis.mit.edu> alexey: is there chance that ppl find your argument is wrong,
are you willing to change? or just documenting exiting?
<nico> mrex: and lack of negotiation of PROT_READY is not an issue
<tlyu@jis.mit.edu> lzhu: doc impl existing for interop etc. If we have to change,
we will change.  Will not change unless already necc.
<tlyu@jis.mit.edu> lzhu: cannot comment (whether shipped)
<mrex> the actual characteristic of PROT_READY is: message *protection* can be
applied before security context establishment, message *unprotection* can not be
used before security context establishment EVER
<tlyu@jis.mit.edu> shawn: looks like not an option at this point (as wg item)
<hartmans@jis.mit.edu/owl> I think we should only adopt as an working group item
s up change control
<nico> mrex: that's good enough here
<nico> hartmans: +1
<mrex> (which is why negotiation PROT_READY is unnecessary -- the receiver will
only process the messages with a fully established security context anyway -- but
it is a reason that an AP_REP subsession key can not be used)
<hartmans@jis.mit.edu/owl> Otherwise they should take it to the rfc-editor
ld flame them for not working with the community to develop significant new
to GSS.
<Ken Raeburn> Agree with Sam.  It sounds like a useful feature, but not without
fixes.
<jhutz@jis.mit.edu/owl> ==hartmans
<nico> mrex: the side with the next to last context token can start sending sooner
with prot_ready
<nico> mrex: if that side has to go first at the app layer, then prot_ready saves
you a full round-trip
<mrex> nico: which particular statement are you disagreeing with?
<nico> I was disagreeing with (which is why negotiation PROT_READY is unnecessary
-- the receiver will only process the messages with a fully established security
context anyway -- but it is a reason that an AP_REP subsession key can not be used)
<tlyu@jis.mit.edu> leifj: produce something with change of being std trk.
<mrex> PROT_READY can save you a round-trip, of course -- which is why it was
invented
<nico> you're saying prot_ready is not negotiable, sure not that prot_ready is not
needed

[http-gss]
Leif presents his draft to the WG: draft-johansson-http-gss-04

<tlyu@jis.mit.edu> shawn: leifj primarily looking for feedback.
<tlyu@jis.mit.edu> leifj: never been presented in kitten before. Update to 4559
(gss for http)
<tlyu@jis.mit.edu> leifj: attempts for sasl mech for http.  Ran into trouble. No
provision for dealing with proxies
<tlyu@jis.mit.edu> leifj: after seeing stuff like negoex come along.  Propose an
iana registry for binding auth mech (http)
<tlyu@jis.mit.edu> existing rfc4559 as special case. should be possible to send
in an entry for this registry that encompasses existing 4559.
<tlyu@jis.mit.edu> would like review.
<tlyu@jis.mit.edu> optional unique ch bind vs (existing) endpoint ch bnd
<nico> I will review
<semery> nico: thanks
<tlyu@jis.mit.edu> shawn: anything you need from us?  Exporting partial contexts?
<tlyu@jis.mit.edu> leifj: sticking pts of multi-roundtrip.  Concentrator... hit 2
physical server endpts on diff parts of rdtrip
<tlyu@jis.mit.edu> wouldn't be able to continue handshake in this case.
<nico> partial sec context export in this case is practically an implementation
detail
<tlyu@jis.mit.edu> one interp. of negoex stuff is a way to get around this problem
<mrex> I do not like the idea to export partial contexts at all!
<tlyu@jis.mit.edu> optional way to get around the problem in the http layer rather
than gss layer
<tlyu@jis.mit.edu> essentially cookie-like mechanism
<nico> mrex: there's no reason it can't be done
<tlyu@jis.mit.edu> one way to generate is export unfinished ctx.
<mrex> in theory there isn't, in pratice it creates all sorts of problems
<tlyu@jis.mit.edu> similar discussion at past ietf. nico, sam .. might be possible
in certain mechs.
<lha> nico: when you dont have control over the key material its not true
<tlyu@jis.mit.edu> not sure how big the problem is.
<nico> you can do it for RFC4121, but it makes little sense
<nico> PKU2U would be a more interesting mechanism to think about
<mrex> if establishment of a security context requires access to credentials that
are stored on hardware tokens, there is the problem of how to manage access to
that credentials if the different steps of context establishment are done in
different processes
<tlyu@jis.mit.edu> leifj: interesting to have those comments on the list
<nico> mrex: I think that can be handled like so: export the context with
references to the underlying tokens, put a timer on them
<mrex> it applies to the side using credentials on hardware tokens
<nico> when importing it, find those references or return an error
<nico> i.e., it needs to be possible for import of partially established exported
sec context token to fail
<lha> martin: but then you'll have the problem when doing load balacing with
non-gss-api based mechs too
<nico> you could just as well store session keys in tokens too
<nico> so technically you could have this problem for established sec contexts,
and I think the same solution would apply if you had that problem
<nico> if TLS can do this, so can we
<leifj> thx for the comments guys - I'm not sure how important
export-unfinished-context is actually
<mrex> established gssapi security contexts do not need access to credentials
(unless they're braindead SPKM implementations providing message integrity with
true digital signatures with the (longterm) credentials).
<nico> leifj: it's very important -- it allows the server to run with less state
<nico> mrex: yes, but you could put session keys in tokens (that's what I wrote in
relation to fully estab. contexts)
<leifj> nico: I understand but I'm wondering how likely that is to be a problem
in practice
<nico> leifj: TLS added session resumption without server-side state for a reason
<leifj> i.e in your typical clustered environment you will probably have a
shared-state mechanism
<nico> leifj: HOWEVER, this is an implementation detail
<leifj> yes
<nico> so we can make mrex happy by excluding all mention of partially established
sec context export
<nico> mrex: in fact, mechglue could emulate partially-established sec context
import/export as I described above for mechs that don't support it
<nico> mrex: yes, it defeats the point, but for most cases it won't

[charter items]
<tlyu@jis.mit.edu> shawn: deleg-policy appears noncontroversial; would require
recharter
<tlyu@jis.mit.edu> tim: no strong feeling either way.  Willing to follow wg
consensus
<tlyu@jis.mit.edu> alexey: do you prefer indiv submission, or wg doc?
<tlyu@jis.mit.edu> tim: turns out to be same amt time; 2 week ietf lc vs 4 week
ietf lc
<tlyu@jis.mit.edu> tim: always feel better if wg consensus behind doc.
<tlyu@jis.mit.edu> sam: not in their charter
<tlyu@jis.mit.edu> jhutz: if answer is yes, "hey tim we'd like to recharter"
<tlyu@jis.mit.edu> tim: yeah so extra 2 wks.
<tlyu@jis.mit.edu> tim: ietf lc gets announced on this list as well.
<tlyu@jis.mit.edu> tim: just go ahead and fwd as AD-sponsored.  One of you will
give me a proto writeup. Doesn't get you out of any work except charter revision.
<tlyu@jis.mit.edu> tim: if we were farther from doing wglc then would say ok pick
them up as wg item and wouldn't reduce time frame.

[review milestones]
<tlyu@jis.mit.edu> shawn: store-cred stable, a few idnits.
<tlyu@jis.mit.edu> shawn: name extens. up to leifj.  not sure if we can get all
items taken care of. dec. too aggressive?
<tlyu@jis.mit.edu> leifj: needs more time.  Unresolved issues from last ietf.  feb.
<tlyu@jis.mit.edu> shawn: 3 min for open mic.  No one steps up to mic.
<tlyu@jis.mit.edu> shawn: meeting over

================

Session Over