Minutes for KITTEN at interim-2013-kitten-1
minutes-interim-2013-kitten-1-1

Interim Meeting - kitten Working Group Minutes
==============================================

Location:       WebEX:
https://ietf.webex.com/ietf/j.php?ED=179545787&UID=1381218722&PW=NYTQ2YTA5MjY4&RT=MiM0
                Audio Conference: 1-650-479-3208 Access code:640 049 742
Time:           Monday, 6 May 2013, 08:00 - 10:00 PDT

Co-Chairs:
Sam Hartman <hartmans-ietf@mit.edu> (attended)
Shawn Emery <shawn.emery@oracle.com> (attended)
Josh Howlett <josh.howlett@ja.net>

Secretary:
Simon Josefsson <simon@josefsson.org>

Security Area Director:
Stephen Farrell <stephen.farrell@cs.tcd.ie>

Scribes:
Ben Kaduk <kaduk@mit.edu>

Audio Recording: TBD

Attendees
---------
Ben Kaduk
Scott Cantor
Klass Wierenga
Nico Williams
Greg Hudson
Tom Yu
Jim Schaad
Zhanna Tsikov

Action Items
============

Chairs: Poll WG of following items:

1. In regards to draft-ietf-kitten-sasl-oauth, RFC 6616, and RFC 6595; do we
allow for GS2 mechanisms that don't provide mutual authentication?  This would
entail changing the GS2 specification (RFC 5801) to relax this constraint.

2. Do we allow the IAKERB draft (draft-ietf-kitten-iakerb) to pull in the
finished message text from the PKU2U draft (draft-zhu-pku2u)?  Subsequently, if
the PKU2U draft is progressed, it will make a normative reference to the IAKERB
draft.

3. In regards to draft-williams-kitten-channel-bound-flag; are you in favor of
using the NULL context solution for the channel bound indicator as opposed to a
new set credential API?

Conference Session
==================

Mutual Authention SASL Mechanisms
---------------------------------

Shawn Emery: Thanks for joining.
first thing is mutal auth/sasl that Jeff Hutzleman and nico brought up
main goal here is to find out how to proceed; the three mechs
openid, saml, and oauth break the GS2 requirement of having mutual
authentication.  The current text in the oauth draft/openid+saml rfcs is
hand-waving that mutual auth is done outside the mech via, e.g., tls, but then
it returns it, which contradicts the GS2 text that "mutual authentication is
required for the mechanism".
There's a couple of solutions; one is to change the GS2 spec to not require
mutual auth; another is to remove the GS2 feature for the sasl mechanisms
by updating the oath mech draft, openid and saml sasl mech rfcs.
Sam Hartman: specify as pure sasl mechanisms, without ???
Nico Williams: in particular drop the dash-plus
sam: if you keep as GSS mechanisms, the dash-plus comes via GS2 unless
we update GS2 so that sometimes it doesn' t have the dash-plus
nico: how do we do that?
sam: if you don't want to update GS2, you have to...
nico: we're going to ahve to because we want mechs without mutual
sam: no consensus
nico: I'm asserting that we do
sam: you probably favor option 1, update gs2, as opposed to option 2
nico: oh, I mixed up what we're discussing
sam: could say, big mistake for gs2 mechs to try and reuse technology;
we're going to decouple these and go fix them later
???: sam, how is this different from just taking all the gss stuff
out of ...
sam: that's what it is
shawn: another option that might be interesting is to bring back stackable
pseudomechanisms, and then have a composite mechanism akin to ...
openid or oauth mechanism.  Have that be a requirement for mechanims,
stacking TLS and the underlying auth mech.
sam: you don't want to do that.
the reason I'm pretty sure you don't want to do that is that one of the
desires behind the oauth and saml mechs is to make them easy for sasl
apps to implement without knowledge of gss, ... with a minimal amount of code.
Changing the requirements so that you can't use a stock tls library as you
normally would would require a lot of code.
nico: agree it's not likely to happen; not worth bothering given that.
Scott Cantor: the requirement for mutual auth is directly related to channel
binding stuff in GS2, is that right?
[yes]
sam: I'd like to understnad that better.
To decide, want to know (1) what applications want to use these mechs
as gss mechs? (2) why does GS2 have these requirements
nico: easier to start with (2).
We have new mech, browser-id based one, which is public-key based.
You can do channel binding without mutual auth, and it means something,
more than for other mechs like oauth, and yet it's still a little squisy.
There is a reason we want mutual and channel binding at the same time.
Are we discussing this later or now?
cantor: my mech does not mandate mutual (but supports), but it's designed
to plug into gs2, so I may need to update language depending on what happens
here today.
sam: saml-ec
I can't come to a conclusion on 1vs2 (drop vs update).
If there are other questions people have, we can add to the list, but we
need to discuss questinos soon.
In my mind, "why does gs2 have this requirement" sounds like a good first one.
shawn: have mech author online, ask him?  Was there demand
sam: don't want to go that way
Do we think, from a gs2 standpoint, that we will see this in the future.
???: do want to say, when started out, had not thought about test mechanisms;
I brought it to kitten, a suggestion was made, and it made sense.
Don't see any demand yet, but could be in the future.
cantor: gss isn't even a question, as ssh is key target (not sasl)
nico: okay, thta was useful
sam: nico, you have most knowledge of gs2.  Can you discuss why we need...
nico: when we wrote rfc5256 on channel binding, had only nebulous idea of
what original authors wanted, and so did the original authors in 2743.
When Sam and I worked on this, we saw that in order to do CB, the whole
purpose was to eliminate MITM; we needed some properties to decide that
we had succeeded.  Someone has to check CBs same on both sides, and the
other side has to believe that it has happened.  There's a sidebar here
for whether the initiator needs any confirmatino that the acceptor has
[done so?].  If we do mutual, and mech can confirm that CB is same or
different on both ends, then mutual is sufficient.  GS2 threw out some
of the complexity of GS1 by using CB; provide integ protection via GS2
header and channel binding, if the mech supports, is great, but didn't
think about at the time.  If we had thought about it, might have done
mixed token like GS1, and that would probably have failed.  So we're stuck
with only CB as a way to provide integrity protection for the stuf fon top.
sam: want to know, who cares about integ protection.
Working through... we send bits from client to server; information about
whether CB was used, and info about authorization identity.  That's all
that is sent with integ protection [nico confirms]
shawn: there are extensions
nico: we made it extensible, but didn't provide extensions.
sam: apology to all for taking so long, want to make sure understanding
correctly.
???: point out: no integ from gs2 itself; presumption that no cb and you're
sunk or cb and will check later
sam: one problem with gs2 discovered in this discussion, is that gs2 always
assumes that all mehs support cb, and provides integ protection for cb.
This is false, and gs2 has a problem, quite serious, if used with a gss
mech that doesn't do cb.
cantor: emergent property of mech, not built into gs2 itself.
sam: gs2 has a different idea of how gssapi works than reality.
to be secure, gs2 should only be used with mechs that provide integ protection
of their channel bindings.
shawn: what if integ done not for target mech, but that cb can be verified?
sam: I don't understand.
shawn: right now, if TLS has been used, then that is used to provide
the integrity checking as opposed to the mech itself.
sam: wrong because of cut/paste attacks.  Maybe.
Actually,we hadn't considered that.
nico: means that application has to use tls, too.  Feature of mech that
must be advertised to application developers.
[example of how application developer thinks]
end up in situation where not needing to care about CB.
sam: not sure...
nico: end up always using TLS, widest possible trust anchors, so that will
always interoperate.  That means possible MITM.  The only way to interop, but
then you're scurewed.
tlyu: in practice, non-web apps using TLS, how to verify server cert?
cantor: lucky if do it at all; builtins of platform libraries.
wouldn't rathole on this issue.
That it breaks the gss abstraction makes it an edge case or rule it out entirely
nico: the lack of security in webserver pki is a motivating afctor for CB.
If it turns out that we can't live without tls, and we can't do anything
about improving the security of that pki, then we wrap it up and go home.
we say we screwed up.
sam: gs2 requires tls.
nico: but not the pki.
cantor: my mech letes me federate the server pki.
sam: still trying to understand question.
HAve information, authorization identity and cb flag.  Server cares about that,
because the server wants to make sure that the CB flag hasn't been cleared
by an attacker, and the server cares that the authz identity is the same
that the client sends.
nico: oh.
Can we backtrack and discuss authz id and then CB flag?
sam: only if better understand security reqs.
nico: if we knew whether the initiator tried to use CB but the attacker cleared
the flag, then we don't care, because we know that the initiator tried to
use CB.
Sam: didn't parse.
nico: gss acceptor received token, also GS2 app.  Do not see CB flag in the
gs2 header.  If, inside token, there was CB information, and mech could tell
us (instead of ignoring it) [sam: never pass null CB for gs2] then we fail.
[sam: that's how we detect failure today; we fail there]
cantor: problem is, if clear flag, and server treats that as indicating to
not check, then this falls apart if don't use plus version of mechniasm.
Posit a secneario where CB is not required, then attacker can MITM and
clear it.
nico: problem we had was this: we needed a particular case, we need to not
even try CB on the client.  We know a priori that this mech can't do what
we awnt; we're not relying on it.  We need to actually know to rely on the
tls server pki.  We need to know that we don't get to do dash-plus with
this mech.  a priori, we need ot know that a mech like, say, oauth, can't
do dash-plus.  That's roughly the soultion I was looking for.
cantor: what are you expecting outcome of security negotiation to be.
Can certainly use such mechs with gs2, if you understand that there's a whole
set of guarantees that you won't have.  I wouldn't have thout=ght that was news.
nico: it is news...going back to sasl applicaiton developer
cantor: my presumtipon is that people deploying such applications that do
understand security impliciations but just don't care.
Is the concern that something is reported to init or acceptor that is
inaccurate, or is the issue that what's reported is right, just some poeple
don't like answer.
nico: no, what I want is, I'm looking at how to use sasl framework, an actual
api that exists now, and I want to know that I am giving security to the
user that asked for it.
If I pick oauth mech with bad trust anchors, then I lose.
cantor: your version of "lose" is what vendors are pushing as next generation
of security
nico: if I can have mitm that goes undetected, then I lose.  I don't see any...
cantor: I agree with you, but that's not consistent with the rest of the world.
What's the issue with gs2 -- if it's that things are accurately reported but
that the security guarantees are not particularly strong...
nico: I'm not saying you don't get to use oauth; I want either app to know
upfront with sasl which mechs to use if the user cares about mitm avoidance,
or alternately, when it's done, have a boolean to indicate whether there
might be a mitm.  The latter has the problem that the user can't ever get
it to use a mech for which the user has credentials, that might work better.
I'm putting this in APIs ... sasl has no guarantee for these kind of demands.
GSS has them, SASL does not.  The diea with dash-plus was to provide this
sort of guarantee.  If we take it out, and the user can see what could have
been used, then they can see what could have been.  But most people won't
care.  So I want the first thing.
cantor: just trying to udnerstand actual functionally broken parts of the rfcs.
Don't want to just make a avlue judgement.
We coudl say we would rather not have had these things as wg mechs post facto.
I'm not seeing yet a statement that gs2 is misreporting.
nico: it absolutely is.  It's the dash-plus
cantor: gs2 can claim that cb was done when it wasn't?
nico: gs2 can claim that cb was possible when it wasn't.
nothing can confirm that something was wrong.
what went wrong is the ability to have a mitm.  That's it for me, I'm done
with that.
cantor: isn't that a property of any mech that doesn't to cb and mutual?
nico: no, I want to know a priori whether this is something I ahve to worry
about, and then deal with it by, e.g., dash-plus.
But if dash-plus is a bad idea, we need an api somewhere that tells us
what the mechanism really does, or indicate what actually happened.
But with the caveate that we might always fail.
cantor: really the gap is there isn't a way to report (particularly to
initiator) what actually happened.
nico: yes.  But I could go either way on this one.  Want user to be able
to succeed when it's possible.  If we keep putting up warnings, the user
is going to click through.  We want to avoid that.
cantor: deployment issue?
nico: no.  We might want to scale to the size of the web.  How can we know?
deployment is on the client side problem.  Client might want to operate
against some sites where do/don't care about mitm.  Would have to manually
adjust set of mechs usable for various connections.
gets back to the first option that I gave.  So I think we need both.
Again, this is all at the API elvel for sasl, not the protocol.
Whatever we do here, the spec for sasl or for gs2, that it's going to upset
the sasl purists.  And I'm okay with that.
shawn: from the gssapi standpoint, what would mutual auth really mean at that
point?
nico: we didn't finish taht discussion, we went to something else.
[on direction to take discussion]
cantor: core discussion is "is gs2 broken"
sam: if you're trying for a consensus call, you're driving me against the
discussion; I'm against consus about anything for this topic.
the questino of "what are the security requrimenets" is really important to
me, but we're off so far into solution space that I can't follow what is being
said well enough to even have an opinion.
nico: not trying to discuss solutions, but rather what properties I want for
the user.
sam: I don't even understand the securty properties of what we have today.
nico: what we want is more important than what we have, though
cantor: will be difficult to achieve consensus about security properties
at that level of detail.
nico: the internet threat model assumes active attackers
tlyu: in practice people ignore parts of the internet threat model
nico: what is the threat model here?
how can we have a discussion about anything without nowing what we want
for security properties of the whole thing?  I don't care about gss or gs2,
I care about what we get at the end of the day.
cantor: sliding set of requirements; important nis to report accurately
to applications so that people can make choices and write code.
don't think there will be an agreed baseline for securiyt properties
nico: if we can't care about secure interop, then I don't think we can even
have this discssion.  I'll throw in the towel; we can document gs2's lack
of security, but that's all I want to do know.
If someone else has a better suggestion, that's fine, I'd love to hear it.
shawn: I'm trying to tie in your proposal for qualificaiton of what mutual
authentication entails.
nico: we're getting into details...how can we achieve a different result by
starting discussino from botton up instead of top down.  At the end of the
day, it's what we get out.
cantor: we have people writing mechs, writing specs.  We can't force those
opinions onto everyone else.
sam: interrupt with process issue.  Shawn, s 6.5.2 rfc 2026 file appeal
about process being used to move forward in that meeting.  A point where
two participants have said that they are throwing in towl and walking away
at some point.  SEveral people have critical opinions who aren't here.
I don't know what the right answer is, but this process in this meeting
right now isn't moving forward, and even if it did, I don't think any
consensus would be good.  We wouldn't have confidence in it.
nico: reschedule with more people?
sam: we tried to schedule.  I don't know what to do here; we don't need
to walk away frmo this meeting ... the current discussion.
We both feel that the issues important to us aren't being addressed, and
something needs to change about the process to move forward.
nico: how does that appeal get addressed.  Can we reach consensus of no
consensus.
sam: you were talking about something else; I withdraw my statement.
you threw in towel on issue, not process.
nico: could confirm on list we failed to get consensus on actual technical
isssues.  We cannot reach consensus for entire wg today because missing
participants.  Might be others, lurkers, who have other opininosn, who
might help on mailing list.  I'm not trying to hijack the process into
saying were done, we have no consensus.  Am saying we have a conflict that
we don't know how to resolve.  Without resolustion to that conflict, we
cannot find consensus.  Leave someone in the rough, or everyone comes around
sam: to me, I'm not even convinced that conflict is important to how I
would decide on the technial issues.
nico: new opinion, please explain.
sam: we are thinking about the problem in entirely different ways, and I'm
being left out of the discussion.  I want to start from where we are today
and I can't wrap my mind around starting from where we want to be and
workin back.  I haven't even gotten to a point where we need to understand
the issue.
nico: I have a problem going the other way around.  To me it's clear
that we want a systemic  property of some sort.  You don't want to discuss
it that way at all
sam: Do at some point want to look at systemtic stuff, but also we have
an existing system to day and I'd like to understand it as an incremental thing.
Not sure that all applications are going to have the same systemic problems.
For exmaple, there are sasl mechanisms today that don't fit into this model.
sasl plain is a well-defined mech.
nico: doesn't have a dash-plus.
dash-plus was supposed to give us a systemic property that we want, that
the user would say "I don't want a non-dash-plus"
sam: you want a systemic property from dash-plus.
If there's a dash-plus mech, then you don't need to
nico :depend on the server pki
sam: is scott disagreeing with you about that?
cantor: no.  I'm just trying to understand where we are, so that we can
understand what to change.
nico: what does dash-plus mean.  Chris Newman's suggestion; he's not on the
call.
sam: what is disagreement betweeni scott and nico?
nico: maybe isn't one and we are confused
cantor: reacting to staemente "if possible for dash-plus and not to exist
in the world, then we can unilaterally decree that no one uses non"
nico: want user to knwo what level of security they got
cantor: is there a limitation with the spec that prevents that from happening?
(not applications)
nico: there are mechs that don't verify CB
cantor: that's my earlier point; people have decided that those mechs have
value; we can't pull them
sam: scott, your question is hard. Nico and I will give you two completely
different answers to this.
My answer is, there's a spec bug.  GS2 is missing today a paragraph that it
intended to have, "only use this mech with mechs that actually do CB integrity"
if you have that paragraph, you get that today.  With that pp, it's quite clear
that we mispublished the existing rfcs.  Another answer I could give you is
that there's al imitation in the spec, that basically that you have dash-plus
mechs that don't verify cb integrity, and that makes it very difficult for the
application to understnad what it's getting.
There are multiple ways to interpret the facts, to see what problems exist
today.
cantor: example?
sam: oauth, simple samle, openid.
cantor: they don't try to verify cb.  How could they be dash-plus?
sam: gs2 does not allow you to have a non-dash-plus mechanism.
The question of do you advertise dash-pluus is a factor fo does the
*application* udnerstand CB, not the mech.
nico: server side ... ...
sam: pelase undestand problem before jumping to solutions, I can't handle
much yet.
cantor: so we're saying that
 gs2 framework presumes that any mech that foloows the framework
is inherently providing both the non-cb and the plus-cb variant and that
they both do the right thing.  IF a plus is chosne, you actually get cb.
nico: better to say that gs2 assumes that gss mechs provide cb.
cantor: trynig to write a mech, you don't think in those terms.
but I understand better what's oging on now.
sam: could give a defintiion from both sides of the layer that are provably
identical.  Nico's is great for thinking as a gs2 implementor.
nico: what I said earlier that upset you may have done so because I said
it in terms of implementation details.  In actual english, we want sasl
sam: the phrase "what we want" makes me upset
nico: the problem is, sasl/gs2 allows you to advertise dash-plus for
mechs where dash-plus does not give you want we intended for it to mean.
sam: two ways to do it: change gs2 or eliminamte mechs
nico: or change what dash-plus means.
sam: think no one is proposing that.
option 1 change gs2
option 2 decouple mechs that can't do it right
nico: do we want consensus on which to choose?
sam: still want to understand problem
tlyu: possible problem with #1 -- there are several different gradations
of not supporting channel bindings, that applications might want to distinguish
among, and we would be doing a great disservice to them if we did not provide
them a way to do that.
nico: expand?  What gradations?
tlyu: please be patient.
app (either side) wants to know information about what security properties
its channel has.
sam: want to understand what properties gs2 needs;
tlyu: trying to do that; nico: gs2 needs for dash-plus, or period; sam:
assuming gs2 works today, want to understand what each side authenticates
and why each side eepends on integrity protection, and what you get out when
it works today; nico: we could start withi authz id
nico: what goes wrong if we don't check authz id
sam: mitm could change and change level of privilege granted
server could care about information disclosure (e.g., s4u2u-like thing)
IN that case, both server and client have availability and integrity
interest in protecting the authz identity.
nico: doni't disagree, as in practice, people only have one avaliable
authz id to them.
Sam: in that case, you don't send it.
nico: right.  attacker can strip, modify, or add it.
sam: both server and client potentially have interest in integ of authz id.
I'ma sking about that because I want to get around to what mutual buys us.
Client gets to know that server verified things.  ONly important if the
client happens to have an interset in their integrity.
If client doesn't care if attacker changed authz identity...
nico: why does mutual get you information that the server validated the id?
sam: only possible thing I could ... gs2 seems to be making that assumption.
I think it's true for all mechs that provide cb and mutual
nico: what about kerberos?
sam: validate that cb input on init/acceptor are the same.
If you have mutual auth, then since authz id is included in cb input,
then have confidence that authz id has not been modified.
cantor: yes
tlyu: ???
sam: this is true for all gss mechs providing cb and mutual, as used by gs2,
that we know about.
???
For authz id, the cb input is confirmed byt he server and by the client.
cantor: gs2 in general or when a plus mech is used?
sam: for this, in general
cantor: my ipression is that gs2 is asaying if you don't use plus mech,
then there are weaknesses but you are apparently accepting those
sam: could accept weakness, or say you only get to use authz id if you
have cb and mutual.
cantor: not trying to focus on solutionst, but what are we saying about gs2
under what conditions.
sam: if without mutual, the server is able to confirm cb, then an attacker
cannot modify the authz identity.  Without mutual, might not be talking to same
server... nico, can you think of a reason we care about mutual for authz
identity? nico: no.  But mutual means different things in different places.
name of server, or talking to same person?  In kerberos, you know name of
server, the second message is completely irrelevant. sam: second message means
that you're actually talking to that entity nico: yeah, but no harm in talking
to wrong one if they can't decrypt them. Then you don't care about a mitm. sam:
well, session setup is relevant, so many applications for which learning that
you don't have a session key at session setup is useful for implementaiton
reasons. nico: why do I care if mitm can't change things? tlyu: you're making
assuptions about application protocols nico: just because didn't have mitm
once, doesn't mean that there won't be one later (who drops packets, etc.) sam:
mutual means keytab is correct, detects operational problems. tlyu: I didn't
hear anything in your exmaple about what protections the application porotocol
was providing for your syslog-type scenario. Cleartext?  Auth or integ or
confidentialty protection? nico: say conf udp packets to the ip address, but
maybe it's the wrong one. the mitm could stop sending my messages to the real
server.  If I want to make sure that it gets back to the server, I need acks
,but the AP-REP does not buy me anything.  Learning the server's name is
valuable, but for kerberos you already have it. tlyu: for kerberos it does have
additional value, but don't want to gaet bogged down in details right now.
nico: but that's what sam wanted? sam: don't think this is valuable either.
nico: we're talking about mutual; I said two meanings.  Which one do we want?
sam: there's a third one. ??? mech verifies server name is as intended, and gss
context establishment is guaranteed to fail if the other end is not the
intended server name. It's not just good enought that the other end can't
decyrpot it, you need to know that they did. Say using gs2-krb5, and krb gets
rid of its apreq, cause you say they don't need it.  I'm an attacker, want to
impersonate the server.  You send your token, and it might just go and claim
success.  Because there's no ap-rep, you're willing to go on with a
converstaion with me. nico: yeah, but I'm not really, because I'm encrypting
everything. sam: gs2 nico: oh, but this is gs2.  Okay. sam: gs2 gets from
mutual, and it's not clear that gss gives this, but gs2 wants it.  i_s_context
will fail lif wrong server, and  (2) server confirms that there are channel
bindings. tlyu: that makes sense. Also remind people that authentication is not
proving an identity or verifying it; authentication is the association of an
identity with some other piece of information that is security relevant.  For
kerberos, the ap-req associates timestamps, servername with a particular
cryptographic key. mutual indicates that the server has successfully decrypted
and verified the authenticator. sam: aslo important to note that the kerberos
gs2 mech also indicates some things with respect to channel bindings. tlyu:
right sam: if the cb flag is important because an attacker could set the cb
flag and it wasn't integrity protected, then the attacker could impoersonate.
could cause server to think that cb was used whtn it was not.  Could be not big
problem, as server might not care. Attacker could clear cb flags and cause
success when there should not be success (i.e., when mitm).  Very important
that client can confirm server receipt of cb flag. nico: we really want mutual
insense of confirming cb.  Don't waht it in the sense of mutual, but in thes
ense of confirmed cb. ??? nico: want to get into discussion about what it means
for acceptor to not have a name but have mutual. sam: can't have dash-plus for
that, but not sure. nico: ??? not clear that it's useful either.   A lot more
useful than nothing at all. that might not apply to gs2 at all because we
always want to have a service name. sam: okay, now that I understand the
security properties... does everyone on the call who cares think they
understand the gs2 properties? [roll call] do we get value out of having gss
mechs that don't do cb? I think that's the right way to phrase the question,
can we agree on that? cantor: answer seems "yes", as ssh is an application in
general sam: we'll get there do you agree that that's the right question?
cantor: yeah, because I think you're jumping over the gs2 piece and can work
backward to get to the right thing. sam: applications where want to use a gs2
mech that isn't in sasl. ssh is one, but ssh requires evn more, it requires
mics from the mech. cantor: not for authentication sam: that's right, if mech
doesn't support integ, then it doesn't have to produce a mic. nico: hope that's
not so cantor: there's an authenticaiton-only option for using a mech with gss
sam: [to nico] see seciton XXX of rfc XXX I think Scott's right. nico: for
keyex, if integ is not available then you fail. I'm just reading through.
[shawn: process, 20 minutes left; 10 minutes for each item left on agenda.]
Sam: based on this, I'd say yes we do want such gss mechs, and that makes me in
favor of option 1 (change gs2 to support mechs that don't do mutual and have
them not have a dash-plus variant). cantor: don't feel qualified to have
opinion on gss mech issue, but was tyring to make it quick by raising ssh
issue. shawn: okay, we'll craft options and post to the list, get consensus
there. tlyu: I think option 1 needs some pretty substantial security
considerations text attached to it if we're gooing to do taht. shawn: yes. sam:
maybe.  Yeah, possibly. shawn: nico, being one of the original authors, would
you be able to update the gs2 spec nico: possibly, yes sam: Simon may have some
cycles. He may have an opinion; he said he was going to post something to the
list but didn't get around to it. shawn: he was going to comment on our
discussion as well. okay, so I think the chairs can go and craft the text for
the consensus call to make (obviously after nico, scott, and co-chairs go
through and make sure that we accurately construct the text for the call).

Channel Bound Proposals
-----------------------

shawn: I think we can move on to the channel bound proposals for gss since
the list never reached consensus on the two proposals.
I forget which one, was it Martin that was suggesting the null context?
Or was that you, Nico?
nico: that was me.
Martin agreed to review it and say something but he never did.
Shawn: okay, and the other option was to have a new set_credential_options
to indicate channel binding.  Was that from you as well, Nico?
nico: I made two proposals, [yes]  I prefer the empty context.
shawn: the problem is that it kind of has a broader scope of changes
required now that mechanisms would have to..
nico: sort of: it has a benefit that it aligns more nicely with the java
bindings, for example.  Whether people see value is a nother story.
It has the benefit that it makes future extensiosn along these lines
much simpler.  For exaple if we run out of flag bits.
For met ehre's a lot of value in that.
sam: the concern I have, not a strong opinion, am nervious that we're making
it harder and harder to create new mechanisms.  The amount of crap you
have to deal with to create new gss mechs is really alot.
nico: standards-track?
sam: implementaiton.
The amount of code in ??? that isn't mech-specific is quite annoyingi and large.
shawn: the tradeoff is between mech developers and application developers
sam: no, tradeoff is between architectural purity and ??? developers.
nico: I prefer architecturarl purity.  Either way, we're adding stuff that
mech implementors have to do.  I odn't see how one is simpler than the other.
sam: for mecheap, I'm much more confident in... both are doable, I'm not
objecting, but I think that the null context is likely to add more instability
and more bugs and be a little harder to implement.
ghudson: other option?
nico: mech attribute, new flags...
sam: set_cred option
nico: I find all of that ugly, it's not just ugly, I feel like we're painting
ourselves into a corner, and would much prefer to have an empty context.
It makes the gssapi much easier to use from an application perspective.
And we might be able to save gss-eap from having to ipmlement this, if
we already have a set_cred something for an attribute than the mechglue
might be able to have some bits to support that.
sam: only if you can count on all the mechglues.
We will implement whatever gets standardized; that's not a problem
tlyu: nico, I suggest that your proposal of using a null context as a way
to simplify the api has sufficient value that you'er selling yourself short
by putting into this other proposal, rather than having it stand on its own
merits.
nico: I'm willing to separate them and have two rfcs.
sam: with chair hat, please don't.
nico: also willing to have one rfc.
Comment about sam's point about mechglues: no standard api between mechglues
and mechanisms.  Don't think we want to consider the ease of integrating
with existing mechglue; I think that's out of scope
sam: I don't, it's an implementation issue that epopel have to face.
nico: say have three different mechglue iplementations, need ifdefs and such,
I'm fine with it.
sam: I'm not
nico: I would like to not be fine with that, but there is no standard interface,
but until there is, I don't think we can have your desires or mine (as mech or
other ipmlementor), we can't... ghudson: agree with sam that the situation for
mech developers is bad, but there aren't many of them.  There are lots of
application developers. So loading context flags into cred options forces those
application developers to acquire creds and set options, which is a significant
change. Once the null context is in, it's a change, but it cuts out a lot of
subsequent stuff.  If they had to do creds, then more stuff changes. sam: whoa,
didn't think that null context was going to change api for
init_sec_context/etc. async isn't on agenda, right? nico: no, it's not.  Buf if
you want it, you'll want null context anyway. ghudson: maybe Iw as confused, I
guess you didn't specify a variant that offered an init_sec_context variant.
nico: I didn't in this document. ghutdsno: I think that applications which
don't currently get creds would find it difficult to do so in order to set a
context flag. nico: I agree, and also say that the beauty is useful for the
application as well. shawn: consensus, let's take to list kaduk: and argue
about which bits to put in first document nico: third item on agenda?

IAKERB
------

shawn: iakerb
ghudson: extra bad news, another difference which I think is superficial,
which has to do with framing.
shawn: first q is do we want to adopt a pku2u draft or include text from it
for the iakerb draft.
Arguments for pku2u draft is that there are a couple of implementations already
kaduk: are people using them?
shawn: would require recharter
schaad: implmenetaiton of that or of icap (?)  I thought otherwise.
sam: mit ships iakerb or something close.  microsoft and apple ship
pku2u.  I think apple also ships iakerb.
nico: why can't we ship both?
what's the q again?
ghudson: goal is finish iakerb; problem is the pku2u reference.
Can adopt or cut/paste.
nico: I think we should adopt pku2u
sam: or finish pku2u as individual submission
that's the trakc it was on; it had gone through enough review.
big question is whether there's enough editor cycles to actually get it done.
nico clarifies: should finish pku2u, not necessarily adopt.
what text is needed?
ghudsoN: the finishend extension.  Earlier versions had its own, butpku2u
was developed and they decided to reference it.
it's a checksum over the conversation.
the bigger issue is that when we implemented it we didn't realize that there
was a newer version of the draft, and there are some superficial diffs
that prevent interop but they use the same mech oid.
shawn: also conficts for keys and id numbers from pku2u and iakerb drafts.
schaad: if pku2u goes forward you have a real problem.  It's using the
same extension numbers that mit iakerb is using
ghudson: no
pku2u finisedh uses type 2 and key usage 41
mit uses extension type 1 and usage 42
draft can go forward as-is, but do iakerb acceptros have to support both
also framing issue, we implemented only for first context tokens, but
the new one says all tokens.  Acceptors could support both, just as for
the finished extension.
shawn: greg, could you post to list?
ghudson: yes
shawn: enough information to make consensus call amongst ourselves
sam: do we have someone to move pku2u forward
schaad: could hold pen on it, but don't have knowledge to know if
doing right or wrong.
sam: I think we need microsoft to commit to looking at what we're doing
and seeing that what we're doing is compatible with what they ship.
would they follow the effort enough to interop
nico: also concern about how to ??? services.  Whole discussion we had
in the context of browserid.
sam: pku2u does have a solution to that which was agreed on the skim mailing
list
nico: but might not work in practice
sam: enterprise cas
nico: yes, enterprise CAs will work.
Add an options, existing implementaitons will interop
Does that make sense?
sam: sure, we can have that discussion, but it makes sense.
shawn: Jim ihas agreed to authro
sam: consensus: agree to move pku2u forward if microsoft agrees to stay
involved in the effort.
ghudson: any reason for finisehd to be in pku2u not iakerb?
Make iakerb define it (and go first) and pku2u reference iakerb.
Requires editorial work on pku2u but I think it sounds like more would
be needed anyway.
kaduk: jim asked for help pulling bits into iakerb on-list and got no reply.
anyone here?
sam: hard to move forward on pku2u until Jeff Hutzleman gives state dump.
[...]
ghudson: I tihnk want finished extension in iakerb.
shawn: consensus here for that?
[pretty much]
schaad: it's stuck in ad-hoc, not clear which paragraphs refer to it.
tlyu: requires a little care to disentangle, but I don't think it's too
difficult.
kaduk: also look at old iakerb drafts for finished extension tips
ghudson: yes, though obviusly numbers are different.
shawn: okay, I think we have rough consensus on that.
We can post to list as well.
Do we have enough info to make consensus call for key/extension numbers.
If goal is to make MIT implemeentation interoperate, it's not just
finished extension but also the asn1 encapsulation of the context initiation
tokens.
shawn: deployments right now using MIT?
ghudson: we don't know.  In several releases but we don't necessarily have
a channel when people start using our stuff.
schaad: anyone using apple's stuff?
ghudson: even less information there
shawn: love was joined in that discussion?
schaad: inclination is roll back to mit numbers and see if anyone yells.
nico: looking at heimdal right now.
ghudson: I don't think they have it; it's the apple-only verison of it.
That's what I was looking at.  It seems a faithful implementaiton of the
current draft.
nico: where
ghudson: opensource.apple.com
shawn: is rolling back viable?
ghudson: problem is, if you implemented this, since use same mech oids,
if you were apple and wanted to change in a way to become compatible, you'd
have to break your own acceptors.  That's mMIT's problem with rolling
forward is that you'd break your own acceptors.
sam: new oid for standrads track
ghudson: not interoperable with either one, but is unique
not thrilled about a new oid, for proliferation of krb5-related oids.
That said, would be nice if it interoperated with at least one of the
implementations.
sam: krb5 mech authors already have a mechanism for dealing with multiple
oids for all osrts of horrible reasons.
nico: it does have an iakerb implementation
ghudson: I already looked at it; they did not make it interoperable with
mit they used the current draft.
shawn: options for consensus call on list are new oid for conflicts...
sam: both finished extensions?  Framing is hard.
ghudson: I think for both of these it's possible to make acceptors work
with both kinds of initiators.
Not sure if it's both directions of packets.
sam: other option is option from intiiator saying "i do standards-track"
ghudson: Does it apply only when doing an ap-req?
sam: that's ugly
schaad: probably cleaner to define a new oid (than to do the extension).
shawn: let's propose it to the list, everyone needs more time to think about it
ghudson: given that we're over time, I think the framing issue may be
premature.
shawn: maybe you can post your findings to the list first?
ghudson: okay
shawn: we're overtime and finished with our topics.
Open mic, anyone?
[nope]
thanks for joining; we'll start working on our action items and add stuff
to the list for consensus call.
end 13:16 edt

Open Mic
--------
No one came forward.

============
Session Over