Subject: Re: Working Group Last Call: Stackable Generic Security Service

From: Martin Rex <[email-masked]>
Date: Fri, 3 Nov 2006 19:42:05 +0100 (MET)

Jeffrey Altman wrote:
> 
> Martin:
> 
> Please send this to the list.  Even if it is beyond the last call
> period.   I can't pass a last call without positive feedback and
> so far there has been none during the last call period.

Actually, *I* do not think the stackable pseudo mechanism and the
mechanism inquiry apis should go for standards track due to a
significant lack of peer review, and (independent) implementation
experience.  

Standardizing APIs is extremely difficult, and the IETF has a tradition
to avoid standardizing APIs.  CAT/GSS-API is an exemption, and it took
quite a number of active individuals to agree on a useful spec --
which still contains some grey and/or contentious areas.

In the past there had been at least two approaches to an
authorization API extension for GSS-API (XGSS-API from Bull and GAA),
but CAT did not put either one on the standards track.

Btw. GSS-API v1 wasn't developed within the IETF either, it was
a fairly complete proposal from DEC (desigend for use in DCE).

There is one other API standard that *I* consider a failure, and
that is GSS-API IDUP.  Lack of independet implementation experience
is bad for a standard, and particularly bad for an API standard.

And lack of independent implementation experience has led to a number
of problems in SPKM.  The more than questionable use of real digital
signatures for message integrity protection and the braindead
boasting about "non-repudiation" all over the document (rfc2025)
as well as the non-obvious and actually quite product-specific
enumeration of crypto-algorithms in the QOP parameter are issues
where the problem becomes visible -- for serious reviewers.

-Martin

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 7 Nov 2006 14:44:37 -0600

> significant lack of peer review, and (independent) implementation

That's not a reason to never get to Standards Track.  That may be a
reason to fail the WGLC and have another round some time down the line.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 7 Nov 2006 22:03:08 +0100 (MET)

> reason to fail the WGLC and have another round some time down the line.

Maybe the IESG take on this has *SIGNIFICANTLY* changed in the last
years.  But the message from Jeff Schiller up until 1998 was clear:
The IETF does NOT do APIs, and GSS-API was an exemption, and
on the bottom line it was really expensive (resource-wise in
the IETF), because it took many participants in the security area
so many years to agree on GSS-API v2.

APIs, and especially abstract APIs are quite complex, and the
IETF standardization process requires a lot of effort, unless
you intend to abuse it for pure rubber-stamping.

There is no IETF standard for PAM, and still it is being used
successfully.

I do not see a benefit from having an IETF "proposed standard" tag
on these proposals.  However, the cost to update or fix a
proposed standard will be enormous.

A BCP document on how to use gssapi would provide a much greater benefit
for the community than these documents, and - coincidentally - we already
have that issue on the kitten wg agenda...

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 7 Nov 2006 15:07:09 -0600

> so many years to agree on GSS-API v2.

We've been over this.  We've been chartered.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 7 Nov 2006 15:33:59 -0600

> proposed standard will be enormous.

Now that's another story.  It may be that we should have different
"tags" for APIs than for protocols.  That might have been useful input
to the NEWTRK WG back before it concluded.  As it is these are the RFC
categories we have.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 7 Nov 2006 22:42:43 +0100 (MET)

> We've been over this.  We've been chartered.

Look at the goals and milestones of the charter.
Either a BCP or a GSS-API v2u2 is on top of that list
and should be long done...

I'm not against making your API extenstions an IETF standard eventually,
but I violently opposed to making it an IETF standard in the
very near future without serious peer review and independent
implementation experience.

I'm also ok with having discussion about these APIs on the Kitten
mailing list.   But...

When I joined the IETF in May 1995, CAT was trying to finish GSS-API v2.  
Look at how long it took CAT to finish what is known as rfc2743/2744.

It took me several years to review the specs and come up with
lots of comments, review and implementation experience.

I'm glad that GSS-API v2 wasn't submitted in 1995.

GSS-API v2 would have been significantly less clear and less useful
back then.  Having the documents at draft status for so many years was
good for the quality/usability of the final document (i.e. the standard),
but at the same time it is fairly alien to the IETF process
of creating standards (charter,milestones).

Before we submit new API extensions that include printable input or
outputs, we should make a recommendation/guideline on i18n/l10n
for such printables -- as we all know, that issue is still open
even for the existing GSS-API v2u1 (with the c-bindings spec
recommending the use of iso-latin-1).

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 7 Nov 2006 15:45:47 -0600

> and should be long done...

We do what we can and when we can.  We're volunteers.  If the IESG has a
problem with our milestones they can tell us.

> implementation experience.

We're in the process of obtaining review.

> I'm also ok with having discussion about these APIs on the Kitten

And if you weren't?

Nico
--