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

[Peter Saint-Andre <[e-mail]>]

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

-- 
Peter Saint-Andre
https://stpeter.im/