Subject: [secdir] review of draft-hollenbeck-rfc4933bis-02

From: Catherine Meadows <[email-masked]>
Date: Mon, 6 Jul 2009 11:53:19 -0400

I have reviewed this document as part of the security
directorate's ongoing effort to review all IETF documents
being processed by the IESG.
These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs
should treat these comments just like any other last call comments.

Quote from last review:

"The draft updates RFC 4933, the EPP Contacts Mapping spec.
The updates listed are relatively minor - updates to
references and a few minor updates to text."

Version 1 has reviewed recently (June 10, by Sandy Murphy) and the  
author already
made the changes that were agreed upon in following discussion.

Everything mostly looks OK to me, but there is one issue that never  
got completely resolved
as far as I can tell from what I saw online.  This is the question of  
channel binding issues as described
RFC 4953.  I'm having trouble accessing that document right now, but  
apparently the issue is that
low-level authentication mechanisms will not provide any distinction  
between channels at a higher level.
This can make it possible for someone with access to the  
authentication mechanisms to spoof different channels.
In particular, if the EPP authorization information is protected with  
lower-level authentication mechanisms this could
be the case.  Unless there is good reason to believe that this sort of  
attack is impossible (in which case it would
be a good idea to say why) it might be good
that

>> Both client and server MUST ensure that authorization
>>    information is stored and exchanged with high-grade encryption
>>    mechanisms to provide privacy services.

be changed to

Both client and server MUST ensure that authorization
    information is stored and exchanged with high-grade encryption
    mechanisms to provide privacy and authentication services at the  
appropriate level
of granularity.

Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: [email-masked]

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 7 Jul 2009 15:52:03 -0400

I made this statement in my response to Sandy:
 
"I would need more specific information to know if there's something to
be done with this comment. Reliance on security mechanisms provided at
the transport layer has been part of this specification since day one. I
am not aware of any implementation issues."
 
There was no follow-up, so I remain a little unsure of how to address
the comment.  Similarly, I need a clarification to know if the text
change suggested below is best made in 4933bis.
 
There's a separate document that addresses EPP transport over TCP.  If
the channel binding issue is primarily an issue with TCP (is it?), I'd
prefer to address it in the TCP mapping document (4934bis).  If it's
more focused on the application-layer exchange of authorization
information I'm OK with making the text change suggested below in
4933bis.  I should note that the same text exists in 4931bis so I'd need
to change it there as well.
 
So - where is the most appropriate place to add text?
 
-Scott-

________________________________

	From: Catherine Meadows [mailto:[email-masked]] 
	Sent: Monday, July 06, 2009 11:53 AM
	To: [email-masked]; [email-masked]; Hollenbeck, Scott
	Cc: Catherine Meadows
	Subject: review of draft-hollenbeck-rfc4933bis-02

	should treat these comments just like any other last call
comments. 

	Quote from last review:

	Version 1 has reviewed recently (June 10, by Sandy Murphy) and
the author already
	made the changes that were agreed upon in following discussion.

	Everything mostly looks OK to me, but there is one issue that
never got completely resolved
	as far as I can tell from what I saw online.  This is the
question of channel binding issues as described
	RFC 4953.  I'm having trouble accessing that document right now,
but apparently the issue is that
	low-level authentication mechanisms will not provide any
distinction between channels at a higher level.
	This can make it possible for someone with access to the
authentication mechanisms to spoof different channels.
	In particular, if the EPP authorization information is protected
with lower-level authentication mechanisms this could
	be the case.  Unless there is good reason to believe that this
sort of attack is impossible (in which case it would
	be a good idea to say why) it might be good 
	that 

			Both client and server MUST ensure that
authorization

			   information is stored and exchanged with
high-grade encryption

	be changed to

	Both client and server MUST ensure that authorization
	   information is stored and exchanged with high-grade
encryption
	   mechanisms to provide privacy and authentication services at
the appropriate level
	of granularity.

	Catherine Meadows

---

From: Catherine Meadows <[email-masked]>
Date: Wed, 8 Jul 2009 12:02:10 -0400

My apologies!  I should have read RFC 4953 first.  The I-D tracker is  
still giving me a 404,
but I was able to find it on the tcpm WG website.

What RFC 4953 discusses is a specific vulnerability in TCP, which  
involves the fact that reset sequence (RST) numbers can cycle through  
quickly in large windows,
and they make the protocol vulnerable to spurious resets from  
attackers in that case.  So this really is a TCP issue, and I agree  
that the TCP mapping document in the appropriate place for
this if there is an issue, which would depend on the window size.

My apologies again for typing without reading first, and for  
introducing such a red herring.  My interpretation of "channel binding  
attack" in this context was no where near the mark.
I now no longer believe that there are any further changes to be made  
to this document.

Also, somebody needs to fix the ID tracker.  My attempt to find 4934  
wound up in a 404 too.

Cathy

On Jul 7, 2009, at 3:52 PM, Hollenbeck, Scott wrote:

> "I would need more specific information to know if there's something  
> to be done with this comment. Reliance on security mechanisms  
> provided at the transport layer has been part of this specification  
> since day one. I am not aware of any implementation issues."
>
> There was no follow-up, so I remain a little unsure of how to  
> address the comment.  Similarly, I need a clarification to know if  
> the text change suggested below is best made in 4933bis.
>
> There's a separate document that addresses EPP transport over TCP.   
> If the channel binding issue is primarily an issue with TCP (is  
> it?), I'd prefer to address it in the TCP mapping document  
> (4934bis).  If it's more focused on the application-layer exchange  
> of authorization information I'm OK with making the text change  
> suggested below in 4933bis.  I should note that the same text exists  
> in 4931bis so I'd need to change it there as well.
>
> as far as I can tell from what I saw online.  This is the question  
> of channel binding issues as described
> be the case.  Unless there is good reason to believe that this sort  
> of attack is impossible (in which case it would

Catherine Meadows

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 8 Jul 2009 15:30:19 -0400

No problem here - thanks for the clarification!
 
-Scott-

	From: Catherine Meadows [mailto:[email-masked]] 
	Sent: Wednesday, July 08, 2009 12:02 PM
	To: Hollenbeck, Scott
	Cc: Catherine Meadows; [email-masked]; [email-masked]
	Subject: Re: review of draft-hollenbeck-rfc4933bis-02

	My apologies!  I should have read RFC 4953 first.  The I-D
tracker is still giving me a 404, 
	but I was able to find it on the tcpm WG website.

	What RFC 4953 discusses is a specific vulnerability in TCP,
which involves the fact that reset sequence (RST) numbers can cycle
through quickly in large windows,
	and they make the protocol vulnerable to spurious resets from
attackers in that case.  So this really is a TCP issue, and I agree that
the TCP mapping document in the appropriate place for
	this if there is an issue, which would depend on the window
size. 

	My apologies again for typing without reading first, and for
introducing such a red herring.  My interpretation of "channel binding
attack" in this context was no where near the mark.
	I now no longer believe that there are any further changes to be
made to this document.

	Also, somebody needs to fix the ID tracker.  My attempt to find
4934 wound up in a 404 too.

	Cathy

		 
		"I would need more specific information to know if
there's something to be done with this comment. Reliance on security
mechanisms provided at the transport layer has been part of this
specification since day one. I am not aware of any implementation
issues."
		 
		There was no follow-up, so I remain a little unsure of
how to address the comment.  Similarly, I need a clarification to know
if the text change suggested below is best made in 4933bis.
		 
		There's a separate document that addresses EPP transport
over TCP.  If the channel binding issue is primarily an issue with TCP
(is it?), I'd prefer to address it in the TCP mapping document
(4934bis).  If it's more focused on the application-layer exchange of
authorization information I'm OK with making the text change suggested
below in 4933bis.  I should note that the same text exists in 4931bis so
I'd need to change it there as well.

		-Scott-

			From: Catherine Meadows
[mailto:[email-masked]] 
			Sent: Monday, July 06, 2009 11:53 AM
			To: [email-masked]; [email-masked]; Hollenbeck,
Scott
			Cc: Catherine Meadows
			Subject: review of
draft-hollenbeck-rfc4933bis-02

			I have reviewed this document as part of the
security 
			directorate's ongoing effort to review all IETF
documents 
			being processed by the IESG. 
			These comments were written primarily for the
benefit of the 
			security area directors.  Document editors and
WG chairs 
			should treat these comments just like any other
last call comments. 

			Quote from last review:

			"The draft updates RFC 4933, the EPP Contacts
Mapping spec.  
			The updates listed are relatively minor -
updates to 
			references and a few minor updates to text."

			Version 1 has reviewed recently (June 10, by
Sandy Murphy) and the author already
			made the changes that were agreed upon in
following discussion.

			Everything mostly looks OK to me, but there is
one issue that never got completely resolved
			as far as I can tell from what I saw online.
This is the question of channel binding issues as described
			RFC 4953.  I'm having trouble accessing that
document right now, but apparently the issue is that
			low-level authentication mechanisms will not
provide any distinction between channels at a higher level.
			This can make it possible for someone with
access to the authentication mechanisms to spoof different channels.
			In particular, if the EPP authorization
information is protected with lower-level authentication mechanisms this
could
			be the case.  Unless there is good reason to
believe that this sort of attack is impossible (in which case it would
			be a good idea to say why) it might be good 
			that 

				   information is stored and exchanged
with high-grade encryption

				   mechanisms to provide privacy
services.

			be changed to

			Both client and server MUST ensure that
authorization
			   information is stored and exchanged with
high-grade encryption
			   mechanisms to provide privacy and
authentication services at the appropriate level
			of granularity.

			Catherine Meadows

	Catherine Meadows

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 15 Jul 2009 10:51:46 -0400 (Eastern Daylight Time)

(Note to all.  I sent multiple secdir related messages yesterday 
afternoon, and they all were mangled or ultimately not delivered.  So this 
is a repeat that some og the recipients may already have seen. 
Apologies for the technology failure.)

>change suggested below is best made in 4933bis.

Yes, I am guilty of not following up.  I was unsure of my understanding
of channel binding issues, none of the other reviewers of the rfc493*
suite made any notice of the issue, and, as you note here, the
issue is really in the base spec, not 4933.  I just had no idea
what the right process would be, if any.

Subsequent discussion and review of material make me more confident
that there is, indeed, a channel binding issue here.

The question is what to do about it.  This is an established protocol.
Would a security considerations section in 4930bis that pointed out
that there's a MITM attack possible here, because of the lack of
channel binding, be sufficient?  Or would pointing to the sasl-gs2
work as a protection be mentioned?  suggested?  mandated?

I sure would love to see AD or subject matter experts weigh in here
on the technical and process aspects of this.

--Sandy

---

From: "Polk, William T." <[email-masked]>
Date: Wed, 15 Jul 2009 13:59:05 -0400

I'm a little late to the party, but I have been quietly mulling over this problem as well.  Now that Sandy has explicitly asked for an AD to step in, I figured I should participate more actively.  I have also added Nico Williams to the CC list (my apologies, Nico) since channel bindings is really his area of expertise.

I think there is a real need for channel bindings with some applications of EPP, but may not always be strictly necessary in other cases.  For example, the e-Automation project for the administration of DNS root zone uses EPP but if I recall correctly most of the objects that are transferred are digitally signed objects.  In this case, channel bindings are perhaps less important since we aren't relying solely on the EPP authentication mechanism.  So, in my opinion we should encourage their use but should not require channel bindings.

However, if the application is relying on EPP in combination with transport for security, channel bindings would provide significantly enhanced security.  That says channel bindings deserves to be mentioned and a little guidance on (1) implementing channel bindings and (2) determining when channel bindings is required.  That begs a new question of course - where does this information go?

I am starting to believe that the security considerations section of 4930bis should note that enhanced security SHOULD be achieved through channel bindings unless the application involves digitally signed objects, and that the TLS usage section of 4934bis (section 9) should include a pointer to techniques for implementing channel bindings with TLS.  I am still mulling this over, and will probably not enter any discuss until tomorrow, but this seems the best approach.  (Hopefully Nico will weigh in before then and keep me straight on this one...)

Tim Polk

On 7/15/09 10:51 AM, "Sandra Murphy" <[email-masked]> wrote:

--Sandy

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 15 Jul 2009 15:49:13 -0400

I don't have an issue with adding appropriate text to 4934bis.  Help in
coming up with something that's appropriate would be appreciated.
 
I'm a little concerned about adding text to 4930bis unless the text is
generic enough to apply to all potential transport protocols.  A
specific addition proposal would be very helpful.
 
-Scott-

	From: Polk, William T. [mailto:[email-masked]] 
	Sent: Wednesday, July 15, 2009 1:59 PM
	To: Sandra Murphy; Hollenbeck, Scott
	Cc: Catherine Meadows; [email-masked]; [email-masked]; Nicolas
Williams
	Subject: Re: [secdir] review of draft-hollenbeck-rfc4933bis-02

	I'm a little late to the party, but I have been quietly mulling
over this problem as well.  Now that Sandy has explicitly asked for an
AD to step in, I figured I should participate more actively.  I have
also added Nico Williams to the CC list (my apologies, Nico) since
channel bindings is really his area of expertise.
	
	I think there is a real need for channel bindings with some
applications of EPP, but may not always be strictly necessary in other
cases.  For example, the e-Automation project for the administration of
DNS root zone uses EPP but if I recall correctly most of the objects
that are transferred are digitally signed objects.  In this case,
channel bindings are perhaps less important since we aren't relying
solely on the EPP authentication mechanism.  So, in my opinion we should
encourage their use but should not require channel bindings.  
	
	However, if the application is relying on EPP in combination
with transport for security, channel bindings would provide
significantly enhanced security.  That says channel bindings deserves to
be mentioned and a little guidance on (1) implementing channel bindings
and (2) determining when channel bindings is required.  That begs a new
question of course - where does this information go?
	
	I am starting to believe that the security considerations
section of 4930bis should note that enhanced security SHOULD be achieved
through channel bindings unless the application involves digitally
signed objects, and that the TLS usage section of 4934bis (section 9)
should include a pointer to techniques for implementing channel bindings
with TLS.  I am still mulling this over, and will probably not enter any
discuss until tomorrow, but this seems the best approach.  (Hopefully
Nico will weigh in before then and keep me straight on this one...)
	
	Tim Polk

		(Note to all.  I sent multiple secdir related messages
yesterday
		afternoon, and they all were mangled or ultimately not
delivered.  So this
		is a repeat that some og the recipients may already have
seen.
		Apologies for the technology failure.)

		>There was no follow-up, so I remain a little unsure of
how to address
		>change suggested below is best made in 4933bis.
		
		Yes, I am guilty of not following up.  I was unsure of
my understanding
		of channel binding issues, none of the other reviewers
of the rfc493*
		suite made any notice of the issue, and, as you note
here, the
		issue is really in the base spec, not 4933.  I just had
no idea
		what the right process would be, if any.
		
		Subsequent discussion and review of material make me
more confident
		that there is, indeed, a channel binding issue here.
		
		The question is what to do about it.  This is an
established protocol.
		Would a security considerations section in 4930bis that
pointed out
		that there's a MITM attack possible here, because of the
lack of
		channel binding, be sufficient?  Or would pointing to
the sasl-gs2
		work as a protection be mentioned?  suggested?
mandated?
		
		I sure would love to see AD or subject matter experts
weigh in here
		on the technical and process aspects of this.
		
		--Sandy

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 16 Jul 2009 12:18:24 +0100

Hi Tim,

Polk, William T. wrote:

> I’m a little late to the party, but I have been quietly mulling over 
> this problem as well. Now that Sandy has explicitly asked for an AD to 
> step in, I figured I should participate more actively. I have also 
> added Nico Williams to the CC list (my apologies, Nico) since channel 
> bindings is really his area of expertise.
>
> channel bindings are perhaps less important since we aren’t relying 
> solely on the EPP authentication mechanism. So, in my opinion we 
> should encourage their use but should not require channel bindings.

>
> However, if the application is relying on EPP in combination with 
> transport for security, channel bindings would provide significantly 
> enhanced security. That says channel bindings deserves to be mentioned 
> and a little guidance on (1) implementing channel bindings and (2) 
> determining when channel bindings is required. That begs a new 
> question of course – where does this information go?

Nico's response confirmed what I was thinking about this myself: for EPP 
running over TLS over TCP (4934bis), channel bindings are not required, 
because TLS authentication is mandatory and because TLS server 
certificate verification procedure is also mandatory.
So I don't think there is an issue with 4934bis document.

> I am starting to believe that the security considerations section of 
> 4930bis should note that enhanced security SHOULD be achieved through 
> channel bindings unless the application involves digitally signed objects,

I think another alternative can be to require mutual TLS authentication 
in a transport protocol mapping document.

> and that the TLS usage section of 4934bis (section 9) should include a 
> pointer to techniques for implementing channel bindings with TLS.

As per my coment above, I don't think this is needed.
Besides adding channel bindings to EPP would require an extension to EPP 
itself.

> I am still mulling this over, and will probably not enter any discuss 
> until tomorrow, but this seems the best approach. (Hopefully Nico will 
> weigh in before then and keep me straight on this one...)

---

From: "Polk, William T." <[email-masked]>
Date: Thu, 16 Jul 2009 10:54:24 -0400

Hi Alexey,

On 7/16/09 7:18 AM, "Alexey Melnikov" <[email-masked]> wrote:

> Hi Tim,
> 
> Polk, William T. wrote:
> 
>> I¹m a little late to the party, but I have been quietly mulling over
>> channel bindings are perhaps less important since we aren¹t relying
>> question of course  where does this information go?
> 

I'm not so sure... TLS server certificate verification protects the client
against a MITM attack.  The server has no way of knowing whether this
procedure has been implemented.  So, the server does not have all the
protection it needs unless the TLS connection uses client certificate
authentication as well.

Channel bindings would extend the level of assurance for the server.
Alternatively, mutual authentication using certificates would resolve the
problem as well.

> in a transport protocol mapping document.

I think that would be a great solution, and it wouldn't need to tamper with
EPP or 4934bis.  Any new EPP transport protocol mappings in the works?

> Besides adding channel bindings to EPP would require an extension to EPP

That has been part of my concern from the beginning.  Since we are
progressing to Full Standard, extending EPP is pretty much a non-starter.

That is why I would prefer to restrict my discuss or comment to raising
issues in the security considerations of 4930bis.

---

From: "Polk, William T." <[email-masked]>
Date: Thu, 16 Jul 2009 11:01:57 -0400

Alexey,

I just went back and looked at 4934bis... You were right, there is no
channel bindings problem there.

I missed the fact that client certs are *required*, since the bulk of the
section specified how the client should verify the server identity, but no
such text exists for the client cert.  Probably should correct that
oversight, but there is no systemic problem.

Still mulling over 4930...

Any reason we can't make 4934bis the mandatory to implement transport?

Tim 

On 7/16/09 10:54 AM, "Polk, Tim" <[email-masked]> wrote:

> That has been part of my concern from the beginning.  Since we are progressing
> to Full Standard, extending EPP is pretty much a non-starter.
>

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 16 Jul 2009 10:16:54 -0500

> Alternatively, mutual authentication using certificates would resolve the

The client can always just post the username & password in a very public
place, spam people with it, ...

Channel binding doesn't protect against that!  ;)

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 16 Jul 2009 12:01:09 -0400 (Eastern Daylight Time)

> EPP or 4934bis.  Any new EPP transport protocol mappings in the works?

rfc4930bis mentions a couple of others in sect 2.1 Transport Mapping 
Considerations

    -  The transport mapping MUST be onto a transport such as TCP
       [RFC0793] or Stream Control Transmission Protocol (SCTP) [RFC4960]
       that provides congestion avoidance that follows RFC 2914
       [RFC2914], or if it maps onto a protocol such as SMTP [RFC5321] or
       Blocks Extensible Exchange Protocol (BEEP) [RFC3080], then the
       performance issues need to take into account issues of overload,
       server availability, and so forth.

I don't know how close to "in the works" those other suggested examples 
are.

Later it says that EPP can be carried over both connection-less and 
connection oriented transports.

And the security considerations section says that

                          EPP instances MUST be protected using
    a transport mechanism or application protocol that provides
    integrity, confidentiality, and mutual strong client-server
    authentication.

--Sandy

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 16 Jul 2009 12:06:51 -0400

> -----Original Message-----
> From: Sandra Murphy [mailto:[email-masked]] 
> Sent: Thursday, July 16, 2009 12:01 PM
> To: Polk, William T.
> Cc: Alexey Melnikov; Hollenbeck, Scott; Catherine Meadows; 
> [email-masked]; Nicolas Williams; [email-masked]
> >>> this problem as well. Now that Sandy has explicitly asked 
> for an AD 
> >>> to step in, I figured I should participate more actively. I have 
> >>> applications of EPP, but may not always be strictly necessary in 
> >>> other cases. For example, the e-Automation project for the 
> >>> administration of DNS root zone uses EPP but if I recall 
> correctly 
> >>> most of the objects that are transferred are digitally signed 
> >>> objects. In this case, channel bindings are perhaps less 
> important 
> >>> since we aren¹t relying solely on the EPP authentication 
> mechanism. 
> >>> So, in my opinion we should encourage their use but 
> should not require channel bindings.
> >>
> >>>
> >>> enhanced security. That says channel bindings deserves to be 
> >>> mentioned and a little guidance on (1) implementing 
> channel bindings 
> >>> and (2) determining when channel bindings is required. 
> That begs a 
> >>> new question of course  where does this information go?
> >>
> >> Nico's response confirmed what I was thinking about this 
> myself: for 
> >> EPP running over TLS over TCP (4934bis), channel bindings are not 
> >> required, because TLS authentication is mandatory and because TLS 
> >> server certificate verification procedure is also mandatory.
> > I'm not so sure... TLS server certificate verification protects the 
> > client against a MITM attack.  The server has no way of knowing 
> > whether this procedure has been implemented.  So, the 
> server does not 
> > have all the protection it needs unless the TLS connection 
> uses client 
> > certificate authentication as well.
> >
> > Alternatively, mutual authentication using certificates 
> would resolve 
> > the problem as well.
> >
> section of 
> >>> 4930bis should note that enhanced security SHOULD be achieved 
> >>> signed objects,
> >> I think another alternative can be to require mutual TLS 
> >> authentication in a transport protocol mapping document.
> >
> > I think that would be a great solution, and it wouldn't 
> need to tamper 
> > with EPP or 4934bis.  Any new EPP transport protocol 
> mappings in the works?
> 
> rfc4930bis mentions a couple of others in sect 2.1 Transport 
> Mapping Considerations
> 
> I don't know how close to "in the works" those other 
> suggested examples are.
> 
> Later it says that EPP can be carried over both 
> connection-less and connection oriented transports.
> 

I'm not aware of any other IETF work to develop a standards-track transport mapping for EPP.  I have heard that other transports are being used by ccTLDs (they often "roll their own" when it comes to how they operate), but I don't have specific info on-hand.

-Scott-

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 16 Jul 2009 12:49:45 -0500

>       server availability, and so forth.

Incidentally, that text is not clear.  How do "performance issues" take
anything into account?  Someone should be taking "issues of overload"
(uncomfortable wording, that), and so on, but who?  The implementor?
Designers of new transport mappings?  Who?

>    integrity, confidentiality, and mutual strong client-server

Which means TLS, DTLS (for connection-less transports), and maybe SASL
(for BEEP?  SMTP should use TLS).

Note that "mutual strong client-server authentication" needs definition.
In particular the adjective "mutual" as applied to "authentication" can
mean one of two things:

a) Each party's identities are authenticated to the other

OR

b) Authentication does not complete until the party being authenticated
   sends a message that proves it.

   For example, say you're using RSA key transport to encrypt a session
   key in the server's public key.  The server's ability to decrypt the
   session key authenticates the server, but the client won't know that
   the server successfully decrypted the session key until the server
   sends back a message proving it knows the session key.  TLS includes
   such a message.

   This meaning of "mutual authentication" comes from Kerberos, where
   it means that the server will send an AP-REP reply to a client's
   AP-REQ message.

Here I suspect that EPP wants (b), since it will send a username and
password over the secure channel to authenticate the user.  If TLS were
authenticating the user in the first place (as in (a)), then there would
be no need for username and password authentication.

The "strong" adjective also needs some explanation.  I suspect that
what's really desired here is that the _server_ be authenticated via
certificates, while the client will be authenticated by sending a
username and password over the secure channel.  As opposed to both, the
client and server being authenticated to the other via certificates.

Perhaps this would be clearer text:

                         EPP instances MUST be protected using
   a secure, end-to-end channel, at a suitable layer, that provides
   integrity and confidentiality protection, and strong server
   authentication.  Authentication of the server to the client MUST be
   "mutual" in the Kerberos V5 [RFC4120] sense: the secure channel must
   require that the server send a message establishing that key exchange
   and authentication are complete and that the server has access to its
   authentication credentials and knows the session key.

Nico
--