headers
Thomas Hardjono | 1 Dec 2010 01:20
Picon
Favicon

Teleconference call to talk about PAC work

Folks,

Would people who are interested in the PAC discussion be
interested/open to having a teleconference call about the PAC work?

If so, I can setup a DoodleIt schedule and bridge for people to select
dates/times.

cheers,

/thomas/


-----Original Message-----
From: ietf-krb-wg-bounces <at> lists.anl.gov
[mailto:ietf-krb-wg-bounces <at> lists.anl.gov] On Behalf Of Thomas
Hardjono
Sent: Tuesday, November 30, 2010 4:09 PM
To: krb-wg mailing list (ietf-krb-wg <at> lists.anl.gov)
Subject: [Ietf-krb-wg] Teleconference call to talk about PAC work

Folks,

Would people who are interested in the PAC discussion be
interested/open to having a teleconference call about the PAC work?

If so, I can setup a DoodleIt schedule and bridge for people to select
dates/times.

cheers,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jehan Pagès | 1 Dec 2010 16:25
Picon
Gravatar

Re: RFC5802: SCRAM

Hi,

I have made 2 other errata on SCRAM, but I guess they should be
showing up on this list, which apparently they don't. They are sent to
sasl ml, which is supposed to be closed and redirected to kitten ml.
But I didn't receive anything on kitten for the 2 last errata (nor do
I see them in the archives). Instead I could see them in the sasl
archives!

Isn't there a redirection issue?
Bye.

Jehan

2010/11/23 Nicolas Williams <Nicolas.Williams <at> oracle.com>:
> On Mon, Nov 22, 2010 at 07:50:48PM +0900, Jehan Pagčs wrote:
>> 2010/11/22 Alexey Melnikov <alexey.melnikov <at> isode.com>:
>> > Jehan Pagčs wrote:
>> >> I think I spotted a small wording mistake in the SCRAM RFC
>> >> (too bad the draft period is already finished, sorry I didn't
>> >> participate). In section 5:
>> [...]
>> > Good catch. Can your report this as an erratum using
>> > <http://www.rfc-editor.org/errata.php> (press the "Report New Errata"
>> > button)?
>>
>> Ok. I have done it. I have made it an "editorial" errata, not
>> technical, because even though it changes (even reverse) the meaning
>> of the text, the current one was not intended.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Saint-Andre | 1 Dec 2010 16:31
Favicon

Re: RFC5802: SCRAM

I've asked the Secretariat to look into this...

On 12/1/10 8:25 AM, Jehan Pagčs wrote:
> Hi,
> 
> I have made 2 other errata on SCRAM, but I guess they should be
> showing up on this list, which apparently they don't. They are sent to
> sasl ml, which is supposed to be closed and redirected to kitten ml.
> But I didn't receive anything on kitten for the 2 last errata (nor do
> I see them in the archives). Instead I could see them in the sasl
> archives!
> 
> Isn't there a redirection issue?
> Bye.
> 
> Jehan
> 
> 2010/11/23 Nicolas Williams <Nicolas.Williams <at> oracle.com>:
>> On Mon, Nov 22, 2010 at 07:50:48PM +0900, Jehan Pagčs wrote:
>>> 2010/11/22 Alexey Melnikov <alexey.melnikov <at> isode.com>:
>>>> Jehan Pagčs wrote:
>>>>> I think I spotted a small wording mistake in the SCRAM RFC
>>>>> (too bad the draft period is already finished, sorry I didn't
>>>>> participate). In section 5:
>>> [...]
>>>> Good catch. Can your report this as an erratum using
>>>> <http://www.rfc-editor.org/errata.php> (press the "Report New Errata"
>>>> button)?
>>>
>>> Ok. I have done it. I have made it an "editorial" errata, not
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sean Turner | 1 Dec 2010 16:34

Fwd: [Technical Errata Reported] RFC5802 (2652)

-------- Original Message --------
Subject: [Technical Errata Reported] RFC5802 (2652)
Date: Tue, 30 Nov 2010 10:58:12 -0800 (PST)
From: RFC Errata System <rfc-editor <at> rfc-editor.org>
To: chris.newman <at> oracle.com, ams <at> toroid.org, Alexey.Melnikov <at> isode.com, 
Nicolas.Williams <at> oracle.com, turners <at> ieca.com, tim.polk <at> nist.gov, 
tlyu <at> mit.edu, kurt.zeilenga <at> isode.com
CC: jehan <at> zemarmot.net, sasl <at> ietf.org, rfc-editor <at> rfc-editor.org

The following errata report has been submitted for RFC5802,
"Salted Challenge Response Authentication Mechanism (SCRAM) SASL and 
GSS-API Mechanisms".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5802&eid=2652

--------------------------------------
Type: Technical
Reported by: Jehan Pagès <jehan <at> zemarmot.net>

Section: 7

Original Text
-------------
    base64-char     = ALPHA / DIGIT / "/" / "+"

    base64-4        = 4base64-char

    base64-3        = 3base64-char "="
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sean Turner | 1 Dec 2010 16:35

Re: RFC5802: SCRAM

I just forwarded them to the list.

spt

On 12/1/10 10:31 AM, Peter Saint-Andre wrote:
> I've asked the Secretariat to look into this...
>
> On 12/1/10 8:25 AM, Jehan Pagčs wrote:
>> Hi,
>>
>> I have made 2 other errata on SCRAM, but I guess they should be
>> showing up on this list, which apparently they don't. They are sent to
>> sasl ml, which is supposed to be closed and redirected to kitten ml.
>> But I didn't receive anything on kitten for the 2 last errata (nor do
>> I see them in the archives). Instead I could see them in the sasl
>> archives!
>>
>> Isn't there a redirection issue?
>> Bye.
>>
>> Jehan
>>
>> 2010/11/23 Nicolas Williams<Nicolas.Williams <at> oracle.com>:
>>> On Mon, Nov 22, 2010 at 07:50:48PM +0900, Jehan Pagčs wrote:
>>>> 2010/11/22 Alexey Melnikov<alexey.melnikov <at> isode.com>:
>>>>> Jehan Pagčs wrote:
>>>>>> I think I spotted a small wording mistake in the SCRAM RFC
>>>>>> (too bad the draft period is already finished, sorry I didn't
>>>>>> participate). In section 5:
>>>> [...]
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sean Turner | 1 Dec 2010 16:34

Fwd: [Technical Errata Reported] RFC5802 (2651)

-------- Original Message --------
Subject: [Technical Errata Reported] RFC5802 (2651)
Date: Tue, 30 Nov 2010 10:32:27 -0800 (PST)
From: RFC Errata System <rfc-editor <at> rfc-editor.org>
To: chris.newman <at> oracle.com, ams <at> toroid.org, Alexey.Melnikov <at> isode.com, 
Nicolas.Williams <at> oracle.com, turners <at> ieca.com, tim.polk <at> nist.gov, 
tlyu <at> mit.edu, kurt.zeilenga <at> isode.com
CC: jehan <at> zemarmot.net, sasl <at> ietf.org, rfc-editor <at> rfc-editor.org

The following errata report has been submitted for RFC5802,
"Salted Challenge Response Authentication Mechanism (SCRAM) SASL and 
GSS-API Mechanisms".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5802&eid=2651

--------------------------------------
Type: Technical
Reported by: Jehan Pagès <jehan <at> zemarmot.net>

Section: 7

Original Text
-------------
    nonce           = "r=" c-nonce [s-nonce]
                      ;; Second part provided by server.

    c-nonce         = printable
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nicolas Williams | 1 Dec 2010 16:40
Picon
Favicon

Re: RFC5802: SCRAM

On Wed, Dec 01, 2010 at 08:31:54AM -0700, Peter Saint-Andre wrote:
> I've asked the Secretariat to look into this...

I've seen them.  I just haven't responded yet :)  I hope to get to these
soon.
Permalink | Reply | 0 comments |
headers
Sam Hartman | 1 Dec 2010 19:06
Picon
Favicon

Re: sasl saml and sasl openID

>>>>> "Klaas" == Klaas Wierenga (kwiereng) <kwiereng <at> cisco.com> writes:

    Klaas> Ehm, I was thinking of computing a key with the saml authn
    Klaas> req and the key material from tls as input, would that work?

I'm a bit dubious of using the key from TLS as part of verifying the TLS
endpoints (which is what CB does).
Permalink | Reply | 0 comments |
headers
Jeffrey Hutzelman | 1 Dec 2010 19:48
Picon
Favicon

Re: sasl saml and sasl openID

--On Wednesday, December 01, 2010 01:06:59 PM -0500 Sam Hartman 
<hartmans-ietf <at> mit.edu> wrote:

>>>>>> "Klaas" == Klaas Wierenga (kwiereng) <kwiereng <at> cisco.com> writes:
>
>     Klaas> Ehm, I was thinking of computing a key with the saml authn
>     Klaas> req and the key material from tls as input, would that work?
>
>
> I'm a bit dubious of using the key from TLS as part of verifying the TLS
> endpoints (which is what CB does).

Me too.  If I recall correctly, when we were working on defining CB for 
TLS, one of the conclusions we came to was that the TLS master secret does 
_not_ constitute a unique channel binding, which is why we use the entire 
finished message instead.  Further, using TLS's keying material in any way 
other than as defined in TLS runs the risk of inadvertently sharing keying 
material between what should be separate cryptographic contexts.

Finally, it's really not appropriate for a GSS/SASL mechanism to assume 
there is an underlying TLS channel.  Channel bindings are somewhat abstract 
by design; a mechanism should work with _any_ channel binding.

-- Jeff
Permalink | Reply | 0 comments |
headers
Jeffrey Hutzelman | 1 Dec 2010 19:52
Picon
Favicon

Re: sasl saml and sasl openID

--On Monday, November 15, 2010 01:27:13 PM +0100 Simon Josefsson 
<simon <at> josefsson.org> wrote:

> Here is how it could work, in more detail:
>
> 1) The server adds the CB data in a SAML tag in the SAML AuthN request.
>
> 2) The client verify that the CB data is the same as it has locally.
>
>    (Note, here a MITM could have replaced the CB data with something
>    else, but that will detected later.)
>
> 3) The client sends the AuthN request off to the IdP, which copies the
>    CB data into the SAML AuthN Statement.
>
> 4) The server verify that the CB data is the same as it sent.
>
>    (This step will detect of there were a MITM.)

This doesn't actually bind the channel in the eyes of the client, because 
the client has no way to tell whether the verification in step 4 succeeded. 
I think I like Scott's approach better, where both the client and SP 
provide signed copies of the CB data to the IdP, and the IdP compares them. 
This does require a secure channel between the client and IdP, but securing 
that channel is not really up to the GSS/SASL mechanism.

-- Jeff
Permalink | Reply | 0 comments |

Gmane