> I must confess that on an initial reading of the draft,
I was
> lost on the need for requirements that add certificate
> authentication to SIP. Using TLS, a registrar and a
UAC and
> exchange certificates today and authenticate each
other,
> without resorting to a shared secret, right?
With TLS, the UAC can authenticate its proxy, yes. But the
establishment of a TLS session, even mutually-authenticated
TLS (which is not mandated by RFC3261, by the way) doesn't
inheriently provide authentication of the REGISTER message.
I suppose it _could_, but we don't have that written down
anywhere that I'm aware of.
> I beleive the use case that the author is going for has
to do with
> using the hop-by-hop signaling path through a SIP proxy
mesh to a
> registrar, but being able to exchange certificates
directly
> between the UAC and the registrar.
Yes, exactly.
-d
> As such, the title of the
> draft ought to be reflective of this; something along
the lines
> of "Requirements for direct registrar
authentication in the
> Session Initiation Protocol (SIP) by a User Agent
Client (UAC)".
>
> > - whether the problem space exists but is
something slightly
> > different, and if so what is that problem space?
>
> If the problem space is defined as coming up with
requirements
> for direct registrar authentication in SIP by a UAC
over a
> normal SIP proxy mesh, then that is a reasonable
problem space,
> IMHO.
>
> > - whether there is a more general problem that the
security area
> > should be addressing, rather than the SIP group
addressing something
> > specific?
>
> I beleive that this is fairly specific to SIP, but will
defer
> to the chairs and the rest of the WG.
>
> > - 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?
>
> This draft also talks about interpreting the contents
of the
> certificates (S3, requirement 8). As such, some of the
work Scott
> Lawrence and I have done in domain-certs provides more
> guidelines on this particular aspect. We received good
feedback
> from the pkix WG in Prague when we presented
domain-certs
> there; we are in the process of revising the
domain-certs draft
> to include a discrete set of steps that can be
programmed to
> do certificate validation. We should be sending a
revised
> version of this draft out by tomorrow.
>
> > - 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?
>
> domain-certs, as mentioned above. In addition,
sip-sipsec could
> provide a possible solution set; it appears to fit some
of the
> requirements.
>
> Thanks.
>
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532
(USA)
> Email: vkg {alcatel-lucent.com,bell-labs.com,acm.org}
> WWW: http://www.al
catel-lucent.com/bell-labs
>
>
> _______________________________________________
> Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip
_______________________________________________
Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|
