Subject: [SPKM] [67th IETF] SPKM3 BOF announcement

From: Olga Kornievskaia <[email-masked]>
Date: Tue, 03 Oct 2006 11:33:09 -0400

We would like to announce the following BOF for the 67th IETF meeting.

BOF name:  NFSv4 and Low Infrastructure Public Key Based GSS Security 
Mechanisms
Area: Security Area
Chair: Jeffrey Hutzelman

If this topic is of interest to you please email your questions and 
concerns to the mail list ([email-masked]).

Problem Statement:

    The NFSv4 protocol has a need for low infrastructure PKI based GSS 
security mechanism(s) that provide for the creation of a secure channel 
using mutual authentication where    
    1) both user and server authenticate with public key certificates
    2) server authenticates with public key certificates, and the user 
authenticates with a username and password.
    
Current State:
    RFC3530 "Network File System (NFS) version 4 Protocol" mandates the 
use of RFC2847 "LIPKEY - A Low Infrastructure Public Key Mechanism Using 
SPKM". While RFC2847 fulfills the requirements of the problem
statement, there are areas where RFC2847 is outdated and/or 
underspecified. Futhermore, RFC2847 both replaces and refers to portions 
of RFC2025 "The Simple Public-Key GSS-API Mechanism (SPKM)" and is 
confusing to implementers. None the less, there are two implementations 
(Hummingbird and Linux) based upon RFC2847. 
draft-adamson-rfc2847-bis-01.txt, an update of RFC2847, is intended to 
address RFC2847 shortcomings and provide a complete specification that 
doesn't need [RFC2025] and that replaces [RFC2847]. 

Agenda:
    1) Need for a low infrastructure PK based GSS security mechanism for 
NFSV4
        - what is low infrastructure
        - existing markets
        - current implementations
    2) draft-adamson-rfc2847-bis-01.txt
        - issues brought up by IESG review
            - naming
            - algorithms
            - which diffie-hellman
            - clarify protocol security claims
            - whole document review
        - backwards compatibility with RFC2847 based implementations
    3) moving forward
        - finish draft-adamson-rfc2847-bis-01.txt
            - get draft into shape to submit to for IESG comments.
            - find reviewers
            - explore alternative GSS mechanisms

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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 11 Oct 2006 15:15:47 -0500

>            - explore alternative GSS mechanisms

First, although I prefer, as you know, pursuing "alternative GSS
mechanisms," I think it may well be best to pursue the alternative that
I've proposed (namely, a DTLS-based mechanism) using the individual
submission process, even though that process did not work out for
draft-adamson-rfc2847-bis.  I've not made up my mind as to whether I'd
argue for this or for pursuing a WG work item.

Second, I believe it is possibly -- probably, IMO -- the case that two
of your goals for draft-adamson-rfc2847-bis are mutually exclusive:

 - fixing the problems with RFC2847
 - while retaining backwards compatibility with any deployed
   implementations

It seems to me that establishing whether this is so would be an
essential responsibility of any WG tasked with updating RFC2847 as a
result of this BoF.

Figuring that out would require participants who are intimately familiar
with any such implementations and/or who are very experienced in trying
to interop with them.

It may be that some, but not all problems with RFC2847 can be fixed
while retaining compatibility and that the result would pass WG, IETF
and IESG review.  Then again, it may not be.

For example, draft-adamson-rfc2847-bis extends some ASN.1 types that in
RFC2847 never had extensibility markers -- this could break
interoperability with deployed implementations.  And
draft-adamson-rfc2847-bis specifies use of DER, whereas RFC2847 did not
specify an encoding (one of its many problems), though Certificate may
be encoded in BER...

A more detailed summary of the problems with RFC2847 would be useful,
and, if the BoF succeeds, necessary.  Ditto establishing the desire/need
for backwards compatibility (so we can answer questions like: why not a
new mechanism OID, i.e., SPKM-4?).

Nico
--

---

From: Mike Eisler <[email-masked]>
Date: Wed, 11 Oct 2006 16:04:44 -0700 (PDT)

> argue for this or for pursuing a WG work item.

Not that it has ever stopped IETF before, but
I think a GSS Public Key WG should avoid multiple
solutions to the same problem.

When I wrote RFC 2847, it was with the advice and encouragement
of SPKM-philes, and a belief that this would be relatively
simple to pull off. It turned, at the time, it was relatively
hard, because the SPKM-1 code I thought I had has bit rotted,
and I never had time to untangle the mess.

At this point Andy, Olga, and others say they have interoperating
SPKM-3 implementations. That trumps pursuing alternatives,
however elegant some might see them to be.

An analogy is Kerberos V5. The reason every NFSv4 implementation
today supports Kerberos V5 is not because Kerberos V5 is elegant
(it's really messy) or easy to use or deploy (it's really messy),
but because it turned out to be relatively easy to drop into RPCSEC_GSS
and hence RPC and NFS. A credit to the many people who worked on MIT
Kerberos. So a test for SPKM or any other public key GSS mechanism
is how easy reference (read: free, like beer) code will be to
drop into *every* NFSv4 implementation.

>  - while retaining backwards compatibility with any deployed
[good stuff deleted]

The takeaway for me is that it may take a bunch of time to
sort this out. Again, I favor moving fast, and additionally, I favor
simplicity, especially when it comes to security (that which
is hard to understand is more prone to security holes, which really
need to avoid). So SPKM-5 (reserving even numbers for the evil
timestamped based SPKMs) may be a reasonable way out of this.
Those who still would like a fixed SPKM-3 can figure out how to do
that without holding up SPKM-5. We could even make it an official
work item so that we don't have to confused by personal i-ds.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 11 Oct 2006 18:38:01 -0500

> however elegant some might see them to be.

Your opinion is not entirely at variance with mine.

I took the presence of the above item in the agenda as an
acknowledgement of alternate proposals.  I then expressed my belief that
a DTLS-based mechanism, as I propose, could progress through the
individual submission track.  See below.

I would like to hear from the ADs as to whether the IESG would frown at
two standards-track ways of doing much the same thing, or at one
standards-track and one informational/experimental alternative.

> Kerberos.

What made Kerberos V so successful was, in great part, IMO, the
availability of open source implementations.  The same is true of TLS.
If SPKM-# succeeds it may well turn out to be for similar reasons.

>           So a test for SPKM or any other public key GSS mechanism

As long as SPKM conforms to the GSS-API as an interface then, whatever
SPKM may look like on the wire, it should "drop into" NFSv4 no problem.

Getting new mechanisms to "drop into *every* NFSv4 implementation" is
another story in that this depends on whether NFSv4 implementations are
pluggable or otherwise make it easy to drop in new mechanisms.  But here
I'm picking nits :)

> sort this out.

I've provided plenty of feedback over the last three years, to all
who've asked for it, about what was wrong with the existing SPKM specs
and how to fix it.  It's taken the better part of three years to reach
the point where a BoF was thought necessary...

>                Again, I favor moving fast, and additionally, I favor
> need to avoid).

Given how long it's taken to come to this point it seems like a safe bet
that it will take a long time to finish an update to SPKM-3 or a new
SPKM.

One way to speed things up and simplify things would be to drop interop
with SPKM-3 implementations as a requirement and simply introduce a new
SPKM with a new mechanism OID.

Doing so would allow for a number of simplifications, methinks.  E.g.,
no more CertificatePair.

Note that simplicity from implementors' p.o.v. is important also.  This
is where DTLS comes in: using off-the-shelf DTLS implementations (or
adding DTLS support to existing off-the-shelf TLS implementations) in
order to implement a new SPKM would greatly simplify SPKM for many
implementors.

>                 So SPKM-5 (reserving even numbers for the evil

I agree.

But if the authors would agree to this, then one has to ask: why charter
a WG for SPKM-4/5/whatever?  Why shouldn't the individual submission
process work?

> work item so that we don't have to confused by personal i-ds.

I don't understand the last sentence, but I suspect that I agree :)

Nico
--

---

From: Mike Eisler <[email-masked]>
Date: Thu, 12 Oct 2006 07:11:02 -0700 (PDT)

> a WG for SPKM-4/5/whatever?  Why shouldn't the individual submission

Sam Hartman suggested that the BOF/WG route would be a deterministic 
way to gauge interest in the problem, and thus determine whether 
IETF should spend its cleverness on this issue. The authors agreed. 

> I don't understand the last sentence, but I suspect that I agree :)

What I mean is that the potential WG can add:
  "fix SPKM-3 in a backward compatible way"
as an additional, but lower priority item to its charter, but the
primary goal would be to produce SPKM-5. Once SPKM-5 is done,
those who want to produce a repaired SPKM-3 can continue to do
so. And if there is going to be an effort to fix SPKM-3 I'd
rather the I-Ds were named draft-ietf-spkm-... than
draft-smith-spkm-... because they are harder to find.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Oct 2006 14:35:44 -0500

> draft-smith-spkm-... because they are harder to find.

I'd like to think that the individual submission path should be workable
for security area work.  In particular I think neither an SPKM-4/5 nor a
DTLS based GSS mechanism should require forming a WG.  And if there
isn't sufficient interest in fixing SPKM-3 to form a WG, then nothing
more can be done for it.

At this point we need to hear from the authors and from anyone with
experience with deployed implementations.  We need to hear about the
interop story.

Nico
--

---

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Thu, 12 Oct 2006 15:48:19 -0400

> experience with deployed implementations.  We need to hear about the

At the September 2006 NFSv4 bakeathon here at CITI, the Hummingbird Windows 
NFSv4 client mounted a Linux NFSv4 server using SPKM3 (not spkm3i nor spkm3p). 
Two independent SPKM3 implementations. The full suite of connectathon tests 
passed.
I'd say this shows a lot of interest in SPKM3.

-->Andy

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Oct 2006 16:06:18 -0500

> Two independent SPKM3 implementations. The full suite of connectathon tests 

I assume these don't quite implement RFC2847, but something similar,
yes?  How faithful a description of that protocol is draft-adamson-
rfc2847-bis-01?  Has either implementation been deployed in production
environments?

Nico
--

---

From: Mike Eisler <[email-masked]>
Date: Fri, 13 Oct 2006 12:57:58 -0700 (PDT)

> DTLS based GSS mechanism should require forming a WG.  And if there

Well if sufficient numbers of people want to form a WG, and
if IESG accepts, then whether or not individual submissions work
is irrelevant.

I like WGs because the related I-Ds are collected in one place in
the WG web page and I don't have to organize it: IETF's web masters
organize it. I like WGs because there is a physical forum every
4 months for people to meet, rather than me having to
arrange with the local Holiday Inn for a conference room (it's
worth the $700 or so I pay IETF 3X a year to arrange
all this). Etc.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 13 Oct 2006 15:58:06 -0500

On Fri, Oct 13, 2006 at 12:57:58PM -0700, Mike Eisler wrote:
> > I'd like to think that the individual submission path should be
> > workable for security area work.  In particular I think neither an
> > SPKM-4/5 nor a DTLS based GSS mechanism should require forming a WG.
> > And if there
> 

Yes, BoFs can result in no WG formation, even if there is sufficient
interest.

> worth the $700 or so I pay IETF 3X a year to arrange

WGs aren't free though.  And lack of WGs does not preclude having
working meetings at IETF conferences for disucssing individual
submissions.

One possible addition to the potential charter of an SPKM WG that might
help foster WG formation would be this item from the KITTEN WG charter:

 o Guidelines for GSS-API mechanism designers

Since KITTEN has not gotten around to that item, and since that item
seems rather relevant to this SPKM effort, it makes sense to consider
moving it to any WG that results from this BoF.

Nico
--