> For example, consider using a USRK to secure HTTP. If your access > provider did this to deliver firmware updates to your handset, this > might be reasonable, but if amazon.com required it for authentication, > this would be unreasonable. I do not believe that either application is reasonable. The EAP peer has no reason to trust a third party to update its firmware merely because they can prove possession of a key derived from the EMSK. Given that any proxy on the path could obtain such a key, this kind of architecture provides such flimsy security that it needs to be restricted to use in protecting a commodity (e.g. network access) that has virtually no value. Existing firmware distribution models provide much higher levels of trust, typically providing verification of the identity of the third party, as well as demonstration that they are authorized to provide firmware updates, and proof that the firmware itself has not been tampered with. _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf