Hit send too quickly.
An alternate solution here is to just use TLS between the client and its
next SIP hop. If thats the registrar, great, we're done. If its an
intermediate proxy - then the intermediate proxy has basically done the
authentication and can use RFC 4474 or 3325 to convey that authenticated
identity to the registrar.
If you are worried about cases of local proxies in untrusted networks,
separate from your home proxy - well there are tons of problems in that
model and its something we need to discourage.
If you step back a moment - it seems wrong to me that we are going to
have our clients implement TLS, which supports client authentication
with certificates, but then tell them that they need to ALSO implement
something entirely different to accomplish the same thing.
-Jonathan R.
Jonathan Rosenberg wrote:
Well, I'm going to be contrarian here. I'm not convinced that this is
needed.
I think certificate based authentication is a great idea. However, I am
not sure I understand why TLS is not an appropriate solution.
DRAGE, Keith (Keith) wrote:
(As WG chair)
http://www.ietf.org/internet-drafts/draft-dotson-sip-certificate-auth-03
.txt
Describes a set of requirements for:
This document defines requirements for adding certificate
authentication to the Session Initiation Protocol (SIP). This
document is being presented with the intention of providing clear
requirements to any potential solutions specifying certificate
authentication within SIP networks. Supporting certificate
authentication in SIP would provide strong authentication and
increase the types of possible deployment scenarios.
(Before we go any further, please forget all about the solutions
document - that comes later and we are not dealing with it now)
We need to decide whether there is support for a body of work in this
area, and therefore whether we should charter some requirements work in
the SIP WG.
(Because this is security related we have agreed that SIP does the
requirements drafting and not SIPPING)
So can I hear opinions of the WG on:
- whether this represents a problem space that the working group
should draft requirements on?
- whether the problem space exists but is something slightly
different, and if so what is that problem space?
- whether there is a more general problem that the security area
should be addressing, rather than the SIP group addressing something
specific?
- based on your answers to the first three questions, whether this
draft is essentially in the right direction to be adopted as the WG
draft assuming we create the charter item, or whether we need to seek
some other input draft?
- and finally, whether (assuming we go ahead with this work) there
is any work in any other IETF WG that we should take account of?
Regards
Keith
Regards
Keith
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
--
Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
Cisco Fellow Parsippany, NJ 07054-2711
Cisco Systems
[EMAIL PROTECTED] FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.cisco.com
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
