Re: [Dime] [DIME] Comments about AVP for crypto key transport draft
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Dime] [DIME] Comments about AVP for crypto key transport draft
Hi Qin,
> [Qin]: The problem is when the NAS recieves MSK or rMSK, the NAS can not judge
> whether MSK or rMSK is validated. because the NAS has no root key. Only intermediary node and End-Server
> can tell whether MSK or rMSK is validated. What the NAS can do is format checking, e.g.,
> whether the lifetime of MSK is more than 0 or something else.
>
> [Qin]: It may introduce security threat. Because the authenticator has no
> root keys and can not judge the key is validated. Only local server can validate
> the rMSK based on DSRK.
>
> [Qin]: In implicit bootstrapping aren't both the MSK & rMSK sent in the same
> message? How can you tell the difference between them at the NAS?
>
Implicit bootstrapping is not an ERP exchange, therefore it does cannot
derive an rMSK (no SEQ available). Only MSK is sent in that case.
In my understanding explicit bootstrapping is an ERP exchange between
peer and home server; therefore the rMSK is derived from the rRK key
(although I could not find this clarified in RFC5296 after a quick
search). At the same time, the rDSRK is derived to be provided to local
server. There is no relationship between this rMSK and rDSRK, so the
local server would not be able to check the validity of the key material
further than the NAS.
Anyway, these details are far away from the initial discussion about
what is best choice for distinguishing between two different keys:
- an enumerated AVP "Key-Type" inside the grouped AVP, or
- a different grouped AVP code for each key types.
Except for the different parsing and different message size, those two
possibilities are equivalent in terms of functionality it offers...
Best regards,
Sebastien.
--
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.