Subject: [abfab] WGLC draft-ietf-abfab-gss-eap-06

From: Leif Johansson <[email-masked]>
Date: Tue, 17 Apr 2012 11:43:23 +0200

The chairs believe that draft-ietf-abfab-gss-eap-06 is ready for
last call and that any remaining issues including the nits already
identified by Sam can be addressed during the WGLC.

This is then a WGLC on draft-ietf-abfab-gss-eap-06. Please provide
comments and/or feedback by 1/5 2012.

	Best R
	Leif & Klaas

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 17 Apr 2012 12:24:21 +0200

I believe it would be prudent to ask for review by the Kitten WG since
the document specify new GSS-API and SASL mechanisms.  Perhaps the
Kerberos WG too, since it creates an IANA registry for RFC 4121 token
types.

Section 5.8 contains:

   Open issue: handling of lifetime parameters.

Should that be removed, or is there something to address here?

The phrase "Section 7.1" in this sentence looks a bit weird:

   If the null name type or the GSS_EAP_NT_EAP_NAMe (OID
   1.3.6.1.5.5.15.2.1) Section 7.1 is imported, then the string
   representation above should be directly imported.

Note also the typo; s/EAP_NAMe/EAP_NAME/.

"GSS_Init_sec_context" and "GSS_Accept_sec_context" has inconsistent
capitalization throughout the document.

Section 7.5: the SASL mechanism name "eap-aes128-cts-hmac-sha1-96" does
not follow the syntax rules in RFC 4422:

      sasl-mech    = 1*20mech-char
      mech-char    = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE
      ; mech-char is restricted to A-Z (uppercase only), 0-9, -, and _
      ; from ASCII character set.

You may want to register the GS2 -PLUS variant name as well, compare RFC
5802.  One approach is to register a SASL family that would encode all
EAP variants implicitly, i.e., by registering EAP-* where * is derived
as B32(DER(OID)) from the EAP-GSS mechanism OID.  Compare how RFC 5801
derives SASL mechanism names.  You could also fall back on the GS2-X
construction that is already specified.

Are there implementations of the mechanism that can be tested remotely
on an interop-server?

/Simon

---

From: Sam Hartman <[email-masked]>
Date: Tue, 17 Apr 2012 15:41:36 -0400

Hi.
I think the review in kitten and krb-wg would be good.

I think we already have a consensus that we want to register short SASL
names; I will look into doing it like scram. Sorry for the sloppiness
there.

It also looks like we left lifetimes as a todo.

Whatever we do I think it should be a MAY or SHOULD implement, not a
MUSt implement.
It looks like on the acceptor we could support RADIUS session time
limits (if there is such a thing). On the initiator there's not much we
can do.

Thanks for your review!

---

From: Leif Johansson <[email-masked]>
Date: Tue, 17 Apr 2012 21:57:50 +0200

On 04/17/2012 09:41 PM, Sam Hartman wrote:
> Hi. I think the review in kitten and krb-wg would be good.
> 

So the chairs would be happy to go and ask for that review unless
anyone else comes forward and volunteers as couriers :-)

	Cheers Leif