Subject: [BEEPwg] Name check in BEEP TLS

From: Steve Hanna <[email-masked]>
Date: Wed, 25 Aug 2004 12:56:16 -0400

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.

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.

Sorry for the newbie questions. I'm considering
proposing BEEP for a new protocol I'm working on
and want to make sure I understand the security
properties. I'll let you know how it comes out.

Thanks,

Steve Hanna
Funk Software

_______________________________________________
BEEPwg mailing list
[email-masked]
http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg

---

From: Marshall Rose <[email-masked]>
Date: Fri, 27 Aug 2004 09:24:45 +0200

this message got stepped on accidentally... oops!

Begin forwarded message:

> From: "RL 'Bob' Morgan" <[email-masked]>
> Date: August 27, 2004 02:45:34 CEST
> To: Marshall Rose <[email-masked]>
> 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-masked]>
> To: Steve Hanna <[email-masked]>
> Cc: [email-masked]
> 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"
>