... do the responsible thing, which would be to clearly define the
applicability, along with providing an interoperable means of defining
the key hierarchy for those usages that want to/can use it.
This is all I'm suggesting we do. I think we should add text to the
document that gives guidance on the types of usages for which a USRK
would be appropriate. Usages should be for functions related to the
access network to which you are connecting, and for functions where it
is reasonable for your access network to have an interest in authorization.
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. Even if amazon.com had an agreement with
your provider to obtain a USRK for your session, that's not the kind of
thing for which your provider should be the authorization authority.
t. charles clancy, ph.d. eng.umd.edu/~tcc
electrical & computer engineering, university of maryland
IETF mailing list