RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)

From: Thomson, Martin ^lt;Martin.Thomson@andrew.com>
Date: Thu Feb 15 2007 - 00:22:36 EST

I'm sorry. I seem to have misplaced my magic wand.

I can recommend a solution for DHCP - since a new option is required to carry the signature, let's just make that option carry a PIDF-LO. It's less fussy that way and we avoid any concerns about the format.

As for the others, they aren't IETF protocols, but I'm sure it wont be too hard to convince the other SDOs to change:

LLDP-MED already has an option to carry a PIDF-LO, so no problem there. Just deprecate the RFC3825 format.

SUPL uses 3GPP GAD, so you'd be better off talking to 3GPP. Perhaps we can also come to some arrangement with 3GPP so that we can squeeze a signature into a few protocols. After all 23.271 specifies mobile-originated location requests. That's a minor change to... (lemme see)... MAP, RRC, RRLP, BSSMAP-LE, and PCAP spring to mind.

As for SUPL - you probably want to get MLP as well, but that's XML so maybe there is something we can do (I'll let you talk OMA into changing).

Oh yeah, and OMA want to include civic addresses - we can give them those for free while we're at it.

Enjoy,
Martin

> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> Sent: Thursday, 15 February 2007 3:37 PM
> To: Thomson, Martin; Dawson, Martin; 'Henning Schulzrinne'
> Cc: geopriv@ietf.org
> Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-
> LOdigitalsignatures)
>
> As long as it works with L7 LCP, DHCP and LLDP-MED and maybe SUPL, great.
>
> Brian
>
> > -----Original Message-----
> > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]
> > Sent: Wednesday, February 14, 2007 11:34 PM
> > To: Brian Rosen; Dawson, Martin; Henning Schulzrinne
> > Cc: geopriv@ietf.org
> > Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-
> > LOdigitalsignatures)
> >
> > I'm pleased. It seems that we are making progress towards a solution.
> >
> > I have been working for a while on a draft that outlines, in more
> detail,
> > the "why" and "how" of applying digital signatures to location objects.
> > It is based largely on section 8 of l7-lcp-ps rather than my old draft.
> > After a few weeks, it's largely complete - it just needs the trimmings:
> > schema, examples, IANA, some final touches, reorganization and a harsh
> > edit. I'll publish before the -00 deadline as a discussion piece.
> >
> > Regards,
> > Martin
> >
> > > -----Original Message-----
> > > From: Brian Rosen [mailto:br@brianrosen.net]
> > > Sent: Thursday, 15 February 2007 3:21 PM
> > > To: Dawson, Martin; 'Henning Schulzrinne'
> > > Cc: geopriv@ietf.org
> > > Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-
> > > LOdigitalsignatures)
> > >
> > > We think the cert problem is tractable.
> > >
> > > The local PSAP, for example, can deal with its local access network
> > > providers. The PSAP can sign the certs of the local providers. There
> > are
> > > not very many of them, and they are all local (at least in the sense
> > that
> > > there are local people, and local equipment).
> > >
> > > Then the PSAP can check the certs.
> > >
> > > We actually think we can have a real PKI for PSAPs, but just doing
> local
> > > certification is feasible.
> > >
> > > Enterprise is a little more difficult, just because of the numbers. I
> > > think
> > > we can handle that too, because we have a set of issues to deal with
> > that
> > > involves enterprises, and we can get the cert in the mix.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> > > > Sent: Wednesday, February 14, 2007 4:44 PM
> > > > To: Henning Schulzrinne
> > > > Cc: geopriv@ietf.org
> > > > Subject: RE: [Geopriv] WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-
> > > > LOdigitalsignatures)
> > > >
> > > > Yes, I think the broader Internet issue of cert security etc. needs
> to
> > > > be solved in the broader context. Location needs to ride on whatever
> > the
> > > > best state of the art is.
> > > >
> > > > I actually just think of the identity as a unique random number that
> > the
> > > > LIS generates. That, coupled, with the LIS identity makes for a
> > globally
> > > > unique identity that the location recipient can be comfortable with
> > > > using to applying policy against without any user or network
> specific
> > > > information having had to be conveyed.
> > > >
> > > > Cheers,
> > > > Martin
> > > >
> > > > -----Original Message-----
> > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > > > Sent: Thursday, 15 February 2007 8:37 AM
> > > > To: Dawson, Martin
> > > > Cc: jerome.grenier@bell.ca; geopriv@ietf.org
> > > > Subject: Re: [Geopriv] WGLC
> > > > ondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)
> > > >
> > > > I think we're in general agreement. I'm not sure what you mean
> > > > precisely by "access network identify", but this doesn't have to be
> a
> > > > NAS identity, say. It could just as well be a (public) IP address or
> > > > any other token, so that it works for non-authenticated users, as
> > > > long as these cannot spoof a large number of network addresses or
> > > > similar. In some cases, a combination of a physical network port and
> > > > identity may well be appropriate. If the PSAP gets 100 calls from
> > > > "socket 17 at columbia.edu" or "AP 42 at the Anytown Starbucks",
> even
> > > > if they all have different MAC addresses, something is likely fishy.
> > > >
> > > > The remaining hard problem of not having trustworthy certifiers
> > > > remains and could make any such mechanisms moot. (Although today's
> > > > email-return-routability CA mechanism makes it expensive to get
> > > > dozens of certs, although fishers seem to pay for those with stolen
> > > > credit card numbers...)
> > > >
> > > > On Feb 14, 2007, at 4:27 PM, Dawson, Martin wrote:
> > > >
> > > > > This is true, I agree.
> > > > >
> > > > > I think what we want to do is to make it as difficult as possible
> > > > > to do that more than once for a given client identity in the
> > > > > network. This, as nearly as possible, would make it the equivalent
> > > > > of Trudy setting her phone to forward to 911. Eve could only make
> > > > > one call at a time through it. Trudy could have two phones and
> etc.
> > > > > but, really, Eve is constrained to requiring her partner to have
> > > > > the equivalent amount of "presence" in the network as she is
> > > > > attempting to use.
> > > > >
> > > > >> From a PSAP perspective, it is a concern that each call is a,
> > > > >> presumably, bogus one but they are not particularly concerned as
> > > > >> to whether it is Eve that is effectively dialling them rather
> than
> > > > >> Trudy.
> > > > >
> > > > > So - the important thing is for the PIDF-LO to be associated with
> a
> > > > > single apparent identity in the access network so that appropriate
> > > > > policy can be applied against getting two calls arriving with this
> > > > > identity. Note that this "identity" is the anonymous appearance of
> > > > > a particular IP host in the network and nothing to do with
> > > > > conveying an individual's real world identity or voice service
> > > > > subscriber identity. The latter is not the access network's job.
> > > > > Requirement 3 is about providing a mechanism for the access
> network
> > > > > to convey this "access network identity" as part of the location
> > > > > information.
> > > > >
> > > > > Cheers,
> > > > > Martin
> > > >
> > > >
> > > > --------------------------------------------------------------------
> --
> > --
> > > --
> > > > ----------------------
> > > > This message is for the designated recipient only and may
> > > > contain privileged, proprietary, or otherwise private information.
> > > > If you have received it in error, please notify the sender
> > > > immediately and delete the original. Any unauthorized use of
> > > > this email is prohibited.
> > > > --------------------------------------------------------------------
> --
> > --
> > > --
> > > > ----------------------
> > > > [mf2]
> > > >
> > > >
> > > > _______________________________________________
> > > > Geopriv mailing list
> > > > Geopriv@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/geopriv
> > >
> > >
> > > _______________________________________________
> > > Geopriv mailing list
> > > Geopriv@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/geopriv
> >
> > ------------------------------------------------------------------------
> --
> > ----------------------
> > This message is for the designated recipient only and may
> > contain privileged, proprietary, or otherwise private information.
> > If you have received it in error, please notify the sender
> > immediately and delete the original. Any unauthorized use of
> > this email is prohibited.
> > ------------------------------------------------------------------------
> --
> > ----------------------
> > [mf2]
>

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Wed, 14 Feb 2007 23:22:36 -0600

This archive was generated by hypermail 2.1.8 : Thu Feb 15 2007 - 00:22:36 EST