Subject: [Sip] comments on draft-ietf-sip-identity

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 06 Mar 2005 14:30:52 -0500

Enclosed are comments on draft-ietf-sip-identity-04. I did a very 
detailed review, and so many of my comments are nits. To spare everyone 
the trouble of reading the comments to look for more interesting issues 
(and I assume almost no one will), here are some of the more important 
comments:

* display name handling

I'm concerned that the treatment of the From display name. The current 
spec allows an authentication service to verify it (at MAY strength), 
and it can reject it if it doesnt like it. But, there is no signature 
that covers it, and no way for a verifier to know if the authentication 
service allowed it to pass.

I'm worried that, although we believe that the URI is the important form 
of identity to worry about, real people will be more concerned with the 
display name. The mechanism may, as a result, be extremely misleading, 
because users are still free to completely spoof the display name.

I'd like to consider adding the display name to the signature, under the 
constraints that, if done, it require the domain to tell the client the 
display names it can insert, so as to avoid all of these equivalence 
nightmares for internationalized names.

* authorization policies - how to know if a domain is supporting this 
mechanism?

The spec recommends that a verifier look at the domain name, and if it 
knows that it supports this mechanism, reject the request if its not in 
use. However, this is very difficult to know ahead of time, requiring 
exactly the same kind of closed network topology that we are trying to 
get away from in this draft.

As such, I think some kind of companion technique for "checking if 
domain X is using sip-identity" is needed. It need not be defined here, 
but it seems crucial to successful deployment of this.

* privacy interactions

There are some interactions with SIP privacy (rfc3323) that require more 
consideration. Specifically, 3323 recommends that endpoints use a From 
field of anonymous.invalid, which would render this specification 
impotent when used in conjunction with rfc3323. I think a revision of 
rfc3323 is probably needed, but this spec has to make sure that the 
avenue is open for that.

* sips URI scheme meaning just TLS

The spec proposes the usage of a sips URI in the Identity-Info header 
field to mean that a client should open a TLS connection to the server, 
get its certs, and close the connection. I think this is a misuse of the 
SIPS URI.

* why sips/https - not just http? and mandatory scheme

The Identity-Info header field is supposed to contain only a sips or 
https URI, not just vanilla HTTP. What is the problem in using just 
vanilla HTTP? Also, I think we need to defined a baseline 
mandatory-to-impelement scheme.

* applicability to register

The draft specifies that the mechanism isn't applicable to REGISTER, but 
I think there are valid use cases and I dont see why it doesnt work.

* tel URI handling

Some strange behavior is specified for the cases where the From header 
field has a tel URI. I think that is really at odds with a domain-based 
identity assertion scheme, and I think that requests with tel URI in the 
 From shouldn't be signed by an identity service without a proper way to 
determine the owning domain for that number.

* only domain certs, or user certs?

The text is somewhat unclear on whether it is possible for this 
mechanism to be used when endpoints act as the authentication service, 
using a cert that contains a user identity (i.e., a subjectAltName of 
user@domain). Is this allowed or not?

* unclear subordination rules

The verifier rules around namespace subordination are a bit unclear. We 
should make strong statements about what a verifier should do under 
various cases, and still leave the door open for other techniques in the 
future.

Detailed comments:

abstract

> This document recommends practices and conventions for
>    identifying end users in SIP messages, and proposes a way to
>    distribute cryptographically-secure authenticated identities.

this kind of statement makes it sound like is more of a BCP. I'd prefer 
something like, "This document defines a mechanism for securely 
identifying originators of SIP messages. It does so by defining two new 
SIP header fields, Identity, for conveying a signature used for 
validating the identity, and Identity-Info, for conveying a reference to 
the certificate of the signer."

>  However, few SIP user agents today support the end-user certificates
>    necessary to authenticate themselves via TLS or S/MIME, and

this statement is misleading. It makes it sound like, if UA's would just 
support TLS, then we wouldn't need this spec. Its not true on two counts 
- an increasing number of UA are supporting TLS, and TLS doesn't suffice 
here due to its use as a hop-by-hop mechanism.

> An example
>    of the former would be a presence service that compares the identity
>    of potential subscribers to a whitelist before determining whether it
>    should begin sending presence notifications.  In both of these cases,

I think this is better phrased as, "...whether it should accept or 
reject the subscription".

> All RFC3261-compliant SIP user agents support a means of
>    authenticating themselves to a SIP registrar, commonly with a shared
>    secret; Digest authentication, which MUST be supported by SIP user
>    agents, is typically used for this purpose. 

this sentence is awkward. Suggest, "All RFC3261 compliant user agents 
support digest, which utilizes a shared secret, as a means for 
authenticating themselves to a SIP registrar."

> The address-of-record URI used for registration is also the URI with
>    which a UA commonly populates the From header of requests in order to

terminology nit: "header" refers to top part of a sip message that 
contains all of the header fields. The term you want her eis "From 
header field".

> The identity
>    mechanism specified in this document derives from the following
>    principle: if you can prove you are eligible to register in a domain
>    under a particular address-of-record, you are proving that you are
>    capable of legitimately receiving requests for that
>    address-of-record, and accordingly, when you place that
>    address-of-record in the From header field of a SIP request other
>    than a registration (like an INVITE), you are providing a 'return
>    address' where you can legitimately be reached.  In other words, if

this definition would appear to rule out inclusion of anonymous 
identities in the From header field. This mistake is made many times 
through the document; I don't point it out again, but please look for 
all instances.

> Accordingly, this document specifies a means of sharing a
>    cryptographic assurance of end-user SIP identity in an interdomain
>    context which is based on the concept of an 'authentication service'
>    and a new SIP header, the Identity header.  Note that the scope of

Though the mechanism here is targeted for inter-domain, it also works 
intra-domain (and quite well, in fact). I think you need to highlight this.

> This specification allows either a user agent or a proxy server to
>    act as an authentication service.  To maximize end-to-end security,

I dont think the term "authentication service" has yet been defined in 
this doc. You should do that before using the term.

>  o  The mechanism must allow a UAC to provide a strong cryptographic
>       identity assurance in a request that can be verified by a proxy
>       server or UAS.

The UAC isn't providing the assurance at all. Suggest, "The mechanism 
must provide a strong cryptographic identity assurance in a request that 
can be verified by a proxy server or UAS".

>  The mechanism must be capable of protecting the integrity of SIP
>       message bodies (to ensure that media offers and answers are linked
>       to the signaling identity).

I don't think this is a requirement in and of itself; I believe it is a 
derived requirement from the previous replay-prevention requirement. 
That is, integrity of the body is ESSENTIAL for replay protection. It is 
not present as a feature of the identity mechanism just because we threw 
it in as a requirement.

> It must be possible, in cases where a request has been retargeted
>       to a different AoR than the one designated in the To header field,
>       for the UAC to ascertain the AoR to which the request has been
>       sent.

I think you mean UAS.

> The authentication service authenticates Alice (possibly by sending a
>    Digest authentication challenge) and validates that she is authorized
>    to populate the value of the From header field (which may be Alice's
>    AoR, or it may be some other value that the policy of the proxy

of course alice is authorized to populate the value of the header field; 
it has to be done by a UAC. I think you mean, "... and validates that 
she is authorized to assert the identity that has been placed into the 
 From header field. This value may be Alice's AOR, or it may be....."

> When Bob's domain receives the request, it verifies the signature
>    provided in the Identity header, and thus can authenticate that the
>    domain indicated by the host portion of the AoR in the From header
>    field authenticated the user, and permitted them to assert that From
>    header field value.

I think "authenticate" is the wrong verb in the beginning of this 
sentence. I think "verify" is more correct. Also, this verification can 
also be done by the UAS, you should mention that.

>  instantiated by a proxy server or a user agent.  Any entity that
>    instantiates the authentication service role MUST possess the private
>    key of a domain certificate, and MUST be capable of authenticating
>    one or more SIP users that can register in that domain.  Commonly,

Hmm, doesnt this definition rule out a user with a certificate for 
themselvs (I.e., one for which the subjectAltName is 
"sip:[email-masked]") from being an authentication service? I 
thought we were going to still allow this.

> Then it computes a signature
>    over the canonical form of several headers and all the bodies, and
>    inserts this signature into the message.

all the bodies? There is only one body of a SIP message. It may be 
multipart, and thus there are many body parts.

> The authentication service authenticates the identity of the message
>    sender and validates that the identity given in the message can
>    legitimately be asserted by the sender.  Then it computes a signature
>    over the canonical form of several headers and all the bodies, and
>    inserts this signature into the message.

I dont like this paragraph, actually, because its sort of an informative 
overwiew paragraph, and the actual steps are in fact spelled out in 
detail in the sections that follow. You need to be very precise about 
the sequencing of steps and what happens at each step. I suggest 
breaking this seciton into sub-sections or numbered steps for each 
activity, much like the way proxy behavior is specified in rfc3261.

>   o  If the authentication service is instantiated by a SIP
>       intermediary (proxy server), it may challenge the request with a
>       407 response code using the Digest authentication scheme (or
>       viewing a Proxy-Authentication header sent in the request which
>       was sent in anticipation of a challenge using cached credentials,
>       as described in RFC 3261 Section 22.3).
>    o  If the authentication service is instantiated by a SIP user agent,
>       a user agent can be said to authenticate its user on the grounds
>       that the user can provision the user agent with the private key of
>       the domain, or by preferably by providing a password that unlocks
>       said private key.

please add:

* If the authentication service is instantiated by a SIP intermediary 
(proxy server), and that proxy server is maintaining a TLS connection 
with the client, over which the proxy had previously authenticated 
itself using digest authentication, the identity value obtained from 
that previous authentication step can be reused without an additional 
digest challenge.

>  Authorization of the use of a particular username in the From header
>    field is a matter of local policy for the authorization service, one

what is an authorization service? I think you mean authentication service.

> n this latter case, a domain might
>    maintain a mapping between the values in the 'username' parameter of
>    Proxy-Authorization and a set of one or more SIP URIs which might
>    legitimately be asserted for that 'username'.

you are sort of dancing around this, but I think its OK to explicitly 
say that, for example, the username can correspond to the private 
identity as defined in 3gpp, in which case the From field can contain 
any of the public identities associated with that private identity.

>   exceptions to such policies might arise for cases like anonymity; if
>    the AoR asserted in the From header field is anonymous (per RFC3323
>    [3]), then the proxy should authenticate that the user is a valid
>    user in the domain and insert the signature over the From header
>    field as usual.

That isn't going to work. RFC3323 recommends the usage of 
anonymous.invalid as the domain in the From field. Doing so is 
incompatible with this specification. I think there are many remedies to 
that, and the full treatment of privacy with usage of sip-identity is 
probably outside of the scope of this draft (indeed, I believe a 
revision of rfc3323 is probably in order). However, you should at least 
point out that any anonmyziation mechanism that works with sip-identity 
requires the domain in the From field to be a domain over which the 
authentication service is responsible.

> As such, authentication services MAY check the display-name as well,
>    and compare it to a list of acceptable display-names that may be used
>    by the sender; 

You need to say a little more here, I think, given the IDN nightmare 
that could arise here. In particular, I think you need to say that such 
policies will really only work in conjunction with systems in which 
valid display name values are provided to users ahead of time, such that 
the authentication service can validate the display name using basic 
case sensitive string comparisons, and do not require any kind of 
canonicalization of the display name. This means that a user can't just 
"type in" their display name.

I think you may need to at least mention the amazingly hard question of 
how a domain can figure out that sip:[email-masked] is actually 
"Alice Smith".

> if the display-name does not meet policy constraints,
>    the authentication service MUST return a 403 'Inappropriate
>    Display-Name' response code. 

Hmm. Not sure this is the right response code. This is a situation in 
which the UA may be able to automatically retry the request (for 
example, omitting a display name). 403 is appropriate when their is no 
remedy that can easily be taken. I fear a new response code is needed.

> Third, the authentication service MUST form the identity signature
>    and add an Identity header to the request containing this signature.

you need to say how this is done here, else point to the section that 
defines how the signature is computed.

> Retargeting, the alteration by intermediaries of the Request-URI of a
>    SIP request, can cause a few wrinkles for the Identity mechanism when
>    it is applied to requests sent in the backwards direction within a
>    dialog.  

this definition isn't right. You don't ever get retargeting for 
mid-dialog requests since the r-uri corresponds to the remote target of 
the dialog, and is unchagned the whole way through. I think what you 
mean is:

"Retargeting is defined as the alteration of the Request-URI by 
intermediaries to point to another URI that corresponds to a user that 
cannot authenticate itself with the identity present in the request URI. 
By this definition, retargeting excludes translation of the request URI 
to a registered contact of an endpoint that has authenticated itself as 
that user. When a dialog-forming request is retargeted, it introduces a 
few wrinkles for requests sent in the reverse direction of that dialog."

> When a request is retargeted, it may reach a SIP endpoint whose user
>    is not identified by the URI designated in the To header field value.
>    The value in the To header field of a dialog-forming request is used
>    as the From header field of requests sent in the backwards direction
> 
> 
> 
> Peterson & Jennings     Expires August 17, 2005                 [Page 9]
> 
> Internet-Draft                SIP Identity                 February 2005
> 
> 
>    during the dialog, and is accordingly the header that would be signed
>    by an authentication service for requests sent in the backwards
>    direction.

actually, there are many nasty cases where the To field will contain an 
identity that doesnt correspond to a valid identity of the recipient. 
Consider, for example, cases where users dial a phone number, and the To 
header field contains the dial sequence as a SIP URI in the domain of 
the originator. Or its an alias of some sort. Or a tel URI. You should 
mention these cases.

> The mechanism in this draft cannot aid in determining whether or not
>    the unanticipated party is an appropriate target of this request and,
>    accordingly, solving this problem is outside the scope of this draft.
>    If, however, it were possible for the sender of the dialog-forming
>    request to anticipate that retargeting had occurred, and to gain some
>    kind of assurance of the new target of the request before any
>    requests in the backwards direction were received, this would open up
>    some new approaches to authorization policy.

this paragraph seems repetitive with the previous paragraph.

> Ultimately, the
>    authentication service provides an Identity header for requests in
>    the backwards dialog when the user is authorized to assert the
>    identity given in the From header field, and if they are not, an
>    Identity header is not provided.

well, thats interesting. It means that the draft DOES provide a 
connected identity service - but only if the connected identity 
corresponds to the user you called in some cases.

> If an Identity header is not
>    present in a request, and one is required by local policy (for
>    example, based on a global policy, a per-sending-domain policy, or a
>    per-sending-user policy), then a 428 'Use Identity Header' response
>    MUST be sent.

There is of course a gaping hole here, which is how a receiving domain 
is supposed to know that a domain is using this draft, and thus should 
expect the Identity header field in requests from that domain. One 
answer is if it is known due to trusted peer relationships. Of course, 
in such a case, you probably don't need sip-identity and P-A-ID would do.

I'd love to see a draft developed that allows for a domain to be able to 
determine whether the originating domain is using this mechanism. Some 
kind of dialback approach or a DNS solution could work. I think its 
arguably out of scope for this draft, but this draft needs to 
acknowledge this issue and perhaps state that such a mechanism is 
outside the scope of this document.

I'd also say that a global policy on this is probably incredibly 
unrealistic. Given it doesnt exist today, how could you phase in this 
mechanism with such a policy? If its an appropriate policy only once 
this has been ubiquitously deployed, that should be stated.

>  If the URI scheme in the Identity-Info
>    header cannot be dereferenced, then a 436 'Bad Identity-Info'
>    response MUST be returned.  

I think you need to specify a baseline mandatory-to-implement scheme 
here. Suggest http.

> Subsequently, the recipient MUST verify the signature in the Identity
>    header, and compare the identity of the signer (the subjectAltName of
>    the certificate) with the domain portion of the URI in the From
>    header field of the request as described in Section 14.

again, this rules out per-user certificates.

> If a verifier determines that the signature on the message does not
>    correspond to the text of the message, then a 428 'Invalid Identity

what do you mean by "text of the message"? I would normally think this 
means the content in a text/plain body, such as one used in MESSAGE. But 
i dont think thats what you mean.

>  This mechanism can be applied opportunistically to existing SIP
>    deployments; accordingly, it requires no change to SIP user agent
>    behavior in order for it to be effective.  However, because this
>    mechanism does not provide integrity protection between the UAC and
>    the authentication service, a UAC SHOULD implement some means of
>    providing this integrity.  

there are lots of security features needed in sip not provided by this 
spec. Why is integrity between UAC and auth service important? I think 
its to protect the From from modification by attackers? Need to point 
that out if thats what you mean.

> When a UAC sends a request, it MUST accurately populate the header
>    field that asserts its identity (for a SIP request, this is the From
>    header field). 

this text seems like it alludes to the fact that there might be other 
ways for conveying its identity. I dont think so. So you should be more 
crisp here - "When a UAC sends a request, it MUST accurately populate 
the From header field with a value corresponding to an identity that it 
believes it is authorized to claim. This value MAY include a display 
name, in such a case where the domain administrator has provided the UAC 
with display names it considers valid."

> In a request it MUST set the URI portion of its From
>    header to match a SIP, SIPS or TEL URI AoR under which the UAC can
>    register (including anonymous URIs, as described in RFC 3323 [3]).

except that RFC 3261 requires the To header field of a REGISTEr to be 
only a sip or sip URI, not a tel URI.

> The UAC MUST also be capable of sending requests, including mid-call
>    requests, through an 'outbound' proxy (the authentication service).
>    The best way to accomplish this is using pre-loaded Route headers and
>    loose routing.  UAC implementations MUST provide a way of
>    provisioning pre-loaded Route headers in order for this mechanism to
>    work for mid-call requests in the backwards direction of a dialog.

Hmm. Normally, pre-loaded route headers (including ones learned through 
Service Route) do not apply to mid-dialog requests. The route set 
learned from the dialog is used instead of any such route set (though I 
think this may not be spelled out clearly anywhere).

I'm not sure this requirement is needed anyway, since text above says 
that we aren't really providing identity for mid-dialog requests in the 
reverse direction anyway. I would remove it, and merely mention that a 
consequence is that if an authentication service is not on the path of 
the original request, identity for mid-dialog requests in the reverse 
direction won't be provided.

> Identity-Info header contains a URI from which its certificate can be
>    acquired.  Details are provided in section Section 10.

double section

> Even if a proxy server does not
>    act as an authentication service, it MAY verify the existence of an
>    Identity before it makes a forwarding decision for a request.

verifying existence is not interesting. Its validating the identity.

> For the purposes of identifying mid-dialog requests, proxy servers
>    that instantiate the authentication service role MUST Record-Route
>    themselves in dialog-forming requests.

per above, I don't think this is needed.

> This document specifies two new SIP headers: Identity and
>    Identity-Info.  Each of these headers can appear only once in a SIP
>    message.
> 
>    Identity = "Identity" HCOLON signed-identity-digest
>    signed-identity-digest = LDQUOT 32LHEX RDQUOT
> 
>    Identity-Info = "Identity-Info" HCOLON ident-info
>    ident-info = LAQUOT absoluteURI RAQUOT

this is pedantic - but the first paragraph should state that the two 
which follow define the grammar for these new header fields.

I'll note that you have not allowed for extensibility in either header 
field. I think that is a mistake. You should use standard extension 
header syntax and allow header field parameters for both.

>  o  The AoR of the UA sending the message, or the 'identity field'.
>       For a request, this is the addr-spec from the From header field.

you should point out that this includes any header field parameters.

> The Date header field, with exactly one space each for each SP and
>       the weekday and month items case set as shown in BNF in 3261.  The

careful here! The case as described in the BNF is case insensitive, 
since the BNF rules specify that quoted strings imply case insensitive. 
I think you mean to say, "RFC 3261 specifies that the BNF for weekday 
and month are a choice amongst a set of tokens. The RFC 2234 rules for 
the BNF specify that tokens are case sensitive. However, when used to 
construct the canonical string defined here, the first letter of each 
week and month MUST be capitalized, and the remaining two letter must be 
lowercase. This matches the capitalization provided in the definition of 
each token."

You need to be this pedantic in order to get this to interoperate...

> headers from the message-body, but does include everything that
>       follows that CRLF.  If the message has no body, then message-body
>       will be empty, and the final colon will not be followed by any
>       additional characters.

I suggest you explicitly talk about multipart and what it means for this.

> signing this string with sha1WithRSAEncryption as described in RFC
>    3370 and base64 encode the results as specified in RFC 3548.  Put the
>    result in the Identity header.

you need normative refs for these two. Hmm. 3548 is informational....

>  The Identity-Info header MUST contain either an HTTPS URI or a SIPS
>    URI. 

why secure? Why does it matter?

> If it is a SIPS URI, then the
>    authentication service intends for a user agent that wishes to fetch
>    the certificate to form a TLS connection to that URI, acquire the
>    certificate during normal TLS negotiation, and close the connection.

blech! That is a definite misuse of the sips URI scheme.

> The
>    REGISTER method uses Contact header fields in very unusual ways that
>    complicate its applicability to this mechanism.  Accordingly, the
>    Identity and Identity-Info header MUST NOT appear in REGISTER or
>    CANCEL.

I agree with CANCEL, but not REGISTER.

Usage of this with register is essential for 3gpp-like architectures 
where there is a separation between the proxy instantiating the 
authentication servce (a p-cscf or similar edge proxy) and the registrar 
(s-cscf or home proxy). We've recognized these kinds of architectures in 
many places. In that case, we need a way to convey the authenticated 
identity to the registrar from the edge proxy. This mechanism seems fine 
for that, in that the registrar is just a UAS that just happens to lie 
in the same domain as the requestor.

I don't understand why this cannot work for REGISTER.

> The examples in this section illustrate the use of the Identity
>    header in the context of a SIP transaction.  Implementations MUST
>    verify their compliance with these examples, i.e.:

this is a bizarre normative requirement; normally we specify behaviors 
of software/hardware against behaviors, not behaviors of people against 
our specs. If so, we could do things like, "All implementors MUST read 
this specification, and MUST mail a check for US $100 to Mr. Jon 
Peterson...." ;)

> 11.  Compliance Tests and Examples

these example messages don't contain some of the things we are 
recommending people to use, like Accept, Allow, and the various 
capability declaration headers.

Also it would be great if there were ladder diagrams for these flows.

> described in this document.  Telephone numbers commonly appear in the
>    username portion of a SIP URI (e.g.,
>    'sip:[email-masked]').

this is missing the ;user=phone

> That username conforms to
>    the syntax of the TEL URI scheme (RFC2806bis [9]).

now published as rfc 3966.

> Implementations that intend to send their requests
>    through an authentication service MUST put telephone numbers in the
>    From header field into SIP or SIPS URIs, if possible.

"if possible" makes this a SHOULD.

> Verifiers SHOULD NOT accept
> 
> 
> 
> Peterson & Jennings     Expires August 17, 2005                [Page 21]
> 
> Internet-Draft                SIP Identity                 February 2005
> 
> 
>    signatures over From header TEL URIs in the absence of some
>    pre-provisioned relationship with the signing domain that authorizes
>    this usage of TEL URIs.

wow. I don't like this at all. It seems to invalidate many of the 
assumptions on which this specification is built. I would rather not 
provide identity for these use cases.

> 13.  Privacy Considerations
> 
>    The identity mechanism presented in this draft is compatible with the
>    standard SIP practices for privacy described in RFC3323 [3].

not really; per above 3323 says to use anonymous.invalid.

>  Note, however, that an authentication service must possess a
>    certificate corresponding to the host portion of the addr-spec of the
>    From header field of any request that it signs; accordingly, using
>    domains like 'invalid.net' may not be possible for privacy services
>    that also act as authentication services. 

may not be possible? Won't be possible.

> 13.  Privacy Considerations

what I think is missing from the discussion here, as it relates to 
rfc3323, is that this specification does not actually introduce ANY 
information into the sip message that has privacy implications, beyond 
what is already in the message. It adds a signature and a URL for 
fetching a cert; the domain presumably matches the one in the From 
field, so no additional identifying information is provided.

> This document describes a mechanism which provides a signature over
>    the Contact, Date, Call-ID, CSeq, To, and From header fields of SIP
>    messages.

actually, just requests. The spec sometimes uses "messages" and 
sometimes "requests". It should consistently use requests.

> request targets.  Providing the To header field in the Identity
>    signature servers two purposes: first,

serves

> Implementations MUST also record Call-IDs received in
>    valid requests containing an Identity header, and MUST remember those
>    Call-IDs for at least the duration of a single Date interval (i.e.
>    commonly 3600 seconds).  

while reasonable, this also belongs up above in a section on UA 
behavior, as it is likely to be lost in the security considerations 
section. Generally, I like these sections to summarize stuff that has 
already been stated previously in specification.

> Accordingly, if an Identity header is
>    replayed within the Date interval, receivers will recognize that it
>    is invalid because of a Call-ID duplication; 

you need to have a normative statement somewhere above that says that a 
verifier should check the date and the callid, and specify exactly what 
to check.

Also, is the requirement for validation one for a UA or any verifier? 
That is, should a proxy be doing the call-id checks? That could be a lot 
of data.

> The Contact header field is included to tie the Identity header to a
>    particular device instance that generated the request. 

s/device/user agent

> However, a
>    signature over the topmost Via header does not prevent attacks of
>    this nature, since the attacker could leave the topmost Via intact
>    and merely insert a new Via header field directly after it, which
>    would cause responses to be routed to the attacker's host "on their
>    way" to the valid host, which has exactly the same end result.

not quite; remember that normal sip routing rules cause the response to 
go to the source IP of the request AND the port present in the Via 
header field. This is unless rport is in use, in which case the response 
goes back to the source port too.

The implication is that it is not possible to redirect responses unless 
the Via is modified, unless the originator supported rport. It still 
doesn't make sense to include Via, for other reasons you describe.

> sending user agent and the authentication service, it could not
>    prevent an attacker from adding a Via hop after the authentication
> 
>    service, and accordingly pre-empting responses.  It is necessary for
>    the proper operation of SIP for subsequent intermediaries to be

extra line inserted

> While there are conceivably attacks that an
>    adversary could mount against SIP systems that rely too heavily on
>    the display-name in their user interface, this argues for intelligent
>    interface design, not changes to the protocol.

I am concerned that in a universe of aol style identifiers like 
[email-masked], the display name plays a larger role in identification 
than you might think. Certainly it is extensively used in the pstn. I 
think we should consider further whether or not the signature should 
include the display name.

> However, it is likely that applications building on
>    the Identity header could leverage this integrity protection,
>    especially body integrity, to provide further security services.

I don't know what this means exactly.

> Therefore, it is RECOMMENDED that UASs receiving signed requests
>    notify end users if there is ANY discrepancy between the
>    subjectAltName of the signer's certificate and the host portion of
>    the identity within the From header field.  If the domain name in the
>    subject of the certificate is subordinate t

what happens if the verifier is a proxy? No notification is possible.

Also, to be frank, I think that normative statements around UI behaviors 
are a mistake. The average user will NOT know what to do in these cases. 
IETF folks are profoundly unqualified to figure out what is the right UI 
interaction.

> If the domain name in the
>    subject of the certificate is subordinate to the domain name in the
>    identity URI, then verifiers may consider this a minor discrepancy.

this is a relatively weak statement. What is the normative guidance here 
on subordination? I think it needs to be clearly addressed, and it 
should be addressed in the section on verifiers.

> provided by a certificate authority operated by the federation.  It
>    is STRONGLY RECOMMENDED that self-signed domain certificates should

while I agree with the sentiment, usage of capitalized STRONGLY is not 
defined in RFC 2119.

> Header Name: Identity
>       Compact Form: y
>       Header Name: Identity-Info
>       Compact Form: (none)

according to sip-guidelines, compact forms should be requested for both, 
since both are mandatory (or are we out of letters?)

> It is used when a verifier received a SIP request that
>    lacks an Identity header as a response indicating that the request
>    should be re-sent with an Identity header. 

this sentence is awkward

-- 
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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip