Fwd: Name check in BEEP TLS

this message got stepped on accidentally... oops!

Begin forwarded message:

> From: "RL 'Bob' Morgan" <[email protected]>
> Date: August 27, 2004 02:45:34 CEST
> To: Marshall Rose <[email protected]>
> Subject: Re: [BEEPwg] Name check in BEEP TLS
>
>
>
> ---------- Forwarded message ----------
> Date: Thu, 26 Aug 2004 10:56:24 -0700 (PDT)
> From: RL 'Bob' Morgan <[email protected]>
> To: Steve Hanna <[email protected]>
> Cc: [email protected]
> Subject: Re: [BEEPwg] Name check in BEEP TLS
>
>
> On Wed, 25 Aug 2004, Steve Hanna wrote:
>
>> In looking through the description of the TLS transport security 
>> profile
>> in RFC 3080, I expected to see some information about how the server
>> certificates are used to perform server authentication. Something like
>> section 3.1 of RFC 2818. Otherwise, you just have an armor-plated pipe
>> to an unknown party.
>
> Indeed it's the case that each protocol profiled for TLS (eg
> IMAP/POP/LDAP) has to specify this "server identity check" in its own 
> way,
> eg section 3.6 of RFC 2830 for LDAP.  Note that the profile for SMTP's 
> use
> of TLS (RFC 3207) only says:
>
>    -  A SMTP client would probably only want to authenticate an SMTP
>       server whose server certificate has a domain name that is the
>       domain name that the client thought it was connecting to.
>
> (hmm, is that a SHOULD or a MAY?  8^) due to the nature of SMTP
> deployment.
>
> I have to agree that RFC 3080 doesn't seem to cover this issue (I 
> really
> thought it did, hmm).  It might be claimed that BEEP, as a generic
> protocol kernel, shouldn't be prescriptive about the name check, 
> leaving
> it to BEEP-using protocol specs to do this.  It might even be claimed 
> that
> this paragraph of section 4:
>
>    Note that regardless of transport security and user authentication,
>    authorization is an internal matter for each BEEP peer.  As such,
>    each peer may choose to restrict the operations it allows based on
>    the authentication credentials provided (i.e., unauthorized
>    operations might be rejected with error code 530).
>
> makes this point, since this name check could be characterized as an
> authorization step ("is the presenter of this cert allowed to act as 
> the
> desired server name").  But it would be appropriate for this issue to 
> be
> mentioned in Security Considerations at the least.
>
> So it would be appropriate in a new BEEP-using scheme to specify this
> check in a way appropriate to that scheme.  I suppose the question is
> whether BEEP implementations provide any hooks to let relying code do 
> the
> check.
>
>> Is the idea to use SASL after the TLS transport is up to allow the two
>> peers to authenticate each other? If so, I hope that authentication is
>> tied to the TLS session in some way so you know there's no man in the
>> middle.
>
> A SASL mechanism may or may not provide server authentication.  There 
> is
> no connection in SASL to the server authentication that is done at the 
> TLS
> layer (for client authentication the connection is made via the SASL
> EXTERNAL mechanism).  The TLS-layer server name check is the key thing 
> in
> preventing MITM.
>
>  - RL "Bob"
>