On Nov 9, 2025, at 9:25 AM, Oleg Pekar <[email protected]> wrote:
> 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?
Largely, yes. There is no need to repeat much of the text in 7170bis which
talks about packet format, TLV format, etc.
> 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?
7170bis has been submitted to the IESG for publication. The only changes
should be editorial, which means that there's no more technical development to
be done on it.
> 3) Is the intention to recommend that implementers develop both
> TEAPv1 bis and TEAPv2 protocols and use them in parallel in their
> products?
The intention of 7170bis is to document what implementors have done.
I would very much hope that no one makes further changes to their TEAPv1
implementation. The functionally documented in Section 5 of 7170bis is what
works, and pretty much nothing else will work.
The bottom of Section 5 says:
Any changes to the TEAP protocol can then be done in a future TEAPv2
specification.
Perhaps it should also say that implementers should not develop their TEAPv1
functionality any more. If they do, there is no guarantee that the changes
will be compatible with anyone else's TEAPv1 code.
> Technical questions and nits:
> 4) Section "3.2. Initial-Binding TLV" says:
...
> 5) "A party receiving an initial message from the other party MUST check
...
> 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."
I'll fix all of those points, thanks.
> 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
The intent was to use the same "inner method" terminology as 7170bis. But
given some recent discussions, I suspect much of the text around IMCK, etc.
will be going away.
So I'll omit responding to review comments for that text.
> ...
> 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
OK.
> 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?
One attack is where an attacker terminates the TLS tunnel, and forwards the
inner data to someone else. The Initial-Binding TLV is sufficient to protect
from this attack.
The next question is whether we want the inner methods bound to the tunnel,
and whether we want the outer MSK bound to the inner MSKs.
If we don't bind the inner methods to the tunnel, then a trusted
authentication server can forward the inner methods to another authentication
server. Whether this is an attack or a design requirement is perhaps a subject
for discussion.
If we do bind the inner methods to the tunnel, then we will need the full
Crypto-Binding TLV, perhaps in a TEAPv2 format. But we then have the problem
of what to do when the inner method does not derive an MSK. e.g. Basic
Password, PKCS#7, etc.
i.e. if we try to bind the inner methods to the tunnel, then that binding
can't be done for some inner methods. Which makes the binding work only
sometimes. That limitation suggests to me that we should just give up on
binding the inner method to the tunnel.
We then need to decide if it's OK for a trusted authentication server to
forward inner methods somewhere else. This would be a subject for more
discussion in EMU.
Alan DeKok.
_______________________________________________
Emu mailing list -- [email protected]
To unsubscribe send an email to [email protected]
