>>>>> "Stephen" == Stephen Farrell <[email protected]> writes:
Stephen> (1) Am I reading this right? 4.2.2 says: "The EAP MSK is
Stephen> transported between the IdP and the RP over the AAA
Stephen> infrastructure, for example through RADIUS headers. This
Stephen> is a particularly important privacy consideration, as any
Stephen> AAA Proxy that has access to the EAP MSK is able to decrypt
Stephen> and eavesdrop on any traffic encrypted using that EAP MSK
Stephen> (i.e. all communications between the Client and IdP)." Does
Stephen> that mean that if a client authenticates with a password
Stephen> say, then that password could be read after the fact by any
Stephen> RP or AAA proxy involved in the transaction. Wouldn't that
Stephen> be unacceptable, if e.g. the equivalent of web-bugs or
Stephen> trackers could be inserted into a UI so as to get
Stephen> first-shot before a user has authenticated? And that seems
Stephen> to contradict step 7 in 1.4 unless those messages also go
Stephen> via the RP, which is not shown in the diagram in 1.4. What
Stephen> am I missing?
Fortunately, I think you're reading this slightly wrong.
Learning the MSK is not sufficient to snoop on traffic between the
peer/client and IDP.
Only on traffic between the peer/client AND RP.
The issue is that if the peer-client use the MSK to encrypt traffic say
using the GSS per-message services or the GSS PRF, that an attacker who
learns the MSK can decrypt that traffic. They should not (and with EAP
methods that are typically used are believed to be unable to) learn keys
needed to observe the authentication conversation between peer/client
and IDP.
honestly, I consider proxies being able to observe session traffic to be
quite bad from a perpass standpoint, thus my interest in adding DH
between client/peer and RP.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
