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
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
