Subject: [abfab] Getting the charter done

From: Leif Johansson <[email-masked]>
Date: Fri, 06 Aug 2010 00:34:05 +0200

Folks,

We're still working off of the version of the charter online at

* http://www.project-moonshot.org/bof/charter

Before and during the BoF session in Maastricht we had a few
proposals and a few things have surfaced since then.

Acting as one of the BoF chairs I'd like to kick off a discussion
that will hopefully lead to a charter that both the community and
the IESG likes.

Here is what Sam sent to the moonshot list on 26/7:

1) cover descriptions of issues that may require changes such as
user-interface in the architecture document; I think this is in the
current charter text.

2) Explicitly call out that when thinking about user interface we need
to consider the elements of information that will be required for user
interface. For example Eliot gave the example of a banking interface
that requires information of who you are paying, what you are paying for
and how much you are paying. We'd need to explore which of these
elements are needed where and do the same for other use cases.

3) Explicitly say that we want to hold to WG open to do a revision of
the architecture based on ongoing work including ongoing user interface
work throughout the industry.

During the BoF session there was consensus (by my interpretation) around
(2) at least.

- From the excellent notes we have the following AIs:

1) Make privacy more explicit in moonshot related materials - including
the charter.
2) Charter needs to specifically mention liaison with OASIS about the
SAML RADIUS binding.
3) Order deliverables in the charter in a more logical fashion.
4) Charter needs use-cases and architectures as deliverables.
5) In the charter, change "within the GSS-API" to "within the
application" on the 4th deliverable for broader applicability.

There was also consensus on the moonshot list (by my interpretation)
that the charter should explicitly make alternatives to GSS-API in
scope for the WG.

Finally Elliot has suggested a simplification of the introductory text
in the charter - Elliot: could you send your latest version to the list?

I'd be perfectly happy to attempt a new version of the charter based
on this set of changes.

	Cheers Leif

---

From: Josh Howlett <[email-masked]>
Date: Fri, 6 Aug 2010 10:39:51 +0000

> that the charter should explicitly make alternatives to GSS-API in

Related to this, during the BoF Glen stated there should be alternatives to RADIUS for the AAA leg. I believe there was consensus that Diameter transport must be supported and recommended within the architecture.
 
> I'd be perfectly happy to attempt a new version of the charter based

Thanks!

Josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 6 Aug 2010 14:35:57 +0200

Josh Howlett {mailto://[email-masked]] writes:

> Related to this, during the BoF Glen stated there should be alternatives
> to RADIUS for the AAA leg. I believe there was consensus that Diameter
> transport must be supported and recommended within the architecture.

Actually, I'd really like to see a clear problem statement before anything
else takes place.  As I attempted to say in the meeting, the pieces of
technology to be mutilated seem to have been chosen largely on the basis of
convenience: "We have RADIUS servers and all these apps that support GSS,
how shall we connect them?  I know, let's hack on EAP, everybody else
does!".  Of course, I have no idea if this is actually the case and even if
it were it is no condemnation of the project; it seems to me a very weak
basis upon which to build a standard, however.

> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Eliot Lear <[email-masked]>
Date: Fri, 06 Aug 2010 15:57:15 +0200

On 8/6/10 2:35 PM, Glen Zorn wrote:
> else takes place.  

I think the original proposed charter did this, but perhaps was a bit
verbose.  It's rather straight forward: there is a need to support
federated identity in non-web applications.  There is also a need to
scale discovery of identity providers.

Eliot

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 6 Aug 2010 16:37:56 +0200

Eliot Lear [mailto:[email-masked]] writes:

...

> verbose.  

I'd kind of like to verify this but the original charter seems to be missing from the proceedings.

> It's rather straight forward: there is a need to support

OK, I know this is an inside game but what does that mean _in this context_.  I can find at least half a dozen definitions of "federated identity" w/at least that many commercial products claiming to support it.  Which one is this?

---

From: Sean Turner <[email-masked]>
Date: Fri, 06 Aug 2010 10:41:36 -0400

> I'd kind of like to verify this but the original charter seems to be missing from the proceedings.

Here's a link to originally proposed charter: 
http://www.project-moonshot.org/bof/charter

spt

---

From: Eliot Lear <[email-masked]>
Date: Fri, 06 Aug 2010 16:43:57 +0200

Glen,
> OK, I know this is an inside game but what does that mean _in this context_.  I can find at least half a dozen definitions of "federated identity" w/at least that many commercial products claiming…

My apologies- I was a bit imprecise.  Here I mean federated
authentication and authorization, meaning (loosely) that someone is able
to make use of a service by authenticating with another entity using a
pre-existing set credentials.  There are a whole lot of solutions around
for web-based services, but very few for non-web.

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 6 Aug 2010 17:53:20 +0200

Eliot Lear [mailto:[email-masked]] writes:

> Glen,
> > OK, I know this is an inside game but what does that mean _in this
> context_.  I can find at least half a dozen definitions of "federated
> identity" w/at least that many commercial products claiming to support
> it.  Which one is this?
> >
> 

Correct me if I'm wrong, but I could.ve sworn that one of those was standardized in the IETF: Kerberos.  It may be for various reasons unpopular with the Moonshot folks, but is that a good reason to rubberstamp theirs?

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 6 Aug 2010 18:10:28 +0200

Thanks!

...

---

From: Klaas Wierenga <[email-masked]>
Date: Fri, 06 Aug 2010 18:23:57 +0200

Glen,

>> context_.  I can find at least half a dozen definitions of
>> "federated identity" w/at least that many commercial products
>> claiming to support it.  Which one is this?
>>>
>>
>> authentication and authorization, meaning (loosely) that someone is
>> able to make use of a service by authenticating with another entity
>> using a pre-existing set credentials.  There are a whole lot of
>> solutions around for web-based services, but very few for non-web.
>
> Correct me if I'm wrong, but I could.ve sworn that one of those was
> standardized in the IETF: Kerberos.  It may be for various reasons
> unpopular with the Moonshot folks, but is that a good reason to
> rubberstamp theirs?

no, that is not a good reason ;-)

I guess the argument here is that there is a large installed base of 
SAML-based federations and these guys would like to leverage their 
existing infrastructure for access to non-web applications. Given the 
uptake of SAML I think that makes sense, and applicability beyond this 
one community. In addition to that there are AAA-infrastructures that 
have proved to scale. I think that at least it makes sense to explore 
combining SAML and AAA in this way. The briefing document defines therefore:

1- an API to integrate fedauth into application protocols
2- a federation fabric
3- a mechanism to communicate credentials and other information between 
principal and IdP

for 1, 2 and 3 they have initially chosen resp. GSS-API, AAA and EAP. It 
is my understanding that these choices are not yet carved in stone, but 
than that functionality needs to be provided by something else.

Klaas

---

From: "Scott Cantor" <[email-masked]>
Date: Fri, 6 Aug 2010 12:30:10 -0400

> no, that is not a good reason ;-)

I think it is if the uptake of Kerberos for federation is non-existent, and
it's certainly close to that. Another criteria might be whether the proposed
approach is likely to exceed that adoption, and of course I can't answer
that.

If we'd like to talk about what needs to happen to make Kerberos better for
federation, we can certainly do that somewhere too.

> existing infrastructure for access to non-web applications.

I really think it's more pragmatically "HELP"!

We need an answer. Kerberos today is not one. Using a browser hack is a
popular one, and it's one I really, really don't like, as Klaas can attest.
But if nothing else gets done, it's going to win. So any other suggestions?

That's where the proposal is coming from, IMHO.

-- Scott

---

From: Josh Howlett <[email-masked]>
Date: Fri, 6 Aug 2010 16:41:10 +0000

Glen,

> unpopular with the Moonshot folks, but is that a good reason to

IMO Kerberos is a great protocol; unfortunately it just doesn't address the use-cases at hand.

We explicitly asked Sam to compare Moonshot with other alternatives precisely to avoid re-inventing the wheel; please check out section 10 of the Moonshot 'Feasibility Analysis' for this discussion.

http://www.project-moonshot.org/sites/default/files/moonshot-feasibility-analysis.pdf

Best regards, Josh.

---

From: Klaas Wierenga <[email-masked]>
Date: Fri, 6 Aug 2010 20:21:37 +0200

Sent from my iPad

> I really think it's more pragmatically "HELP"!

But that is mainly for the idp discovery and metadata distribution part, right? Not so much for the non-web aspect.

> popular one, and it's one I really, really don't like, as Klaas can attest.

Yes, I can ;-)

Klaas

---

From: Sam Hartman <[email-masked]>
Date: Fri, 06 Aug 2010 14:47:29 -0400

I do find it telling that several of the major Kerberos
contributors--myself, Nico--think that gss-eap is a better fit than
Kerberos today.

I think I've answered in enough detail for a charter discussion in the
section on the feasability analysis.  Ultimately, I think Kerberos is
something to continue to think about, but several of us who are very
familiar with Kerberos have tried to fit it into this model and failed.

I actually think we'll be able to re-use much or all of this work if we
do ever figure out how to make Kerberos part of the abfab ecosystem.  I
plan to continue those explorations but think we've gone down that path
enough to conclude that we don't want to block abfab on its conclusions.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 6 Aug 2010 11:36:23 -0500

> Actually, I'd really like to see a clear problem statement before anything

A clear problem statement is always a good thing, and here critical.

>                    As I attempted to say in the meeting, the pieces of
> convenience:

Is there any better way to choose technologies to mutilate?  I suppose
if one is to mutilate technologies, then choosing them randomly might
work well enough.

More seriously: convenience is going to be critical to deployment.  And
in this case it seems to be driving the design.  Observing that "these
are the pieces we have" leads one to ask "how can we leverage them into
solutions to bigger problems?" -- a much better question than "how do we
replace them with a cleaner solution?" or worse, than just giving up on
solving bigger problems.

The real question is not "is this the best way to put a solution
together?" but "will this work?" (for a value of "work" that includes
"secure").

>              "We have RADIUS servers and all these apps that support GSS,

What makes this "a very weak basis upon which to build a standard"?

The use of other standards as construction blocks??  Surely not!  I'd
have thought that'd be commendable.  Would you rather the proponents
build a proprietary solution instead?

Or did you mean that you see no way to build a secure solution using
these particular building blocks?  Such an objection I'd understand, but
please be specific, not only as to claims, but also please provide at
least a rough outline of how these building blocks make for a sub-par
solution.

Incidentally, this project violates my own sense of aesthetics, perhaps
as much as it seems to yours.  And I found your, er, "mutilation" of the
proposal rather funny.  But technical and economic issues trump
aesthetics.  I've long been a proponent of making it possible for users
to use existing authentication infrastructure rather than forcing them
to deploy specific authentication infrastructures in order to use this
or that application.  I see no reason why this case should be different.

Nico
--

---

From: "Scott Cantor" <[email-masked]>
Date: Fri, 6 Aug 2010 15:07:24 -0400

> But that is mainly for the idp discovery and metadata distribution part,
> right? Not so much for the non-web aspect.

No, I think the telling fact is that in the face of some complexity, the
Moonshot work has initially suggested dropping SAML from the base use case
for scenarios in which additional attribute information can be handled by
AAA. So if this was purely "how can we fit SAML in", that wouldn't be the
case.

On the SAML side, the wins are potentially all of those things (discovery,
via an active client, some new ways to think about metadata verification,
and the non-web applicability).

Obviously, we can fit SAML into the non-web problem in other ways too, but
the security will likely be weaker than these proposals. That makes for a
good set of options to trade-off, I think.

To speak to the "what exists now" argument, the alternative to this work
today is not Kerberos, it's IMI/Infocard.
 
-- Scott

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 6 Aug 2010 11:40:50 -0500

> unpopular with the Moonshot folks, but is that a good reason to

There's also PKI.

But not everyone has a PKI or a Kerberos infrastructure deployed.  Users
should be able to use the authentication infrastructures that they
already have unless they are woefully inadequate.

Now, there are many ways that I could see to do this.  One would be to
extend Kerberos pre-authentication to support such other authentication
infrastructures, thus leveraging them into a Kerberos infrastructure.

I'll note too that Kerberos isn't quite a federated authentication
system, but that's a matter of missing pieces rather than fundamental
limitations (much the same applies to PKI).

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 6 Aug 2010 14:23:57 -0500

> no, that is not a good reason ;-)

I object to the notion of "rubberstamping", and to the notion that the
IETF has or should have a single applicable standard.  The popularity or
not of <fill-in-the-blank> with <fill-in-the-blank> has been, is and
should continue to be irrelevant at the IETF.

The IETF has several standards-track authentication mechanisms, more
than one of which allows for transitive trust and/or namespace
delegation.  One more wouldn't hurt.

The thing that bothers me is that standard mechanisms are not really
usable in web contexts.  Moonshot doesn't have to help that problem,
though I'd certainly like to see it helped.  For me the guiding
principle here is that whatever authentication infrastructure a user
has, they should be able to use it in Internet protocols and web
applications, as well as non-Internet protocols that use Internet
protocols such as SASL and the GSS-API.

(On a separate note, I'm concerned about how trust transitivity is
used.)

Nico
--

---

From: Klaas Wierenga <[email-masked]>
Date: Fri, 6 Aug 2010 22:26:48 +0200

Sent from my iPad

> should continue to be irrelevant at the IETF.

I didn't mean to suggest that, what I was referring to was the 'because it is unpopular' statement. I think it is good engineering practise to first look at what is available and see whether that satisfies your requirements before going on a new endeavor. I think the moonshot people have investigated alternative approaches, and those don't satisfy the requirements for different reasons, be it technical, commercial or lack of uptake. They are not trying to rubber stamp whatever they came up with but seek guidance from the IETF community, I think that that is commendable. Otoh Glen's questions are justified imo, we should be critical towards the chosen directions, and if there are better ways of solving the problem we should be open to that.
  
> (On a separate note, I'm concerned about how trust transitivity is

I am interested in your concerns here, do you care to comment on that? ( perhaps in a separate mail )

Klaas

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 6 Aug 2010 16:01:11 -0500

On Fri, Aug 06, 2010 at 10:26:48PM +0200, Klaas Wierenga wrote:
> I didn't mean to suggest that, what I was referring to was the
> 'because it is unpopular' statement. I think it is good engineering
> practise to first look at what is available and see whether that
> satisfies your requirements before going on a new endeavor. I think
> the moonshot people have investigated alternative approaches, and
> those don't satisfy the requirements for different reasons, be it
> technical, commercial or lack of uptake. They are not trying to rubber
> stamp whatever they came up with but seek guidance from the IETF
> community, I think that that is commendable. Otoh Glen's questions are
> justified imo, we should be critical towards the chosen directions,
> and if there are better ways of solving the problem we should be open
> to that.

You're right, and my response (which was really intended for Glen) was a
bit over the top.  The point is that off-the-shelf solutions are always
better, except when they aren't, and that it is possible for an
off-the-shelf solution to fail to meet requirements without that being
the result of a subjective popularity contest.

The very fact that the IETF doesn't have one, but at least two security
technologies that in many ways are equivalent (PKIX and Kerberos) is
proof of that.  Though, of course, there may well be examples of
redundancy arising for bad reasons (perhaps SASL vs. the GSS-API is an
example of that).

It is necessary for the IETF to eliminate unnecessary redundancy for the
simple reason that review capacity is limited.

Nico
--

---

From: Leif Johansson <[email-masked]>
Date: Fri, 06 Aug 2010 23:10:26 +0200

> replace them with a cleaner solution?" or worse, than just giving up on

I think you made _the_ critical observation Nico. The moonshot proposal
isn't trying to build something from scratch but from available pieces.

Perfect is often the enemy of the good (enough).

	Cheers Leif

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 9 Aug 2010 13:10:27 -0500

> contributors--myself, Nico--think that gss-eap is a better fit than

It's worth noting that some of us are usual suspects in the Kerberos
world.  Sam and I, for example, have been active in the KRB-WG for about
a decade (Sam probably for longer).  And have authored or co-authored
Kerberos RFCs and reviewed many more.  And we are or have been
implementors.

Normally one would expect people to boost the technologies they are most
familiar with.  But that is not what's happening here.  There's a reason
for this: Kerberos isn't the solution to every security problem, not any
more than PKI is.

> familiar with Kerberos have tried to fit it into this model and failed.

I think you have, but I'd like to explore a related angle.  I hope this
will help settle the desirability of Moonshot.

Let's consider the range of possible solutions here.  We have some
authentication infrastructure that exists already but is neither PKI nor
Kerberos.  And we want this to be usable wherever SASL/GSS-API are
usable, as well as in web and non-web HTTP applications (but allow me to
ignore the HTTP apps for now[*]).

I see two types of solutions:

 - Type 1: Add "pre-authentication" to PKI (via SACRED or online CAs
	   that issue short-lived certs) or Kerberos that uses the
	   existing authentication infrastructure.

 - Type 2: Add a GSS-API (and therefore SASL/GS2) mechanism that uses
           the existing authentication infrastructure.

Note that that type 2 is actually a... usable in type 1 solutions!

That's because SACRED already uses SASL...  And we could easily define a
Kerberos pre-authentication method that uses the GSS-API... (in fact,
I've proposed this in the past).

Clearly, by far the the most general solution is type 2 + a generic
variant of type 1 (i.e., where pre-authentication uses GSS mechanisms).

In other words, if you want the most general solution you should want
_both_.  And you should want to start with type 2 solutions.

Now, what does solution type 1 buy us over solution type 2?  Ticketing,
effectively, and the ability to combine multiple existing authentication
infrastructures.  If you have Radius... you can have Kerberos!  Nice.

But if you don't need ticketing and you don't already have Kerberos (or
PKI) deployed, then solution type 1 simply adds overhead, signficant
overhead.  Enough overhead to make it unlikely to ever be deployed.

Which gets me back to the principle that Internet protocols should
support the authentication infrastructures that users have deployed.
Internet protocols should absolutely NOT dictate which authentication
infrastructures users must deploy.

Exceptions for protocols like IKE should be allowed but only because we
can define additional KE protocols such as KINK, though I'd really
rather make IKE itself able to use a variety of authentication
infrastructures by making it pluggable (it alread is or is becoming, via
EAP, but IMO it also needs direct GSS-API support for non-VPN uses of
IPsec).

[*] Back to HTTP...  For non-web apps I think HTTP/Negotiate will do.
    For web apps I think we need something more like a REST binding of
    the GSS-API, with channel binding to https via tls-server-end-point
    CB (though I can also see how to do it with tls-unique CB).

Nico
--

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 9 Aug 2010 21:23:37 +0300

Just trying to figure out what you mean: 

> 	   that issue short-lived certs)

Something like 
http://tools.ietf.org/html/draft-ietf-sip-certs-14
?
(similar mechanisms have been developed for other protocols; for XMPP I
suspect that this spec would be the right to reference
http://xmpp.org/extensions/xep-0257.html)

(Other SDOs have defined similar protocols; there is clearly no shortage
on specs -- only on the deployment side...)

> or Kerberos that uses the

Something like 
http://tools.ietf.org/id/draft-tschofenig-pana-bootstrap-kerberos-00.txt
or more something like Appendix A of
http://tools.ietf.org/id/draft-tschofenig-enroll-next-steps-00.txt

The former is more attached to the network access authentication
procedure than the latter. 

Ciao
Hannes

PS: There are obviously lots of options but the question is which onces
are most likely going to be successful from an implementation &
deployment point of view.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 9 Aug 2010 14:12:13 -0500

> http://xmpp.org/extensions/xep-0257.html)

No, I meant specifically SACRED, with a SASL mechanism that does the
RADIUS EAP thing.  (But I only read the abstract of draft-ietf-sip-certs.)

> http://tools.ietf.org/id/draft-tschofenig-enroll-next-steps-00.txt

Maybe, but I see nothing in draft-tschofenig-pana-bootstrap-kerberos
about pre-authentication.

> deployment point of view. 

Exactly.

For me there's also a degree of generality.  I'd like all GSS-API
mechanisms to be usable in all of the following cases:

 - Application protocols using SASL (via GS2):
    - IMAP, SUBMIT, SMTP
    - LDAP
    - SACRED (and any related online CA protocols -- think kca, but with
      GSS-API instead of raw Kerberos for authenticating the requestor)
    - XMPP
    - ...
 - Application protocols using the GSS-API:
    - SSHv2
    - NFSv4, FTP (and SFTP via SSHv2)
    - DNS GSS-TSIG (for DNS updates)
    - ...
 - non-browser HTTP apps (XMPP, *DAV)
 - browser HTTP apps
 - IKEv2

 - Kerberos pre-authentication (preferably via the GSS-API)

 - I'd also like ways to use all the authentication mechanisms that we
   have in EAP applications as well.

This degree of generality means users can use whatever authentication
infrastructure they've already deployed.  And it means we can bridge
authentication infrastructures where necessary.

Nico
--

---

From: "Scott Cantor" <[email-masked]>
Date: Mon, 9 Aug 2010 17:23:35 -0400

>     CB (though I can also see how to do it with tls-unique CB).

I had the impression you meant "web" vs "non-web" as "browser" vs
"non-browser", so I would think that's reversed, if anything. Browsers seem
to support Negotiate already, at least somewhat. A REST approach would seem
more in demand for all the clients out there that might be (unfortunately)
one-offing HTTP.

-- Scott

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 9 Aug 2010 16:41:20 -0500

> more in demand for all the clients out there that might be (unfortunately)

Do browsers support Negotiate with HTTPS and channel binding?  If so,
wow.  If not, well, then I'd expect that the REST thing would work
better, provided there's some JavaScript bindings for the GSS-API and/or
a way to make authentication go from HTML.

Nico
--

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 9 Aug 2010 23:50:14 +0200

Hi Nico,

related the two types of solutions you just mentioned, we sent a few months ago a small set of very preliminary slides (you may find an attached version in this e-mail) to the moonshot mailing list regarding the next two alternatives:

-- EAP-based Kerberos pre-authentication where KDC is acting as EAP authenticator (and Kerberos protocol acting as EAP lower-layer). Then, the KDC can interface with a backend AAA infrastructure. With the key material obtained after EAP authentication (e.g. MSK) it would be possible to generate a shared secret between Kerberos client and KDC. 

-- a GSS-API based Kerberos pre-authentication where Kerberos uses GSS-API to obtain pre-authentication data. In particular, the GSS TOKEN could carry EAP as EAP-GSS approach specifies. (this could be the generic variant of type 1?).

So, if my understanding is correct, I think first option (EAP-based Kerberos pre-authentication) is a Type 1 solution and second option (GSS-API based Kerberos pre-authentication) is an example of type 2 use in type 1 solution, right?. 

Nevertheless, in terms of Kerberos, I believe that solutions which bootstrap Kerberos credentials by means of some out-of-band mechanism (so that they do not use Kerberos pre-authentication mechanism) may not fit well in type 1 or type 2 solutions (as may happen with the Hannes' I-D draft-tschofenig-pana-bootstrap-kerberos-00). Obviously, unless the term "pre-authentication" in type 1 also includes an "pre-authentication" mechanism different than Kerberos pre-authentication. Do you refer to Kerberos pre-authentication in type 1 or a more general "pre-authentication" mechanism?.

Best regards.

>    CB (though I can also see how to do it with tls-unique CB).

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 9 Aug 2010 17:04:32 -0500

On Mon, Aug 09, 2010 at 11:50:14PM +0200, Rafa Marin Lopez wrote:
> related the two types of solutions you just mentioned, we sent a few
> months ago a small set of very preliminary slides (you may find an
> attached version in this e-mail) to the moonshot mailing list
> regarding the next two alternatives:
> 
> -- EAP-based Kerberos pre-authentication where KDC is acting as EAP
> authenticator (and Kerberos protocol acting as EAP lower-layer). Then,
> the KDC can interface with a backend AAA infrastructure. With the key
> material obtained after EAP authentication (e.g. MSK) it would be
> possible to generate a shared secret between Kerberos client and KDC. 

So... the client speaks EAP and the NAS speaks krb5 AS exchanges to the
KDC?  or the client speaks Kerberos with EAP pre-authentication?

The former is type 2, the latter is type 1.

> -- a GSS-API based Kerberos pre-authentication where Kerberos uses
> GSS-API to obtain pre-authentication data. In particular, the GSS
> TOKEN could carry EAP as EAP-GSS approach specifies. (this could be
> the generic variant of type 1?).

This would be type 1, yes.

> So, if my understanding is correct, I think first option (EAP-based
> Kerberos pre-authentication) is a Type 1 solution and second option
> (GSS-API based Kerberos pre-authentication) is an example of type 2
> use in type 1 solution, right?. 

I didn't understand your first option, and the second I understand to be
what I called type 1.

The key is: what does the client speak and to whom?

If the client speaks first to infrastructure using Kerberos, with a
pluggable pre-authentication framework using GSS-API mechanisms, then
that's type 1.  Similarly if the client speaks kca or SACRED using
GSS-API mechanisms.

If the client speaks SASL/GSS-API to the relying party (server) and the
mechanism itself speaks EAP, IAKERB, and so on to infrastructure, then
that's type 2.

> Nevertheless, in terms of Kerberos, I believe that solutions which
> bootstrap Kerberos credentials by means of some out-of-band mechanism
> (so that they do not use Kerberos pre-authentication mechanism) may
> not fit well in type 1 or type 2 solutions (as may happen with the
> Hannes' I-D draft-tschofenig-pana-bootstrap-kerberos-00). Obviously,
> unless the term "pre-authentication" in type 1 also includes an
> "pre-authentication" mechanism different than Kerberos
> pre-authentication. Do you refer to Kerberos pre-authentication in
> type 1 or a more general "pre-authentication" mechanism?.

I did not consider out-of-band solutions.  Either those are
uninteresting or they fall into type 1.

Nico
--

---

From: "Scott Cantor" <[email-masked]>
Date: Mon, 9 Aug 2010 18:26:23 -0400

> Do browsers support Negotiate with HTTPS and channel binding? 

Negotiate, certainly. I don't think CB are supported.

My point is just that browsers aren't written by script kiddies, while other
clients often are (or at least tend to be used by them). You seemed to be
suggesting that the non-browser case was more likely to accommodate a more
complex solution, which seems backwards to me.

> If so, wow.  If not, well, then I'd expect that the REST thing would work

If you meant authentication of script code running within a browser (i.e
JS), I didn't catch that implication. Even so, JS engines inside the browser
are usually part of the browser code base.

I don't know what REST buys you unless the goal is to support people that
would want to write REST clients and servers. I think the security should be
underneath that, or you're targeting the wrong developers and will end up
with as little security as such people can agree to.

-- Scott

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 9 Aug 2010 17:34:34 -0500

> Negotiate, certainly. I don't think CB are supported.

We need HTTPS and CB.

> complex solution, which seems backwards to me.

Browsers also don't evolve fast enough in this space.  I was hoping to
be able to do a simple FF extension with JS bindings for the GSS-API and
a JS method for doing GSS-API with CB in a RESTful fashion using
well-known URIs (see host-meta).  OTOH, if we can get XmlHttpRequest
extended (in FF and IE) to support Negotiate with CB then we're golden.

Non-browser apps can more easily have their HTTP libraries enhanced, or
at least so I assume.  But if my assumption is wrong then the GSS-API
REST approach can still be used there.

> are usually part of the browser code base.

I meant authentication of the user.  The code to make that happen can't
be delivered by the server because we want mutual authentication as
well, and we can't trust the server's code for that.

> with as little security as such people can agree to.

REST buys you not having to modify HTTP implementations.

For example, JavaScript XmlHttpRequest gives you everything you need to
implement SCRAM with CB to tls-server-end-point in a RESTful way.  The
only thing is... the script can't be delivered by the server (see
above); it has to be delivered by an extension.

Nico
--

---

From: "Scott Cantor" <[email-masked]>
Date: Mon, 9 Aug 2010 18:43:36 -0400

> REST approach can still be used there.

I think that's not so clear. It definitely depends on the app and the
library.

> REST buys you not having to modify HTTP implementations.

I get it. Thanks for clarifying.

-- Scott

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 9 Aug 2010 17:47:01 -0500

> I think that's not so clear. It definitely depends on the app and the

Right.  Apps should use either HTTPS/Negotiate with CB if possible or
the REST thing if not.

> I get it. Thanks for clarifying.

NP.

IMO not requiring changes to HTTP implementations is key...

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 9 Aug 2010 18:00:34 -0500

> IMO not requiring changes to HTTP implementations is key...

In particular I think the server-side of the REST thing can be
implemented without any changes to the HTTP layer, and the client side
only needs JavaScript bindings to SASL/GS2 or GSS-API -- again, no
changes to the HTTP layer.

The downside to the REST approach is that it is significantly chattier
than HTTP/Negotiate.  If request pipelining is not used (e.g., if
HTTP/1.0 is used) then you have 4 or so IP packet round-trips per
context token + the round-trips needed to fetch the host-meta, versus
just 1 in the Negotiate case (+ the round-trips for TCP connect and
shutdown).  With pipelining it gets much closer to being as round-trip
efficient as Negotiate.

Is there a specification for how to do HTTP/Negotiate with CB?  RFC4559
is clearly not it (since it pre-dates RFC 5056 and 5929).  Among other
things, how is server support for CB indicated to the client, and how
does the client indicate that it is using CB?  I.e., how is CB
negotiated?

Nico
--

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 10 Aug 2010 01:19:04 +0200

Hi Nico,

thanks for the answer, please see my answer below...

> KDC?  or the client speaks Kerberos with EAP pre-authentication?

[Rafa] We thought in a new Kerberos pre-authentication mechanism based on EAP. That is, 
EAP is directly transported in the padata field in Kerberos messages (such as KRB_AS_REQ/KRB_AS_REP). 
For example, this would imply definition of some new pa-data. 

Thus, the client acts as EAP peer and Kerberos client, so it speaks EAP and Kerberos. The flow would something like:

client (EAP peer) <---EAP over Kerberos---> KDC (EAP authenticator) <---EAP over AAA--> AAA infrastructure.

(slide 3 shows a more specific signaling) 

That is why I thought it would be type 1... unless I am missing something?.
> This would be type 1, yes.

[Rafa] Ok then the first alternative (EAP-based Kerberos pre-authentication) is similar to this one, 
since Kerberos interfaces directly with an EAP stack (instead the GSS-API)

> I didn't understand your first option,

[Rafa] I hope I was able to clarify it.

> and the second I understand to be
> what I called type 1.
> 

[Rafa] I am confused here. As far as I understood from the type 1, there was no reference to GSS-API.
So this type would include a pre-authentication mechanism which may not include GSS-API 
(as for example EAP-based Kerberos pre-authentication)

"- Type 1: Add "pre-authentication" to PKI (via SACRED or online CAs
	   that issue short-lived certs) or Kerberos that uses the
	   existing authentication infrastructure."

> mechanism itself speaks EAP, IAKERB, and so on to infrastructure, then

[Rafa] So basically here in type 2 we define a new GSS-API mechanism which is used 
by the client (GSS Initiator) and application server (GSS Acceptor). Then
the application server speaks to the infrastructure with the mechanism contained
in the GSS token. Is this correct?.

> uninteresting or they fall into type 1.

[Rafa] I believe that if they fall into type 1 then the term "pre-authentication" here may not imply Kerberos pre-authentication. 

On the other hand, (just curiosity): why do you think they are not interesting?.

Best regards

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 9 Aug 2010 18:27:31 -0500

On Tue, Aug 10, 2010 at 01:19:04AM +0200, Rafa Marin Lopez wrote:
> [Rafa] We thought in a new Kerberos pre-authentication mechanism based
> on EAP. That is, EAP is directly transported in the padata field in
> Kerberos messages (such as KRB_AS_REQ/KRB_AS_REP). 

Yes, that's type 1.

> That is why I thought it would be type 1... unless I am missing

Nope, it's type 1.

> [Rafa] I hope I was able to clarify it.

You did :)

> [Rafa] I am confused here. As far as I understood from the type 1,
> there was no reference to GSS-API.  So this type would include a
> pre-authentication mechanism which may not include GSS-API 

There could be.  You're using EAP for pa-data.  But you could have used
GSS-API.  And you could have defined a GSS-API mechanism that uses EAP.

Can you see now what I meant about generality?  If we have a GSS-API
mechanism that can use EAP... and we can use GSS-API in Kerberos
pa-data... and other places (SACRED, kca, ...; see the list I posted)...

> [Rafa] So basically here in type 2 we define a new GSS-API mechanism
> which is used by the client (GSS Initiator) and application server
> (GSS Acceptor). Then the application server speaks to the
> infrastructure with the mechanism contained in the GSS token. Is this
> correct?.

Yes.  But note that the GSS-API doesn't force you to have one or the
other of the initiator and acceptor to talk to infrastructure.  You can
do it either way.  In Moonshot the acceptor talks to infrastructure.  In
Kerberos the initiator talks to infrastructure.

A PKI mechanism could have both, the initiator and the acceptor, talk to
infrastructure (namely, to OCSP responders).

> [Rafa] I believe that if they fall into type 1 then the term
> "pre-authentication" here may not imply Kerberos pre-authentication. 

Right.

> On the other hand, (just curiosity): why do you think they are not

Well, to be honest I haven't thought enough about non-pre-authentication
types of out of band solutions.  So I was rash to call them
uninteresting.  My intuition says that there aren't any such solutions
that can't be thought of as pre-authentication (i.e., type 1).

Nico
--

---

From: Gabriel Lopez <[email-masked]>
Date: Tue, 10 Aug 2010 10:20:47 +0200

Hi Nico, all,

> pa-data... and other places (SACRED, kca, ...; see the list I posted)...
This is the second proposal described in the slides Rafa sent yesterday.

Best regards, Gabi.

-- 
----------------------------------------------------------------
Gabriel López Millán
Departamento de IngenierÌa de la InformaciÛn y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [email-masked]

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 10 Aug 2010 15:31:06 +0300

> simple reason that review capacity is limited.

And also multiplicity of options works against interoperability.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 10 Aug 2010 14:51:59 +0200

Hi Nico, 
> pa-data... and other places (SACRED, kca, ...; see the list I posted)...

[Rafa] As Gabi just mentioned, that is the reason (gain flexibility) of our second proposal "GSS-API based Kerberos pre-authentication", which precisely transports GSS tokens in pa-data. 

However, I feel that, in terms of implementation, it could be easier to implement directly interface EAP - Kerberos (already specified in some sense in RFC 4137) than implementing EAP over GSS-API first and then GSS-API over Kerberos. At least two new implementations may be required in the second alternative.

What do you think?

> Kerberos the initiator talks to infrastructure.

[Rafa] I am not sure if I understand this. When you say the initiator talks to the infrastructure in Kerberos... what do you mean?. In our proposal, the KDC, acting as acceptor, talks to the AAA infrastructure. So I am a little bit confused here.

> that can't be thought of as pre-authentication (i.e., type 1).

[Rafa] I also believe those kind of solutions could be classified as type 1, as long as we consider them as mechanisms which are used to authenticate user before KDC provides a TGT, for example. This mechanism can be part of the traditional Kerberos pre-authentication or potential out-of-band mechanisms.

Best regards.

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 10 Aug 2010 15:58:23 +0300

Hi Leif,

Are we expecting to see a revised charter that reflects the documented
consensus? 
The referenced text does not seem to do that.

Alper

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Leif Johansson
> Sent: Friday, August 06, 2010 1:34 AM
> To: [email-masked]
> Subject: [abfab] Getting the charter done
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> Folks,
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkxbPFgACgkQ8Jx8FtbMZndI8wCfS5N+qjfab/sQQboQ7m3reGl9
> JpsAnjqOSbgVW/hJ1WQTFTUEtF7YXOUH
> =A3L9
> -----END PGP SIGNATURE-----

---

From: Sam Hartman <[email-masked]>
Date: Tue, 10 Aug 2010 09:00:39 -0400

Your proposal includes a type 2 inside a type 1.  Mechanisms such as
iakerb can convert a type 1 into a type 2.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Aug 2010 08:33:21 -0500

> And also multiplicity of options works against interoperability.

Depends on the context, but, largely that is true.  In this context the
use of pluggable authentication frameworks helps.  These frameworks are
often implemented as pluggable frameworks as well (that is, they aren't
pluggable in name only).  Indeed, I would argue that the main hurdle in
terms of security interop in Internet protocols has been the uneven use
of different frameworkd in different protocols:

 - IPsec?  ->  PKIX (OK, now there's KINK as well)
 - TLS?    ->  PKIX
 - NFSv4?  ->  GSS-API  ->  Kerberos (even though the GSS-API is
                                      pluggable, until recently Kerberos
				      was the only standard option)
 - SSHv2?  ->  PK, GSS-API
 - IMAP, SUBMIT/SMTP, LDAP?  ->  SASL  ->  DIGEST-MD5 and Kerberos
 - ...

That is a recipe for non-interoperability as well.  We've been doing our
best to rectify this over the years.  The main way in which we've been
trying to rectify this situation has been to bridge security frameworks.
For example, the SASL/GS2 framework, which allows GSS-API mechanisms to
be used in SASL generically (and which fixes problems in the original
SASL/GSS bridge).

Your interop argument ignores the argument I made earlier, too, that
requiring users to deploy authentication infrastructures other than
those they already have is a recipe for non-deployment of Internet
protocols, or for standardization outside the IETF.

The IETF is a volunteer SDO.  IETF participants can choose not to review
[and therefore not charter WGs to standardize] any piece of work that is
brought to it, and have done so too.  Yet there is a cost to the IETF of
rejecting work that is relevant after all, and that cost is not zero.
Whether to take on some work is a non-trivial decision to make.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Aug 2010 08:51:57 -0500

On Tue, Aug 10, 2010 at 02:51:59PM +0200, Rafa Marin Lopez wrote:
> [Rafa] As Gabi just mentioned, that is the reason (gain flexibility)
> of our second proposal "GSS-API based Kerberos pre-authentication",
> which precisely transports GSS tokens in pa-data. 
> 
> However, I feel that, in terms of implementation, it could be easier
> to implement directly interface EAP - Kerberos (already specified in
> some sense in RFC 4137) than implementing EAP over GSS-API first and
> then GSS-API over Kerberos. At least two new implementations may be
> required in the second alternative.
> 
> What do you think?

I think we need to get our terminology straight.  I'm not sure what "X
over Y" means.  Instead I'd like to refer to these things as "X in Y" or
"X [pre-]authentication mechanism for Y", or "X Y mechanism" (where X is
the basis for a mechanism for the Y framework).

Thus a Kerberos pre-authentication method using EAP would be "EAP in
Kerberos" or, better, "EAP pre-authentication mechanism for Kerberos",
or "EAP Kerberos mechanism".

Can you clarify which you had in mind?

Each possible solution has its own implementation challenges.  But
generally speaking I believe type 2 solutions will be simpler to
implement than type 1 solutions.  That's based on the observation that
the pluggable frameworks that one fits into in type 1 solutions aren't
always all that pluggable in actual implementations, whereas type 2
solutions are much closer to pluggable.

That is, I think Kerberos pre-auth is much harder to plug into than
implementations of EAP, SASL and GSS-API.

For example, an EAP Kerberos mechanism requires specifying the relevant
PA-DATA type(s), fitting them into the FAST framework, and
implementation then is going to be very specific to the host KDC
implementation.  Implementation for Heimdal will be very different from
implementation for MIT krb5, which will be very different from Shishi,
which will be very different from the implementations for other (usually
not open source) KDCs.

While a Kerberos EAP mechanism will likely require no work on the
underlying Kerberos libraries and KDCs.  If the EAP implementation that
you're targeting has a public plug-in API/ABI then your work can stand
alone.

On the other hand, if you were trying to plug in to a PKI infrastructure
for a type 1 solution, well, SACRED is a lot more pluggable than
Kerberos pre-authentication!

> [Rafa] I am not sure if I understand this. When you say the initiator
> talks to the infrastructure in Kerberos... what do you mean?. In our
> proposal, the KDC, acting as acceptor, talks to the AAA
> infrastructure. So I am a little bit confused here.

"Initiator" and "acceptor" are GSS-API terms that roughly correspond to,
say, TLS "client" and "server".

The GSS-API doesn't dictate which, if any, of the two talks to
infrastructure services.

> [Rafa] I also believe those kind of solutions could be classified as
> type 1, as long as we consider them as mechanisms which are used to
> authenticate user before KDC provides a TGT, for example. This
> mechanism can be part of the traditional Kerberos pre-authentication
> or potential out-of-band mechanisms.

Yes, that makes sense to me.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 10 Aug 2010 10:00:43 -0400

Their first proposal was EAP pre-authentication for Kerberos.  Their
second proposal is GSS pre-authentication for Kerberos using an EAP
GSS-API mechanism.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Aug 2010 09:10:16 -0500

> second proposal is GSS pre-authentication for Kerberos using an EAP

Ah, thanks for that clarification.

I like the second proposal :) That's because it would produce two
re-usable things: a) a re-usable EAP GSS-API mechanism, b) a more easily
pluggable pre-authentication extension framework for Kerberos.

(a) is a type 2 solution.  (b) is a type 1 solution re-using a type 2
solution.

As you know, while I'm a fan of FAST, I'd rather have gone with a
GSS-API pre-authentication framework for Kerberos.  Of course, by now
FAST is sufficiently well implemented that it's probably easier to plug
into it than it would be to add a GSS-API pre-auth method to Kerberos...

Nico
--

---

From: Eliot Lear <[email-masked]>
Date: Tue, 10 Aug 2010 18:37:49 +0200

Nico, Alper,

Let's distinguish between "options" as in "protocol options" and options
as in overall choices.  I would agree with the statement that protocol
options hinder interoperability.  However, when looking at design
decisions we should at least allow for some flexibility early on in the
process.  That way we can see what people like and then later narrow in
on that set of functionality.  That is, arguably, the standards maturity
process we have in place.

In this instance, I see several possible avenues that could be pursued,
and quite frankly I don't think anyone on this list can argue with a
straight face that they know which model will ultimately be acceptable. 
And so while I don't think we should let 1E+3 flowers bloom, 3 doesn't
seem like such a bad number – at this point.

Eliot

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Aug 2010 12:01:03 -0500

> process we have in place.

I think that's mostly right.  Though it's also true that if we don't
have common required-to-implement mechanisms for the various pluggable
frameworks then we could lack interop anyways, and even if we do have
one or two required-to-implement mechanisms (say, Kerberos and SCRAM)
that could still leave non-interoperable islands using optional
mechanisms.

In practice, I expect most implementations of pluggable frameworks to be
pluggable themselves (either with public interfaces or interfaces
subject to contracts), so I'm not terribly concerned about having a
plethora of authentication mechanisms.

> seem like such a bad number – at this point.

I agree.  Also, note that all the proposals to date leverage existing
standards.  This is a good thing because it will lower the review
burden.

Nico
--

---

From: "Scott Cantor" <[email-masked]>
Date: Tue, 10 Aug 2010 13:06:21 -0400

> plethora of authentication mechanisms.

The feedback I've gotten from people about SASL or GSS is that this is quite untrue in practice, or that the implementations are simply too fragile to count on plugging into them.

It may be that there is work to be done in producing BCP on how to implement them to improve the quality or avoid common assumptions that break pluggability in practice.

-- Scott

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Aug 2010 12:20:37 -0500

On Tue, Aug 10, 2010 at 01:06:21PM -0400, Scott Cantor wrote:
> The feedback I've gotten from people about SASL or GSS is that this is
> quite untrue in practice, or that the implementations are simply too
> fragile to count on plugging into them.

It's true that Solaris' libgss isn't exactly open, though internally it
is.  And MIT krb5's libgss is pluggable, but its interfaces are not
really public (yet; there's a project to make it so).  That's for
starters.  I think the situation is not great, but not far from pretty
good.

> It may be that there is work to be done in producing BCP on how to
> implement them to improve the quality or avoid common assumptions that
> break pluggability in practice.

I agree.

---

From: Luke Howard <[email-masked]>
Date: Tue, 10 Aug 2010 19:22:00 +0200

> starters.  I think the situation is not great, but not far from pretty

Since 1.7, it can load a GSS implementation that exports the GSS-API itself.

Heimdal, too (since which version I'm not sure).

So, it's going to be easy to plug in EAP GSS mechanism. Of course, naming extensions support will require a modern mechglue.

-- Luke

---

From: Sam Hartman <[email-masked]>
Date: Tue, 10 Aug 2010 13:41:54 -0400

So, there's been a very interesting technical discussion of options,
browsers, HTTP negotiate, GSS, Kerberos and the like.

However as I read this discussion, people participating in that
subthread have not actually expressed disagreement with Leif's summary
of what is outstanding.  Also, with the exception of Glen, have there
been any additional requests for changes?

--Sam

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 11 Aug 2010 10:43:22 +0300

> Your interop argument ignores the argument I made earlier, 

That was not my intention. I was just commenting on that one aspect. 
I didn't mean that this is the determining factor. There are multiple other
considerations, like the ones you listed below, and even more. 

> too, that

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 11 Aug 2010 11:08:46 +0300

> been any additional requests for changes?

Not sure if and how this impacts the charter text... but one other thing
that bothers me is about EAP applicability statement change.

Charter text says:

* An update to the EAP applicability statement in RFC 3748 describing
the applicability of EAP to application authentication and placing
appropriate requirements on this new EAP use case

* An update to the EMSK root key applicability statement in RFC 5295

It is obvious that this is needed for the work to progress, but it is not
clear when and how the IETF agreed to do that.

In ICOS BoF and HO(A)KEY WG formation era (and even afterwards), leadership
was shooting down proposals because they were violating this sacred
applicability statement. Now we see there is a totally new work which is
based on updating (not "violating" this time ;) this applicability
statement. And in between these two events is a .... blackout! No proper
discussion on how we went from point A to point inverse-A.

Before people get on the defensive or offensive mode to protect their
"progress", let me restate that I'm not against changing the applicability
statement. But not having an open, informative, and constructive discussion
to take the community from A to inverse-A is plain wrong. Without that
discussion, it looks like the decisions are made randomly. 

Alper

---

From: Sam Hartman <[email-masked]>
Date: Wed, 11 Aug 2010 08:39:07 -0400

>>>>> "Alper" == Alper Yegin <[email-masked]> writes:

    Alper> * An update to the EMSK root key applicability statement in
    Alper> RFC 5295

    Alper> It is obvious that this is needed for the work to progress,
    Alper> but it is not clear when and how the IETF agreed to do that.

The IETF hasn't agreed to do that.  The IETF would agree to do that by
chartering work to do that; we're having the discussion now about
whether that's a good idea.  In particular, if you believe this topic
needs more discussion, you could call that out when the charter goes out
for external review within the IETF.

    Alper> In ICOS BoF and HO(A)KEY WG formation era (and even
    Alper> afterwards), leadership was shooting down proposals because
    Alper> they were violating this sacred applicability statement. 

I think I was most of the leadership doing the shooting down:-) I went
back to review my statements at least as far as they went into the
minutes.  The statements in the minutes  seem correct with what I
remember saying.

In those fora, I never said that you cannot change the applicability
statement.  I outlined some of the things I think you'd need to do in
order to explain it and why I believed that would be hard.

When you brought up this issue a few months ago, I explained in my
response why I believe that this proposal meets the criteria I set out
at ICOS and elsewhere.

I may have made stronger statements at the first ISMS meeting after I
became AD. At least what went into the minutes is consistent with what I
said at ICOS, although it would not surprise me if some of the shorter
statements I made at the mic were over-simplifications of the entire
position and were not entirely consistent.  (I was a new AD at the first
ISMS meeting; I had only become aware of the applicability issue when
briefed by Bernard shortly before the meeting.)

I cannot speak for other IETF leadership. It's my understanding that my
position was consistent with the position of other IETF and EAP
leadership.

I believe that everyone in the leadership who expressed concerns about
applicability of EAP is aware of this proposal.  However, I do agree
with you that this is an important issue and we should make shure we
handle it correctly.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Thu, 12 Aug 2010 18:00:46 -0400

Nico have had this discussion a couple of times.  I thought I'd write it
down so I can remember it in the future.

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> As you know, while I'm a fan of FAST, I'd rather have gone
    Nicolas> with a GSS-API pre-authentication framework for Kerberos.
    Nicolas> Of course, by now FAST is sufficiently well implemented
    Nicolas> that it's probably easier to plug into it than it would be
    Nicolas> to add a GSS-API pre-auth method to Kerberos...

I've been thinking more about FAST vs  GSS preauth.

As best I can tell they fit together nicely.  For example because we
have FAST, we can use anything with channel bindings as a preauth we
don't need to require gss_wrap.

With sufficiently strong gss_wrap style preauth we could have avoided
the need for armor keys.  However you'd need a fairly strong preauth
mechanism for that.  For example, I'm not sure SCRAM wouldn't be
significantly improved by armor.

If you agree that something like armor is necessary, I think GSS preauth
adds very little complexity over FAST.  You probably could have gotten a
simpler encoding if it wasn't for backward compatibility issues.

So, we may not have gone very far afield with FAST.  From an
implementation standpoint I'm definitely happy I was doing FAST not
gss-preauth.  I avoided the complexity of multi-round-trip state
management.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Aug 2010 17:19:20 -0500

> down so I can remember it in the future.

Heh.  Well, let me present my view as well.

> simpler encoding if it wasn't for backward compatibility issues.

The complexity trade-off ultimately would lie in composition.  FAST
provides a mechanism for that, while the GSS-API doesn't-but-could, so
anyone wishing to design my ideal would have to provide for composition.

The fact that FAST got there first is sufficient that without a need for
mechanism composition elsewhere, it won't happen for the GSS-API.  But a
GSS-API pre-auth mechanism that fits into FAST is certainly feasible,
and probably desirable.

Now, back to my world view...

Ideally the KDC protocol would be like any other application protocol
and not directly deal with "reply keys" or any such thing.  That is, a
client would connect[*], use SASL or GSS-API to mutually authenticate,
and use some security layer[**] to do simplified AS exchanges.  Neither
the AS-REQ nor the AS-REP would contain pre-auth data nor "encrypted
parts" (the Ticket itself, would, as usual, have an encrypted part, of
course).  Here SASL/GSS would provide pre-authentication outside the AS
exchange; an additional message pair for negotiating what mechanism to
use would be needed.  Stackable pseudo-mechanisms would have provided
for mechanism composition.

Note that in my ideal world the strength of keys that SCRAM could output
is irrelevant.  What matters is the strength of the keys provided by the
underlying channel in combination with the strength of the channel
binding.  Of course, the strength of SCRAM's channel binding is
consonant with the strength of SCRAM's PRF and per-message tokens.

[*]  UDP could be supported too.
[**] TLS, if bound to from the SASL or GSS authentication, or SASL
     security layers, or GSS-API wrap tokens with confidentiality
     protection.

But... that's not gonna happen.  It could, but it's too late.

The next ideal case is more or less as you described, with either FAST
or stackable GSS-API pseudo-mechanisms providing composition.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 12 Aug 2010 18:28:08 -0400

Thanks for this write up.  I keep forgetting that stackable mechanisms
play into your model.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Aug 2010 17:35:49 -0500

I would also add that PKIX has something similar to the ideal that I
just described for Kerberos: SACRED.  It uses TLS, it uses SASL.  It
doesn't say anything about channel binding, but easily could.

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 13 Aug 2010 12:33:37 +0300

Sam,

> The IETF hasn't agreed to do that.  

My point is, it is not even discussed in this community. Last time it was
discussed, the decision was the opposite of what is written in the charter.
IETF is left at that point.

> The IETF would agree to do that by

Shouldn't this be discussed "internally" with the BoF members, and pulling
in all the other relevant players from EAP/EMU/PANA/AAA community? 

> response why I believe that this proposal meets the criteria I set out

We need to have an elaborative discussion on that. It was not clear to me
and several others when you were opposing that at ICOS, and it is still not
clear why it is OK now. 

> position was consistent with the position of other IETF and EAP
 
Well, you stand out with your strong position at ICOS. 

> applicability of EAP is aware of this proposal. 

Not so, unfortunately. Not that I polled everyone, but I'm aware of one
important case. Jari Arkko learned about this EAP applicability change
proposal from me when I had a chat with him after the BoF was held in
Maastricht. 

Did you make people aware of this proposal on the EAP/EMU/PANA/AAA mailing
lists? 

> However, I do agree

My point is, before this point gets into the charter, it should be
discussed. 

Alper

---

From: Eliot Lear <[email-masked]>
Date: Fri, 13 Aug 2010 11:40:58 +0200

Alper,

> IETF is left at that point.

We are discussing it now.

Eliot