Erik Kline <[email protected]> wrote: >> I saw that too when editing, and I thought I changed it already. >> Nope. Fixed now. >> >> Any other thoughts? Forced redirect of TLS by portals usually is >> detected by a certificate validation failure. But, in 8995, we defer >> the verification until later on. What I want to know is whether this >> explanation is reasonably communicated. >>
> What are the security implications of any information leaked via the
> voucher request? Is it just "oooh look, here's a node that's doing
> BRSKI" or is there some more traceable client information in there?
The voucher request is signed by the IDevID, which is included.
Both the VR and the IDevID will have device identifying information.
(They have to). Whether that's *PII* or "just" device identity depends upon
the device.
However, at the point when this occurs, it hasn't really been personalized yet.
So the negative situation of disclosing the voucher request to the on-path
activev attacker (aka captive portal admin) is probably relative severe from
a privacy point of view. Thus, getting this concern clearly articulated is
important.
> (Clearly I haven't gone looking to refresh any ANIMA/BRSKI
> semantics/mechanics).
The 4m screen cast got good reviews from other ADs.
Hoping Disney will pick it up for the Skeleton Crew 2nd season/Donald-Duck
cross-over.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Captive-portals mailing list -- [email protected] To unsubscribe send an email to [email protected]
