Subject: AW: [Simple] Usage of Contact header in PUBLISH for application a uthentication ?

From: Boehmer Bernhard ICM Berlin <[email-masked]>
Date: Wed, 20 Oct 2004 15:15:59 +0200

Hi Aki,
thanks a lot for your reply. 
Your proposal with the Authorization is interesting but I'm not sure 
that it solves the issue generally:
If the application is trusted no digest authentication will take place
and no Authorization can be set. Furthermore, since we (as you mentioned)
intend to use the asserted identity for the user identification, a conflict 
may arise if the content of both headers are different - but I'm not sure 
about this.

Concerning the From header I think that here the user (presentity) URI is
carried here not the application's. 

Therefore, I'm not sure whether your proposal allows the distinction 
between the user and the application acting on behalf of the user. 

		What do you think?
			Regards Bernhard

> -----Ursprüngliche Nachricht-----
> Von: Aki Niemi [mailto:[email-masked]] 
> Gesendet: Mittwoch, 20. Oktober 2004 14:29
> An: ext Boehmer Bernhard ICM Berlin
> Cc: SIMPLE WG
> Betreff: Re: [Simple] Usage of Contact header in PUBLISH for 
> application authentication ?
> 
> 
> Hi Bernhard,
> 
> The From has the same meaning in PUBLISH as in any other request: it
> indicates from whom the request is coming. The Request-URI identifies
> the presentity or resource to which the publication is targeted.
> 
> However, you probably don't want to take the contents of the From at
> face value, but use something like Digest authentication instead. In
> that case the "username" parameter in the Authorization will 
> give you an
> identity. In some systems, the request might already contain 
> an asserted
> identity which you can use as an authenticated identity.
> 
> Contacts have no meaning in publications, and that's why ESCs are
> instructed to ignore them. In the future, someone might come up with a
> valid reason to include one in a PUBLISH request, and that's 
> the reason
> for the "MAY". Even then, the ESC will ignore the Contact, simply
> because the header still won't meaning in the publication 
> context while
> in some other context it might.
> 
> Cheers,
> Aki
> 
> On Wed, 2004-10-20 at 12:08, ext Boehmer Bernhard ICM Berlin wrote:
> > Hi,
> > currently we consider the following scenario for PUBLISH:
> > An application is publishing on behalf of a user (presentity)
> > some presence information. However, the presence server needs
> > a means to authenticate the application server. The idea was 
> > to use the Contact-header for this purpose since the From-header
> > is used to carry the presentity's address. However, the PUBLISH
> > draft says:
> > "The PUBLISH request MAY contain a Contact header field, 
> but including
> >  one in a PUBLISH request has no meaning in the event publication
> >  context and will be ignored by the ESC." 
> > 
> > Later in the draft, ignoring the contact header is even mandated. 
> > Could someone help me with this issue, please?
> > 
> > 			Regards Bernhard
> > ___________________________
> >  Dr. Bernhard Böhmer
> >  Systems Engineering
> >  Siemens AG Communications,
> >  Mobile Networks AS BD C
> >  Siemensdamm 50, Berlin
> >  Fon: +49-30-386-22756
> >  Mobile: +49-178-7700119
> > 
> > _______________________________________________
> > Simple mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/simple
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 20 Oct 2004 23:23:54 -0400

For cases where an application server is publishing, the right thing is 
to use mutual TLS between the application server and the presence 
server. The TLS certificates indicate the identity of the element 
generating the publish. There is no need for p-a-id here; the presence 
document would contain the identity of the presentity. Authorization 
policies in the presence server would typically make sure that the given 
application server can publish state for that presentity.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                        FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com