Re: [abfab] AD review of draft-ietf-abfab-arch-09

[Sam Hartman <[e-mail]>]

>>>>> "Stephen" == Stephen Farrell <[e-mail]> 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.