[regext] I-D Action: draft-ietf-regext-org-ext-07.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.

Title   : Organization Extension for the Extensible 
Provisioning Protocol (EPP)
Authors : Linlin Zhou
  Ning Kong
  Junkai Wei
  Xiaodong Lee
  James Gould
Filename: draft-ietf-regext-org-ext-07.txt
Pages   : 24
Date: 2018-06-14

Abstract:
   This document describes an extension to EPP object mappings, which is
   designed to support assigning an organization to any existing object
   (domain, host, contact) as well as any future objects.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-org-ext/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-org-ext-07
https://datatracker.ietf.org/doc/html/draft-ietf-regext-org-ext-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-org-ext-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] FW: New Version Notification for draft-gould-regext-login-security-01.txt

[Gould, James]

Hi,

I posted draft-gould-regext-login-security-01 that incorporates the change to 
the password minimum length discussed on the list.  Let me know if you have any 
additional feedback.

Thanks,
  
—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com  

On 6/14/18, 11:03 AM, "internet-dra...@ietf.org"  
wrote:


A new version of I-D, draft-gould-regext-login-security-01.txt
has been successfully submitted by James Gould and posted to the
IETF repository.

Name:   draft-gould-regext-login-security
Revision:   01
Title:  Login Security Extension for the Extensible 
Provisioning Protocol (EPP)
Document date:  2018-06-14
Group:  Individual Submission
Pages:  18
URL:
https://www.ietf.org/internet-drafts/draft-gould-regext-login-security-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-gould-regext-login-security/
Htmlized:   
https://tools.ietf.org/html/draft-gould-regext-login-security-01
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-gould-regext-login-security
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-gould-regext-login-security-01

Abstract:
   The Extensible Provisioning Protocol (EPP) includes a client
   authentication scheme that is based on a user identifier and
   password.  The structure of the password field is defined by an XML
   Schema data type that specifies minimum and maximum password length
   values, but there are no other provisions for password management
   other than changing the password.  This document describes an EPP
   extension that allows longer passwords to be created and adds
   additional security features to the EPP login command and response.


  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

[Gould, James]

Martin,

This approach looks good to me.  It has the advantage of providing the 
unhandled information in an element that is meant for machine processing 
instead of using the  element that’s meant is meant to be human 
readable.  The other advantage is that the contents of the  element is 
not processed by the XML parser (e.g., processContents=”skip”), meaning it 
would not cause an XML parser error.

This approach could include the entire unhandled extension block without 
causing client-side parsing or unmarshalling issues.  Below is an example of a 
change poll message where the client does not support either the domain or 
changePoll namespaces.  This is unlikely, but it demonstrates how it would work 
for an object and a command / response extension.  As Patrick has pointed out, 
a client could process the contents of the  data offline.



  

  Command completed successfully; ack to dequeue
  

 
   domain.example
   EXAMPLE1-REP
   
   jd1234
   sh8013
   sh8013
   ClientX
   ClientY
   2012-04-03T22:00:00.0Z
   2014-04-03T22:00:00.0Z
 

Message incomplete due to missing 
"urn:ietf:params:xml:ns:domain-1.0" objURI in login services
  
  

 
   update
   2013-10-22T14:25:57.0Z
   12345-XYZ
   URS Admin
   urs123
   URS Lock
 

Message incomplete due to missing 
"urn:ietf:params:xml:ns:changePoll-1.0" extURI in login services
  


  2018-06-14T13:46:33.453Z
  Registry initiated update of domain.


  ABC-12345
  54321-XYZ

  




—

JG

[cid:image001.png@01D255E2.EB933A30]

James Gould
Distinguished Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: regext  on behalf of Martin Casanova 

Date: Thursday, June 14, 2018 at 5:23 AM
To: "regext@ietf.org" 
Subject: [EXTERNAL] Re: [regext] Poll messages with unhandled namespaces (was 
Re: I-D Action: draft-ietf-regext-change-poll-07.txt)


Hello

While implementing, another idea came to mind, which I want to put to 
discussion here:



  

  Command completed successfully; ack to dequeue

  

  urn:ietf:params:xml:ns:changePoll-1.0

Msg incomplete due to missing extURI at login cmd! To 
fix include at epp/command/login/svcs/svcExtension/extURI
  
  

  urn:ietf:params:xml:ns:secDNS-1.1

Msg incomplete due to missing extURI at login cmd! To 
fix include at : epp/command/login/svcs/svcExtension/extURI
  



It is validating against the schemas. The value is referring to a MISSING 
client provided element in this case. The reason is again human readable and 
referring to a server error which is

not quite the case here but still is indicating a condition that is not ideal..

from RFC-5730

  o  Zero or more OPTIONAL  elements that can be used to

 provide additional error diagnostic information, including:



 *  A  element that identifies a client-provided element

(including XML tag and value) that caused a server error

condition.



 *  A  element containing a human-readable message that

describes the reason for the error.  The language of the

response is identified via an OPTIONAL "lang" attribute.  If

not specified, the default attribute value MUST be "en"

(English).

Regards.
Martin

SWITCH

Martin Casanova, Domain Applications

Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland

phone +41 44 268 15 55, direct +41 44 268 16 25

martin.casan...@switch.ch, 
www.switch.ch



Working for a better digital world


On 24.05.2018 10:31, Martin Casanova wrote:
Hello

Sorry I have not been checking the mails of this mailing list for a while...

In my opinion as registries we have a special role and should stick to the 
RFC’s as close as possible for a strong EPP standard everybody can rely on. 
Therefore I find it valuable to discuss the RFC’s and get everybody's input.

I think that there is an issue with potentially breaking some clients, although 
for some clients it may not be a problem as was pointed out.

Also I don't see a big problem for clients to not receive full information in a 
message of a freshly implemented Change Poll Extension response since they 
didn't get it at all before the extension was implemented.

The suggestion of James Gould to give a hint about the missing extension part 
in the  field of the poll response may be a way to go. This filed is 
intended for humans and thats what we want to do: Inform a human to prepare his 
client and configure the Login command accordingly if he wants to receive the 
information of the extension.

However the ChangePoll 

Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Gould, James]

> JG - I don’t believe there is any desire to switch from using the

> variant of the PLAIN SASL mechanism [RFC4616] defined in the existing

> EPP RFC [RFC5730].



I do not know. My main point was more around: if we decide to put more energy 
into "securing" EPP better, providing more options than just plain text 
passwords (as asked by Pieter also I think) would be now a good time to think 
about, and if we go towards some "extensibility"  in authentication frameworks, 
why not just build on existing RFCs?



We can consider alternative authentication options if there is a concrete 
proposal and the proposal does provide a security enhancement.  Currently, most 
EPP registries support multi-factor authentication with the combination of user 
name / password and client certificate / client IP address.  The RFC 5730 16 
character maximum password is a undesirable constraint that is addressed via 
draft-gould-regext-login-security.  I reviewed the RFCs that you referenced 
(SASL and PRECIS) and I don’t see anything in them that defines an alternative 
authentication mechanism for EPP.  Creating additional authentication options 
in EPP may result in less security, so it would be good to understand what 
security aspect needs to be fixed prior to creating additional options.



Thanks,

—

JG







James Gould

Distinguished Engineer

jgo...@verisign.com



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com 



On 6/13/18, 6:48 PM, "regext on behalf of Patrick Mevzek" 
 wrote:



On Mon, Jun 11, 2018, at 21:57, Gould, James wrote:

> Patrick,

>

>

>

> > JG - Thanks, I'll take a closer look at the PRECIS framework in RFC 
7564

>

> > and 8265.

>

>

>

> Please also look at the SASL framework (RFC4422 and RFC4616 for its

> PLAIN version which is basically what we have currently) : this allows

> to decouple authentication needs to the underlying application/protocol,

> which also address Pieter remark about other ways to authenticate.

>

>

>

> JG - I don’t believe there is any desire to switch from using the

> variant of the PLAIN SASL mechanism [RFC4616] defined in the existing

> EPP RFC [RFC5730].



I do not know. My main point was more around: if we decide to put more 
energy into "securing" EPP better, providing more options than just plain text 
passwords (as asked by Pieter also I think) would be now a good time to think 
about, and if we go towards some "extensibility"  in authentication frameworks, 
why not just build on existing RFCs?



--

  Patrick Mevzek



___

regext mailing list

regext@ietf.org

https://www.ietf.org/mailman/listinfo/regext


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Gould, James]

Patrick,

Based on the feedback provided thus far, it looks like setting the minimum to 
the RFC 5730 of 6 with Scott's added language as the way forward.  

Thanks,
  
—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com  

On 6/13/18, 6:45 PM, "regext on behalf of Patrick Mevzek" 
 wrote:



On Mon, Jun 11, 2018, at 19:43, Gould, James wrote:
> In thinking about decreasing the minimum from 8 to 1, I have a concern 
> that we're going to support a minimum that is below the existing RFC 
> 5730 of 6 characters.  I believe it would be best for the Login Security 
> Extension to at least support the existing 6 character minimum with the 
> added language that Scott proposed “Servers SHOULD enforce minimum and 
> maximum password length requirements that are appropriate for their 
> operating environment. One example of a guideline for password length 
> policies can be found in  [reference here]".  Scott's 
> language can be added to the Security Considerations section of the 
> draft.
> 
> Let me know if this will work.  

I do not oppose that if this is the consensus but I still see it as 
pointless to provide *any* specific minimum limit here, and I do not see the 
problem with going lower than RFC5730 since this extension is optional and, 
hopefully, if it is used it means the relevant registry has decided to put more 
energy and work around security measures so you could hope they would deal with 
this minimum issue gracefully (that is enforcing something higher than 6, and 
not lower, if they do define the space of characters allowed too).

-- 
  Patrick Mevzek

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

[Martin Casanova]

Hello

While implementing, another idea came to mind, which I want to put to
discussion here:



  
    
  Command completed successfully; ack to dequeue

  
    
  urn:ietf:params:xml:ns:changePoll-1.0
    
    Msg incomplete due to missing extURI at login
cmd! To fix include at epp/command/login/svcs/svcExtension/extURI
  
  
    
  urn:ietf:params:xml:ns:secDNS-1.1
    
    Msg incomplete due to missing extURI at login
cmd! To fix include at : epp/command/login/svcs/svcExtension/extURI
  


It is validating against the schemas. The value is referring to a
MISSING client provided element in this case. The reason is again human
readable and referring to a server error which is

not quite the case here but still is indicating a condition that is not
ideal..

from RFC-5730

  o  Zero or more OPTIONAL  elements that can be used to
 provide additional error diagnostic information, including:

 *  A  element that identifies a client-provided element
(including XML tag and value) that caused a server error
condition.

 *  A  element containing a human-readable message that
describes the reason for the error.  The language of the
response is identified via an OPTIONAL "lang" attribute.  If
not specified, the default attribute value MUST be "en"
(English).

Regards.

Martin

SWITCH 
Martin Casanova, Domain Applications
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland 
phone +41 44 268 15 55, direct +41 44 268 16 25
martin.casan...@switch.ch, www.switch.ch 
 
Working for a better digital world




On 24.05.2018 10:31, Martin Casanova wrote:
> Hello
>
> Sorry I have not been checking the mails of this mailing list for a
> while...
>
> In my opinion as registries we have a special role and should stick to
> the RFC’s as close as possible for a strong EPP standard everybody can
> rely on. Therefore I find it valuable to discuss the RFC’s and get
> everybody's input.
>
> I think that there is an issue with potentially breaking some clients,
> although for some clients it may not be a problem as was pointed out.
>
> Also I don't see a big problem for clients to not receive full
> information in a message of a freshly implemented Change Poll
> Extension response since they didn't get it at all before the
> extension was implemented.
>
> The suggestion of James Gould to give a hint about the missing
> extension part in the  field of the poll response may be a way to
> go. This filed is intended for humans and thats what we want to do:
> Inform a human to prepare his client and configure the Login command
> accordingly if he wants to receive the information of the extension.
>
> However the ChangePoll Extension is not the only one we need to inform
> about. How should we inform about a changes in DNSSec Data? We also
> would have to indicate that the DNSSec extension should be configured
> in order to include something like
>
>  xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">2371
> 13
> 2
> F991B7FDE40A2C4CD7BEFBBE9A1073D1FC3E34EC6DC31E2931320D1CD8392390
> 
> 
>
> in the extension part..
>
> We are planing to do something like this as we are going to implement
> the RFC-8078 / RFC-7344 CDS feature. Of course there will also be an
> out of band communication with our registrars about this.
>
> Martin
>
> --  SWITCH 
> Martin Casanova, Domain Applications
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland 
> phone +41 44 268 15 55, direct +41 44 268 16 25
> martin.casan...@switch.ch, www.switch.ch 
>  
> Working for a better digital world
>
>
>
>
>
>
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

-- 
--- 
SWITCH 
Martin Casanova, Domain Applications
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland 
phone +41 44 268 15 55, direct +41 44 268 16 25
martin.casan...@switch.ch, www.switch.ch 
 
Working for a better digital world

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Pieter Vandepitte]

I have nothing to add. Just letting know I share the same opinion.

-- 
Pieter Vandepitte
Product Expert
+32 16 28 49 70
www.dnsbelgium.be 
 

 
 

On 14/06/18 00:45, "regext on behalf of Patrick Mevzek" 
 wrote:



On Mon, Jun 11, 2018, at 19:43, Gould, James wrote:
> In thinking about decreasing the minimum from 8 to 1, I have a concern 
> that we're going to support a minimum that is below the existing RFC 
> 5730 of 6 characters.  I believe it would be best for the Login Security 
> Extension to at least support the existing 6 character minimum with the 
> added language that Scott proposed “Servers SHOULD enforce minimum and 
> maximum password length requirements that are appropriate for their 
> operating environment. One example of a guideline for password length 
> policies can be found in  [reference here]".  Scott's 
> language can be added to the Security Considerations section of the 
> draft.
> 
> Let me know if this will work.  

I do not oppose that if this is the consensus but I still see it as 
pointless to provide *any* specific minimum limit here, and I do not see the 
problem with going lower than RFC5730 since this extension is optional and, 
hopefully, if it is used it means the relevant registry has decided to put more 
energy and work around security measures so you could hope they would deal with 
this minimum issue gracefully (that is enforcing something higher than 6, and 
not lower, if they do define the space of characters allowed too).

-- 
  Patrick Mevzek

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext