Re: [secdir] [xmpp] SecDir review of draft-ietf-xmpp-3920bis-17

[Yaron Sheffer <[e-mail]>]

Hi Peter,

yes, these seem reasonable. Is there a "converse" to the rewriting of 
the client's From header before forwarding to other servers, i.e. is 
there a server-side check on stanza From headers received from other 
servers?

Thanks,
	Yaron

On 11/03/2010 11:41 PM, Peter Saint-Andre wrote:
> Hi Yaron, following up our discusion, here is proposed text for the
> conformance features you suggested...
>
> On 11/1/10 2:19 PM, Peter Saint-Andre wrote:
>> On 11/1/10 3:25 AM, Yaron Sheffer wrote:
>>
>>> On 10/30/2010 07:05 AM, Peter Saint-Andre wrote:
>>>>
>>>> On 10/28/10 4:28 AM, Yaron Sheffer wrote:
>>>>
>>>>> - 15: I would expect one or a few features around validation of
>>>>> identities at the various layers, since we're spending much of the
>>>>> document on this issue. "tls-certs" is an important piece of that, but
>>>>> not the whole thing.
>>>>
>>>> I agree with you that the layering topics are important here. Do you
>>>> have specific suggestions?
>>>>
>>> - Server side: correlate cert-asserted client ID with "from".
>>> - Server: correlate "from" on stream to identity as authenticated by SASL.
>>> - Server: rewrite "from" on stanza to authenticated ID.
>>> - Client side: correlate cert-asserted server ID with "from".
>>> - Client: correlate "from" on stream to identity as authenticated by TLS
>>> certs and/or SASL.
>
> I think we can combine client and server validation into two features
> (instead of four), one for TLS and one for SASL.
>
> The TLS feature would be:
>
>     Feature:  tls-correlate
>     Description:  When validating a certificate presented by a stream
>        peer during TLS negotiation, correlate the validated identity with
>        the 'from' address (if any) of the stream header it received from
>        the peer.
>     Section:  Section 13.7.2
>     Roles:  Client SHOULD, Server SHOULD.
>
> As a target for that pointer, I think we need to add the following
> paragraph to the end of Section 13.7.2 ("Certificate Validation"):
>
>     Once the identity of the stream peer has been validated, the
>     validating entity SHOULD also correlate the validated identity with
>     the 'from' address (if any; see Section 4.6.1) of the stream header
>     it received from the peer.  If the two identities do not match, the
>     validating entity SHOULD terminate the connection attempt.
>
> The SASL feature would be:
>
>     Feature:  sasl-correlate
>     Description:  When authenticating a stream peer using SASL, correlate
>        the authentication identifier resulting from SASL negotiation with
>        the 'from' address (if any) of the stream header it received from
>        the peer.
>     Section:  Section 6.4.6
>     Roles:  Client N/A, Server SHOULD.
>
> As a target for that pointer, I think we need to add the following
> paragraph to the beginning of Section 6.4.6 ("SASL Success"):
>
>     Before considering the SASL handshake to be a success, the receiving
>     entity SHOULD correlate the authentication identity resulting from
>     the SASL negotiation with the 'from' address (if any; see
>     Section 4.6.1) of the stream header it received from the initiating
>     entity.  If the two identities do not match, the receiving entity
>     SHOULD terminate the connection attempt.
>
> Finally, we need one more feature, for server stamping of client 'from'
> addresses:
>
>     Feature:  stanza-attribute-from-stamp
>     Description:  Stamp or rewrite the 'from' address of all stanzas
>        received from connected clients.
>     Section:  Section 8.1.2.1
>     Roles:  Client N/A, Server MUST.
>
> Let me know if those seem reasonable.
>
> Peter
>