Subject: Re: SASL WG session at IETF68
From: Kurt Zeilenga <[email-masked]>
To: [email-masked]
Date: Mon, 26 Feb 2007 15:55:43 -0800
List-Id: <ietf-sasl.imc.org>

Those with items for our agenda should contact Tom and I in the next  
week
or so with a basic description of the topic and time needs.

-- Kurt

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: remaining DIGEST-MD5 items?
Date:  Sat, 24 Feb 2007 18:06:32 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 51
Sender: [email-masked]

Alexey Melnikov wrote:

>> Accept multiple commas instead of only one comma to separate elements,
>> why not, it's no rocket science.

> Yes, but somebody just pointed out an error related to this in Cyrus
> SASL code ;-)

LOL.  Interpreting the 2068 BNF was really a PITA, I hope the admittedly
more verbose RFC 4234 style will convince them that that's a bug.

 [continuation lines consisting only of trailing white space]
> This particular thing causes no harm in SASL, as it is not being used
> inside RFC 2822 messages.

Relevant for 2617bis, where the Auth digest stuff isn't B64-encoded.

Do _all_ SASL-applications use B64 ?  Checking, no, ACAP (RFC 2244)
apparently uses lines of plain text, no LWSP folding at all, let alone
continuation lines consisting only of trailing white space.

>> Maybe a case for a MUST NOT generate + MUST accept (?)

> I think "SHOULD NOT generate LWS + MUST accept them" is more reasonable,
> as there might be implementations that already use them. And I would
> rather not declare them non compliant just for that.

The 2822 <obs-FWS> is a MUST NOT.   The main point here is to mention
the (potential) issue somewhere in the prose, SHOULD NOT is also fine.

>> I still don't know if your're really really sure about your new and
>> in theory incompatible with 2831/2617/2069 "backslash unescaping"
>> _within_ <qdstr-value>.

> I always thought that "unquoting" also means removing any escaping
> backslashes. I might be wrong on this.

I looked into Simon's GNU SASL code, and found no hint that he tries
to get rid of backslashes anywhere - or is that a feature of asprintf ?
Apparently his Digest-MD5 code is 2831 (written 2006), not 2831bis.

> I haven't seen anybody using backslashes in DIGEST-MD5 except for 
> Microsoft implementation, which uses them in usernames.  I think I 
> need to do some testing to confirm one way or the other.

"Take <qdstr-val> as is (after removing the quotes)" could be a very
simple solution, if folks always escape a '\' and '"' as '\\' or '\"',
and otherwise stay away from <quoted-pair>.

Frank

To: [email-masked]
Subject: SASL WG session at IETF68
From: Tom Yu <[email-masked]>
Date: Tue, 13 Feb 2007 08:45:24 -0500
Lines: 7
Sender: [email-masked]

The SASL WG session at IETF68 is currently scheduled for Wednesday 21
March at 13:00-15:00.

We have until the 21st of February to request changes.  Does anyone
have a problem with the current schedule?

---Tom

Date: Tue, 13 Feb 2007 11:43:14 +0000
From: Alexey Melnikov <[email-masked]>
To: Frank Ellermann <[email-masked]>
CC: [email-masked]
Subject: Re: remaining DIGEST-MD5 items?
Sender: [email-masked]

Frank Ellermann wrote:

>Alexey Melnikov wrote:
>  
>
>>I personally like the n#rule construct, as it is much more compact    
>>
>I hate the LWSP hidden in it.  Something in the same direction based
>on FWS (as in 2822) could be nice.  With LWSP the following is valid:
>
>element1<SP>,<HT>,<CRLF>
><SP><CRLF>
><HT><CRLF>
><SP>element2,<SP>element3<CRLF>
>
>Accept HT as white space in addition to SP is not nice, but okay, if
>it somehwere gets replaced by spaces no harm done (wrt LWSP or FWS).
>
>Accept multiple commas instead of only one comma to separate elements,
>why not, it's no rocket science.
>
Yes, but somebody just pointed out an error related to this in Cyrus 
SASL code ;-)

>But accept lines consisting only of trailing white space, and treat
>that as valid continuation / folding, I really don't like this, it's
>too easy to get this wrong with some tools (including text editors).
>
This particular thing causes no harm in SASL, as it is not being used 
inside RFC 2822 messages.

>Maybe a case for a MUST NOT generate + MUST accept (?)
>
I think "SHOULD NOT generate LWS + MUST accept them" is more reasonable, 
as there might be implementations that already use them. And I would 
rather not declare them non compliant just for that.

>We had the in essence same issue already in USEFOR, you know the arguments :-)
>  
>
>>>s/<<channel-type/channel-type/
>>>      
>>>
>>I use <<>> markers to highlight something which needs fixing.
>>Currently the exact format of channel bindings is not finalized yet.
>>    
>>
>Okay.  Bill's 4234-ABNF validator would make sure that it's fixed.
>
>Apart from the LWSP issue (with 4234-ABNF it's at least obvious) I
>still don't know if your're really really sure about your new and
>in theory incompatible with 2831/2617/2069 "backslash unescaping"
>_within_ <qdstr-value>.
>
I always thought that "unquoting" also means removing any escaping 
backslashes. I might be wrong on this.

In practice, I haven't seen anybody using backslashes in DIGEST-MD5 
except for Microsoft implementation, which uses them in usernames.
I think I need to do some testing to confirm one way or the other.

>I didn't have this in my own attempt to
>implement a 2831-digest.  It was simple to add it, but that's not
>the point, what do "real" 2831/2617/2069 implementations with it ?
>  
>

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sasl-gs2-06.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Sat, 10 Feb 2007 17:23:44 +0100
Sender: [email-masked]

[email-masked] writes:

> http://www.ietf.org/internet-drafts/draft-ietf-sasl-gs2-06.txt

This fixes some typos and IDNits, which are the only things that have
been pointed out to me since -05.  I believe this version is ready for
WGLC.

/Simon

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-gs2-06.txt 
Date: Fri, 09 Feb 2007 18:50:02 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.

	Title		: Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
	Author(s)	: S. Josefsson
	Filename	: draft-ietf-sasl-gs2-06.txt
	Pages		: 34
	Date		: 2007-2-9
	
This document describes how to use a Generic Security Service
   Application Program Interface (GSS-API) mechanism in the the Simple
   Authentication and Security Layer (SASL) framework.  This is done by
   defining a new SASL mechanism family, called GS2.  This mechanism
   family offers a number of improvements over the previous SASL/GSS-API
   mechanism: it is more general, uses fewer messages for the
   authentication phase in some cases, and supports a SASL-specific
   notion of channel binding.

   See <http://josefsson.org/sasl-gs2-*/> for more information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-gs2-06.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-sasl-gs2-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sasl-gs2-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sasl-gs2-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sasl-gs2-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: remaining DIGEST-MD5 items?
Date:  Fri, 09 Feb 2007 17:27:14 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 41
Sender: [email-masked]

Alexey Melnikov wrote:

> I personally like the n#rule construct, as it is much more compact

I hate the LWSP hidden in it.  Something in the same direction based
on FWS (as in 2822) could be nice.  With LWSP the following is valid:

element1<SP>,<HT>,<CRLF>
<SP><CRLF>
<HT><CRLF>
<SP>element2,<SP>element3<CRLF>

Accept HT as white space in addition to SP is not nice, but okay, if
it somehwere gets replaced by spaces no harm done (wrt LWSP or FWS).

Accept multiple commas instead of only one comma to separate elements,
why not, it's no rocket science.

But accept lines consisting only of trailing white space, and treat
that as valid continuation / folding, I really don't like this, it's
too easy to get this wrong with some tools (including text editors).

Maybe a case for a MUST NOT generate + MUST accept (?)  We had the
in essence same issue already in USEFOR, you know the arguments :-)

>> s/<<channel-type/channel-type/

> I use <<>> markers to highlight something which needs fixing.
> Currently the exact format of channel bindings is not finalized yet.

Okay.  Bill's 4234-ABNF validator would make sure that it's fixed.

Apart from the LWSP issue (with 4234-ABNF it's at least obvious) I
still don't know if your're really really sure about your new and
in theory incompatible with 2831/2617/2069 "backslash unescaping"
_within_ <qdstr-value>.  I didn't have this in my own attempt to
implement a 2831-digest.  It was simple to add it, but that's not
the point, what do "real" 2831/2617/2069 implementations with it ?

Frank

Date: Fri, 09 Feb 2007 11:11:17 +0000
From: Alexey Melnikov <[email-masked]>
To: Frank Ellermann <[email-masked]>
CC: [email-masked]
Subject: Re: remaining DIGEST-MD5 items?
Sender: [email-masked]

Frank Ellermann wrote:

>Chris Newman wrote:
>  
>
>>I am opposed to changing the ABNF because the editor has better uses
>>for his time that will provide more value to the IETF community
>>    
>>
>What about the time of readers trying to figure out what chapter 7.2
>really means ?  Or the time of anybody trying to evaluate the "ABNF" ?
>
Frank, I hear your comment about using consistent ABNF if all 
specifications.

But I personally like the n#rule construct, as it is much more compact 
and, as a result, easier to understand. It is a shame that it is not a 
part of the ABNF spec.
But if the WG consensus is to go with ABNF, I will do the change.
(And thanks for the effort to convert to ABNF, BTW.)

>Just for fun I tried the latter and found the following six problems:
>
>s/server_maxbuf/server-maxbuf/g
>s/client_maxbuf/client-maxbuf/g
>  
>
Thanks for spotting that.

>s/<<channel-type/channel-type/
>  
>
I use <<>> markers to highlight something which needs fixing. Currently 
the exact format of channel bindings is not finalized yet.

>prep is defined twice, renamed in "step two" to prep2
>  
>
Ah, good point. I've renamed the first one to prep-opts instead.

>TEXT was unused, removed
>
Right.

>added <CTL> reference from RFC 4234 (while talking about Latin-1
>            and Unicode it's not more obvious what a <CTL> is)
>
>expanded prose definition of <qdtext>
>expanded prose definition of <TEXTCHAR>
>expanded all occurences of 1#element to
>   LWSP element *(LWSP "," LWSP [element]) LWSP
>
>Chapter 7.2 suggests that the expansion of 1#element is...
>   LWSP element *(LWSP "," LWSP element) LWSP
>...but the prose explains that [element] is the idea.
>
Indeed.

Date: Mon, 05 Feb 2007 16:48:15 -0800
From: Chris Newman <[email-masked]>
Subject: Re: remaining DIGEST-MD5 items?
To: Frank Ellermann <[email-masked]>, [email-masked]
Sender: [email-masked]

Since Frank did the work, I withdraw my objection and would support using the 
proposed RFC 4234 version of the ABNF.  I do not consider this issue a 
show-stopper to publication of 2831bis, but it would be a nice improvement.

                - Chris

Frank Ellermann wrote on 2/4/07 18:32 +0100:
>> After that I got something passing Bill's parser.
>> The complete confusing chapter 7.2 could be removed
>
> The complete chapter 7 could go, but I forgot to replace
> all "=" by EQU adding a definition EQU = LWSP "=" LWSP

Frank Ellermann wrote on 2/4/07 18:10 +0100:
> Chris Newman wrote:
>
>> I am opposed to changing the ABNF because the editor has better uses
>> for his time that will provide more value to the IETF community
>
> What about the time of readers trying to figure out what chapter 7.2
> really means ?  Or the time of anybody trying to evaluate the "ABNF" ?
>
> Just for fun I tried the latter and found the following six problems:
>
> s/server_maxbuf/server-maxbuf/g
> s/client_maxbuf/client-maxbuf/g
> s/<<channel-type/channel-type/
> prep is defined twice, renamed in "step two" to prep2
> TEXT was unused, removed
>
> added <CTL> reference from RFC 4234 (while talking about Latin-1
>             and Unicode it's not more obvious what a <CTL> is)
>
> expanded prose definition of <qdtext>
> expanded prose definition of <TEXTCHAR>
> expanded all occurences of 1#element to
>    LWSP element *(LWSP "," LWSP [element]) LWSP
>
> Chapter 7.2 suggests that the expansion of 1#element is...
>    LWSP element *(LWSP "," LWSP element) LWSP
> ...but the prose explains that [element] is the idea.
>
> After that I got something passing Bill's parser.  The complete
> confusing chapter 7.2 could be removed, see below.
>
> Frank
>
> ;;; 2.1.1 Step One
>
> digest-challenge = LWSP d-c-e *(LWSP "," LWSP [d-c-e]) LWSP
> d-c-e            = realm / nonce / qop-options / stale
>                  / server-maxbuf / charset / prep / algorithm
>                  / cipher-opts / auth-param
>
> realm            = "realm" "=" realm-value
> realm-value      = quoted-string
> nonce            = "nonce" "=" nonce-value
> nonce-value      = quoted-string
>                    ;; contains data described by "nonce-data"
> qop-options      = "qop" "=" DQUOTE qop-list DQUOTE
> qop-list         = LWSP qop-value *(LWSP "," LWSP [qop-value]) LWSP
> qop-value        = "auth" / "auth-int" / "auth-conf" /
>                     qop-token
>                     ;; qop-token is reserved for identifying
>                     ;; future extensions to DIGEST-MD5
> qop-token        = token
> stale            = "stale" "=" "true"
> server-maxbuf    = "maxbuf" "=" maxbuf-value
> maxbuf-value     = 1*DIGIT
> charset          = "charset" "=" "utf-8"
> prep             = "prep" "=" DQUOTE prep-mechs DQUOTE
> prep-mechs       = LWSP prep-mech *(LWSP "," LWSP [prep-mech]) LWSP
> prep-mech        = "rfc4013"
> algorithm        = "algorithm" "=" "md5-sess"
> cipher-opts      = "cipher" "=" DQUOTE cipher-list DQUOTE
> cipher-list      = LWSP cipher-value
>                    *(LWSP "," LWSP [cipher-value]) LWSP
> cipher-value     = "rc4-40" / "rc4" / "rc4-56" /
>                    "aes-ctr" / cipher-token
>                     ;; cipher-token is reserved for
>                     ;; new ciphersuites
> cipher-token     = token
> auth-param       = token "=" ( token / quoted-string )
> nonce-data       = new-nonce-data / obs-nonce-data
> new-nonce-data   = "CB-" channel-type ":" channel-bindings
>                    ":" qop-list ":" cipher-list
>                    ":" nonce-octets
> obs-nonce-data   = nonce-octets
>                    ;; nonce value as defined in RFC 2831.
>                    ;; SHOULD be accepted. MUST NOT be
>                    ;; generated.
> channel-type     = "TLS" / channel-type-ext
>                    ;; Should be taken from
>                    ;; [CHANNEL-BINDINGS].
> channel-type-ext = 1*(ALPHA / DIGIT)
>                    ;; for future channel bindings>>
> channel-bindings = 1*TEXTCHAR
>                    ;; channel binding data as defined by
>                    ;; the channel type
>
> nonce-octets     = 1*TEXTCHAR
>
> ;;; 2.1.2 Step Two
>
> digest-response  = LWSP d-r-e *(LWSP "," LWSP [d-r-e]) LWSP
> d-r-e            = username / realm / nonce / cnonce
>                  / nonce-count / qop / digest-uri / response
>                  / response-v2 / client-maxbuf / charset
>                  / prep2 / cipher / authzid / auth-param
>
> username         = "username" "=" username-value
> username-value   = quoted-string
> cnonce           = "cnonce" "=" cnonce-value
> cnonce-value     = nonce-value
> nonce-count      = "nc" "=" nc-value
> nc-value         = 8LHEX
> client-maxbuf    = "maxbuf" "=" maxbuf-value
> qop              = "qop" "=" qop-value
> digest-uri       = "digest-uri" "="
>                    DQUOTE digest-uri-value DQUOTE
> digest-uri-value = serv-type "/" host [ "/" serv-name ]
> serv-type        = 1*ALPHA
> serv-name        = host
> prep2            = "prep" "=" prep-mech
> response         = "response" "=" response-value
> response-v2      = "response-v2" "=" response-value
> response-value   = 32LHEX
> LHEX             = DIGIT / "a" / "b" /
>                    "c" / "d" / "e" / "f"
> cipher           = "cipher" "=" cipher-value
> authzid          = "authzid" "=" authzid-value
> authzid-value    = quoted-string
>
> host             = IP-literal / IPv4address / reg-name
> IP-literal       = <see RFC 3986>
> IPv4address      = <see RFC 3986>
> reg-name         = <see RFC 3986>
>
> ;;; 2.1.2.1 Response-value
>
> password         = *OCTET
>
> ;;; 2.1.3 Step Three
>
> auth-info        = LWSP a-i-e *(LWSP "," LWSP [a-i-e]) LWSP
> a-i-e            = response-auth / response-v2-auth / auth-param
>
> response-auth    = "rspauth" "=" response-value
> response-v2-auth = "rspauth-v2" "=" response-value
>
> ;;; 7.2 Basic rules
>
> TEXTCHAR         = HTAB / %x20-7E / %x80-FF
> LWSP             = *(WSP / CRLF WSP)
>
> token            = 1*TOKENCHAR
> BACKSLASH        = %x5C
>                    ;  character
> separators       = "(" / ")" / "<" / ">" / "@"
>                  / "," / ";" / ":" / BACKSLASH / DQUOTE
>                  / "/" / "[" / "]" / "?" / "="
>                  / "{" / "}" / SP  / HTAB
> TOKENCHAR        = <any CHAR except CTLs or separators>
>
> quoted-string    = DQUOTE qdstr-val DQUOTE
> qdstr-val        = *( qdtext / quoted-pair )
> qdtext           = HTAB / %x20-21 / %x23-5B / %x5D-7E / %x80-FF
>
> quoted-pair      = BACKSLASH CHAR
>
> ;;; imported from RFC 4234
>
> DIGIT            = <see RFC 4234>       ; 0-9
> DQUOTE           = <see RFC 4234>       ; " (Double Quote)
> ALPHA            = <see RFC 4234>       ; A-Z / a-z
> OCTET            = <see RFC 4234>       ; 8 bits of data
> WSP              = <see RFC 4234>       ; white space
> CRLF             = <see RFC 4234>       ; Internet standard newline
> HTAB             =  %x09
> SP               =  %x20
> CHAR             = <see RFC 4234>       ; any ASCII excluding NUL
> CTL              = <see RFC 4234>       ; %x00-1F / %x7F

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: remaining DIGEST-MD5 items?
Date:  Sun, 04 Feb 2007 18:32:16 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 10
Sender: [email-masked]

> After that I got something passing Bill's parser.
> The complete confusing chapter 7.2 could be removed

The complete chapter 7 could go, but I forgot to replace
all "=" by EQU adding a definition EQU = LWSP "=" LWSP

Sorry,

 Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: remaining DIGEST-MD5 items?
Date:  Sun, 04 Feb 2007 18:10:15 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 169
Sender: [email-masked]

Chris Newman wrote:

> I am opposed to changing the ABNF because the editor has better uses
> for his time that will provide more value to the IETF community

What about the time of readers trying to figure out what chapter 7.2
really means ?  Or the time of anybody trying to evaluate the "ABNF" ?

Just for fun I tried the latter and found the following six problems:

s/server_maxbuf/server-maxbuf/g
s/client_maxbuf/client-maxbuf/g
s/<<channel-type/channel-type/
prep is defined twice, renamed in "step two" to prep2
TEXT was unused, removed

added <CTL> reference from RFC 4234 (while talking about Latin-1
            and Unicode it's not more obvious what a <CTL> is)

expanded prose definition of <qdtext>
expanded prose definition of <TEXTCHAR>
expanded all occurences of 1#element to
   LWSP element *(LWSP "," LWSP [element]) LWSP

Chapter 7.2 suggests that the expansion of 1#element is...
   LWSP element *(LWSP "," LWSP element) LWSP
...but the prose explains that [element] is the idea.

After that I got something passing Bill's parser.  The complete
confusing chapter 7.2 could be removed, see below.

Frank

;;; 2.1.1 Step One

digest-challenge = LWSP d-c-e *(LWSP "," LWSP [d-c-e]) LWSP
d-c-e            = realm / nonce / qop-options / stale
                 / server-maxbuf / charset / prep / algorithm
                 / cipher-opts / auth-param

realm            = "realm" "=" realm-value
realm-value      = quoted-string
nonce            = "nonce" "=" nonce-value
nonce-value      = quoted-string
                   ;; contains data described by "nonce-data"
qop-options      = "qop" "=" DQUOTE qop-list DQUOTE
qop-list         = LWSP qop-value *(LWSP "," LWSP [qop-value]) LWSP
qop-value        = "auth" / "auth-int" / "auth-conf" /
                    qop-token
                    ;; qop-token is reserved for identifying
                    ;; future extensions to DIGEST-MD5
qop-token        = token
stale            = "stale" "=" "true"
server-maxbuf    = "maxbuf" "=" maxbuf-value
maxbuf-value     = 1*DIGIT
charset          = "charset" "=" "utf-8"
prep             = "prep" "=" DQUOTE prep-mechs DQUOTE
prep-mechs       = LWSP prep-mech *(LWSP "," LWSP [prep-mech]) LWSP
prep-mech        = "rfc4013"
algorithm        = "algorithm" "=" "md5-sess"
cipher-opts      = "cipher" "=" DQUOTE cipher-list DQUOTE
cipher-list      = LWSP cipher-value
                   *(LWSP "," LWSP [cipher-value]) LWSP
cipher-value     = "rc4-40" / "rc4" / "rc4-56" /
                   "aes-ctr" / cipher-token
                    ;; cipher-token is reserved for
                    ;; new ciphersuites
cipher-token     = token
auth-param       = token "=" ( token / quoted-string )
nonce-data       = new-nonce-data / obs-nonce-data
new-nonce-data   = "CB-" channel-type ":" channel-bindings
                   ":" qop-list ":" cipher-list
                   ":" nonce-octets
obs-nonce-data   = nonce-octets
                   ;; nonce value as defined in RFC 2831.
                   ;; SHOULD be accepted. MUST NOT be
                   ;; generated.
channel-type     = "TLS" / channel-type-ext
                   ;; Should be taken from
                   ;; [CHANNEL-BINDINGS].
channel-type-ext = 1*(ALPHA / DIGIT)
                   ;; for future channel bindings>>
channel-bindings = 1*TEXTCHAR
                   ;; channel binding data as defined by
                   ;; the channel type

nonce-octets     = 1*TEXTCHAR

;;; 2.1.2 Step Two

digest-response  = LWSP d-r-e *(LWSP "," LWSP [d-r-e]) LWSP
d-r-e            = username / realm / nonce / cnonce
                 / nonce-count / qop / digest-uri / response
                 / response-v2 / client-maxbuf / charset
                 / prep2 / cipher / authzid / auth-param

username         = "username" "=" username-value
username-value   = quoted-string
cnonce           = "cnonce" "=" cnonce-value
cnonce-value     = nonce-value
nonce-count      = "nc" "=" nc-value
nc-value         = 8LHEX
client-maxbuf    = "maxbuf" "=" maxbuf-value
qop              = "qop" "=" qop-value
digest-uri       = "digest-uri" "="
                   DQUOTE digest-uri-value DQUOTE
digest-uri-value = serv-type "/" host [ "/" serv-name ]
serv-type        = 1*ALPHA
serv-name        = host
prep2            = "prep" "=" prep-mech
response         = "response" "=" response-value
response-v2      = "response-v2" "=" response-value
response-value   = 32LHEX
LHEX             = DIGIT / "a" / "b" /
                   "c" / "d" / "e" / "f"
cipher           = "cipher" "=" cipher-value
authzid          = "authzid" "=" authzid-value
authzid-value    = quoted-string

host             = IP-literal / IPv4address / reg-name
IP-literal       = <see RFC 3986>
IPv4address      = <see RFC 3986>
reg-name         = <see RFC 3986>

;;; 2.1.2.1 Response-value

password         = *OCTET

;;; 2.1.3 Step Three

auth-info        = LWSP a-i-e *(LWSP "," LWSP [a-i-e]) LWSP
a-i-e            = response-auth / response-v2-auth / auth-param

response-auth    = "rspauth" "=" response-value
response-v2-auth = "rspauth-v2" "=" response-value

;;; 7.2 Basic rules

TEXTCHAR         = HTAB / %x20-7E / %x80-FF
LWSP             = *(WSP / CRLF WSP)

token            = 1*TOKENCHAR
BACKSLASH        = %x5C
                   ;  character
separators       = "(" / ")" / "<" / ">" / "@"
                 / "," / ";" / ":" / BACKSLASH / DQUOTE
                 / "/" / "[" / "]" / "?" / "="
                 / "{" / "}" / SP  / HTAB
TOKENCHAR        = <any CHAR except CTLs or separators>

quoted-string    = DQUOTE qdstr-val DQUOTE
qdstr-val        = *( qdtext / quoted-pair )
qdtext           = HTAB / %x20-21 / %x23-5B / %x5D-7E / %x80-FF

quoted-pair      = BACKSLASH CHAR

;;; imported from RFC 4234

DIGIT            = <see RFC 4234>       ; 0-9
DQUOTE           = <see RFC 4234>       ; " (Double Quote)
ALPHA            = <see RFC 4234>       ; A-Z / a-z
OCTET            = <see RFC 4234>       ; 8 bits of data
WSP              = <see RFC 4234>       ; white space
CRLF             = <see RFC 4234>       ; Internet standard newline
HTAB             =  %x09
SP               =  %x20
CHAR             = <see RFC 4234>       ; any ASCII excluding NUL
CTL              = <see RFC 4234>       ; %x00-1F / %x7F