Hi Sam, On 12/16/2013 04:48 PM, Sam Hartman wrote: >>>>>> "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.
So when the text says "(i.e. all communications between the Client and IdP)" I don't get what that means. Is it just a typo maybe? S. > > _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
