This the second of two messages. TL;DR> section 5.2 is much changed, but I think you'll have to start again.
Section 4 onwards.
4.1 I would love an example that showed the various LMSOR bits in use.
4.2.3, is Identity-Type TLV mandatory.
(in general, I thought TEAPv1 was so underspecified as to be
non-interoperable, but 7170bis. I guess I also thought this was TEAPv2,
but I see that I've mis-understood)
4.2.5: can a NAK TLV be present when there is an Error TLV?
4.2.6: Suggest "Error" TLV be named Notify TLV, since it can contain
successes.
4.2.8: Please mention PEN before Vendor-ID (in the text), and include the TLA
"PEN", as some know it only by the TLA.
I'm not sure why it's restricted to 24-bits, as PENs are not
restricted in that way, and are at least 32-bits.
4.2.10: Not sure I understand when to use this payload.
I would have thought it had something to do with inner methods?
4.2.17: RFC4945, section 6.4 is not a terribly good reference for CSRs.
It's also kinda obscure today. Also that reference says it's BASE64
encoded, which is contradicted by the "PKCS#10 Data" part of that
definition.
RFC5272 section 3.1 would be better.
4.2.19: will need to be updated to normatively reference
draft-ietf-lamps-rfc7030-csrattrs, as RFC7030 Section 4.5 is
ambiguous. You reference it in paragraph two, but the 7030 reference
should be avoided, I think.
Sorry, welcome to cluster C484.
4.2.20: the use of "host/" seems like a heuristic, and I'm unclear if it's a
standard, or a heuristic. Many comments in that section make me feel
even more confused.
It seems that users identity always have @ in them, and hosts do not.
That seems like a good standard to me.
section 5.
5.2: a diagram of how the *MSK feed into each other would be nice.
I don't think that any of the advice if "brief", and rather than try to give
an overview with may or may not (which is no longer brief), why not just into
the meat already.
"The above derivation is not a requirement,"
how can this be? Either it interoperates or not?
Is some of the process a unilateral decision by the server?
> It is RECOMMENDED that for those EAP methods, implementations take the
> simpler approach of ignoring EMSK, and always derive IMSK from MSK. This
> approach is less secure, as IMSK no longer cryptographically binds the
> inner method to the TLS tunnel. A better solution is to suggest that
> deployments of TEAP SHOULD avoid such methods.
this sure feels like sitting on the fence, and I don't think it's useful.
I'm not really convinced that TEAP is not so widely deployed that this
couldn't be more definite. I also wonder again about just calling this TEAPv2.
I'm not qualified (without writing code) to validate the decision tree in
this section.
section 5.2.5 ought to have some tangile examples.
section 7 (Security Considerations):
Thanks for using "On-path (Active) Attack" terminology.
7.5.1: the comments about RSA key transport, aren't those TLS 1.2 and lower
specific?
====
I then reviewed the diff against -19.
I see that there were mostly changes to section 5.2 since -19, which I
complained about above, and I can understand why the text was added, but I
think that it didn't work. I feel very very uncertain that any
implementations can actually interoperate.
I would feel happier if section 5.2 told me how to do it properly.
THEN, it listed the exceptions which are present because of history, and I
could opt to not implement them (at the cost of possibly not interoperating
with all peers/server).
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
