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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf