Hi Alan, EMU WG,
Few questions after the first read-through.
General questions about the doc intent:
1) Is the plan to keep the TEAPv2 draft pointing only to the differences
between the TEAPv1-bis draft and the TEAPv2 definition?
2) If yes, then does it mean we should develop both the TEAPv1 bis and
TEAPv2 drafts in parallel and only the combination of both final RFCs can
define TEAPv2 completely and clearly?
3) Is the intention to recommend that implementers develop both
TEAPv1 bis and TEAPv2 protocols and use them in parallel in their
products?
Technical questions and nits:
4) Section "3.2. Initial-Binding TLV" says:
"The Initial-Binding TLV MUST be included in the first message sent by
each party, and MUST NOT be included in any subseqent messages."
- a typo in the word "subseqent"
- should say be included in the first message sent by each party
**after the TLS tunnel is up**
5) "A party receiving an initial message from the other party MUST check
that the message contains an Initial-Binding TLV. The Initial-
Binding TLV MUST be validated by the receiving **part** before processing
any other field is process."
- should the highlighted word be "party"? "process" --> "processed"
6) The TLV scheme title still says "The Crypto-Binding TLV is defined
as follows:" while this should be "The Initial-Binding TLV is defined
as follows:"
7) "The Version field is a single octet, which is set to the version
of Crypto-Binding TLV the TEAP method is using."
- should it say "of Initial-Binding TLV"?
8) Section "3.4. Intermediate Compound Key Derivations" says:
"define a seed which combines data from the current inner message
along with data from the previous round"
- should says "inner method". There is a mixture of terms "inner
message" and "inner method", both should be explicitly explained,
probably in the beginning of the doc
9) "methed" --> "method"
10) "Where the inner message is not an authentication method, or the inner
authentication method does not derive MSK or EMSK (e.g. Basic-
Password-Resp TLV), then the RoundSeed structure MUST NOT be
modified."
-- what exactly does "MUST NOT be modified" mean? That the
PrevRoundKey should stay as is and MSK and EMSK must stay all zeroes?
This is not exactly clear.
P.S. section "3.5. Methods which do not generate MSK or EMSK"
explains what does the "RoundSeed stay unchanged" mean. So the
explanation from the latter section should go first to avoid
misreading.
11) Section "3.4.2. Key Derivation":
"Each round produces a DerivedKey, which is depends on the RoundSeed
for this round via the following calculation."
- should say "which depends"
12) "The CMK used to calculate the Compound-MAC is defined as" should
go to section "3.4.2. Key Derivation"
13) The Challenge usage in key derivation - for some protocols it's
obvious what is a challenge like EAP-MSCHAPv2. But there could be
protocols where there may be more than one challenge or the term
challenge is ambiguous for them. This may cause different readings by
implementers.
14) " If the inner method does not use a challenge, then the Challenge
field is ignored."
-- ignored means contain 32 octets of zeroes?
15) If the challenge is smaller than 32 octets - should it be padded
to 32 octets with zeroes?
16) Section "3.8. Operation across Multiple Rounds"
"Any party which sends a message in TEAPv2 MUST include a Crypto-
Binding TLV. Any party which receives a message in TEAPv2 MUST
verify that it contains a Crypto-Binding TLV"
- this may be ambiguous, need to define what is a message and when to
send a Crypto-Binding TLV (e.g. by the end of each inner method that
derives MSK or/and EMSK, but not in every message)
17) "It would be possible to redefine the entire contents of the Crypto-
Binding TLV, in the interest of minor optimization. However, re-
using the existing Crypto-Binding TLV format means that there are
minimal changes required to implementations, which is a more useful
property than saving a few octets of data being exchanged."
- the next idea may be specific to my vision of adding TEAPv2 to the
existing TEAPv1 implementation of a typical AAA product: TEAPv1
implementation should stay since some other clients or servers may
still support it. TEAPv2 may use a different codebase so as not to
interfere with the existing TEAPv1 and to decrease the code
complexity. Considering this, changing the format of the
Crypto-Binding TLV sounds reasonable
18) If Initial-Binding TLV is sent in the beginning of TEAP
conversation - as far as I understand, the Crypto-Binding TLV can be
skipped. Wouldn’t this make the protocol vulnerable to certain
attacks?
The further review depends on these initial questions.
Thanks
Oleg
_______________________________________________
Emu mailing list -- [email protected]
To unsubscribe send an email to [email protected]
