[no subject]

["Doug Ewell" <dewell at roadrunner.com>]

That's indeed an incomplete sentence.=20


> =20
>    It is necessary to use authorization policies to limit the
>    unauthorized distribution of location information.  The security
>    requirements which are created based on [10] are inline=20
> with threats
>    which appear in the relationship with disclosure of location
>    information as described in [33].  PIDF-LO [21] proposes S/MIME to
>    protect the Location Object against modifications.  S/SIME=20
> relies on
>    public key cryptography which raises performance,=20
> deployment and size
>    considerations.  Encryption would require that the local AAA server
>    or the NAS knows the recipient's public key (e.g., the=20
> public key of
>    the home AAA server).
> =20
> So are we saying that the location information attributes can=20
> be encrypted
> in some cases, so that the privacy concerns are not=20
> applicable? But the
> attributes don't support this, right?
> =20
>    Knowing the final recipient of the location
>    information is in many cases difficult for RADIUS entities.
> =20
> Specifically, RADIUS clients only deal with RADIUS servers=20
> that are one
> hop away.


Maybe the discussion about PIDF-LO S/MIME protection is a bit out of
context.=20


Here is the updated document:=20
http://www.tschofenig.com/svn/draft-ietf-geopriv-radius-lo/draft-ietf-ge
opriv-radius-lo-11.txt


Ciao
Hannes

PS: I merged the civic and the geospatial location information attribute
into a single attribute since I noticed a problem in the extensibility
mechanism. One would have to define new attributes with new location
formats even though location information is opaque for the RADIUS
protocol.=20

> =20
> =20
> =20
> _______________________________________________
> Ietf mailing list
> Ietf at ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> =20

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf