Subject: Re: [Ietf-krb-wg] Working Group Last Call: draft-ietf-krb-wg-clear-text-cred-00

From: Sam Hartman <[email-masked]>
Date: Wed, 13 Jul 2011 09:36:47 -0400

Hi, folks, we received two positive comments and no concerns or issues
with draft-ietf-krb-wg-clear-text-cred-00.  As such, I'll be sending it
forward to the IESG for consideration as a proposed standard.
It's been a while; I need to go remember how to do that:-)

One significant factor in being willing to send this document forward
with so little discussion was the extensive discussion last year when
this was proposed
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 18 Jul 2011 19:04:52 +0100

Hi All,

I've had a read of this and have the following minor issues.

1. This uses etype=0 which is reserved and may not be assigned
according to the iana registry for etypes. Should a different
number be assigned, or do we need to let IANA know about this
somehow. I think something is needed there unless I've misread
something, which is quite possible.

2. Could you give a reference to the relevant section of the
OASIS document that defines how an unencrypted KRB-CRED is to
be encapsulated? Its not clear to me that an implementer will
know exactly where to put the KRB-CRED but I think a sentence
or two more should fix that.

3. Is RFC1964 really a normative reference? Doesn't look like
it to me. (But I don't care much:-)

Cheers,
S.

---

From: Nico Williams <[email-masked]>
Date: Mon, 18 Jul 2011 13:11:59 -0500

> something, which is quite possible.

This was, originally (i.e., in RFC1510, section 6.3.1) the etype
number for the NULL enctype.  We removed this in RFC4120.  We're now
basically restoring the NULL enctype just for this one use.  I suppose
this might mean we need IANA considerations?

> it to me. (But I don't care much:-)

Sure, I don't think it has to be a normative reference.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Russell J Yount <[email-masked]>
Date: Mon, 18 Jul 2011 18:23:30 +0000

Hi,

>or two more should fix that.

In 
	http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-attribute-kerberos-csprd02.pdf 

section 2.8 Examples

<saml:Attribute xmlns:kerberos="urn:oasis:names:tc:SAML:2.0:attribute:kerberos"    NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oasis:names:tc:SAML:2.0:profiles:attribute:kerberos:krb-cred"<saml:AttributeValue><kerberos:KerberosData><kerberos:KerberosCname>[email-masked]</kerberos:KerberosCname><kerberos:KerberosSname>http/[email-masked]</kerberos:KerberosSname><kerberos:KerberosMessage KerberosMsgType="KRB_CRED">...base64 representation of a KRB-CRED message...</kerberos:Message></kerberos:KerberosData></saml:AttributeValue></saml:Attribute>

-Russ

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Monday, July 18, 2011 2:05 PM
To: Sam Hartman
Cc: [email-masked]
Subject: Re: [Ietf-krb-wg] Working Group Last Call: draft-ietf-krb-wg-clear-text-cred-00

Hi All,

Cheers,
S.

---

From: Greg Hudson <[email-masked]>
Date: Mon, 18 Jul 2011 14:37:40 -0400

> something, which is quite possible.

I don't think any IANA action is necessary.  The document does not
define an enctype and is not assigning the enctype number 0.  And since
no enctype can be created with enctype number 0, there will never be a
conflict between this use of the number and a real enctype.  There could
be a conflict between this use of the number and another new use of it,
but that conflict would already be a practical issue since 0 is already
used this way in implementations.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 18 Jul 2011 19:54:54 +0100

> used this way in implementations.

Right, so isn't that a reason for this rfc-to-be to be referenced from the iana registry so any other putative user of etype=0 knows not to do that?

S

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Jul 2011 14:59:11 -0400

>>>>> "Russell" == Russell J Yount <[email-masked]> writes:

    Russell> Hi,
    Russell> On Mon, Jul 18, 2011 at 1:04 PM, Stephen Farrell <[email-masked]> wrote:

    >> OASIS document that defines how an unencrypted KRB-CRED is to be
    >> encapsulated? Its not clear to me that an implementer will know
    >> exactly where to put the KRB-CRED but I think a sentence or two
    >> more should fix that.

    Russell> In
    Russell> http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-attribute-kerberos-csprd02.pdf

    Russell> section 2.8 Examples

    Russell> <saml:Attribute
    Russell> xmlns:kerberos="urn:oasis:names:tc:SAML:2.0:attribute:kerberos"
    Russell> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
    Russell> Name="urn:oasis:names:tc:SAML:2.0:profiles:attribute:kerberos:krb-cred"<saml:AttributeValue><kerberos:KerberosData><kerberos:KerberosCname>[email-masked]</kerberos:KerberosCname><kerberos:KerberosSname>http/[email-masked]</kerberos:KerberosSname><kerberos:KerberosMessage
    Russell> KerberosMsgType="KRB_CRED">...base64 representation of a
    Russell> KRB-CRED
    Russell> message...</kerberos:Message></kerberos:KerberosData></saml:AttributeValue></saml:Attribute>

OK.
How about the following 3 changes to address AD review comments:

1) Add the following sentence somewhere appropriate:

The value 0 is a reserved encryption type and will never be assigned
[RFC3961]. Therefore using 0 in the enctype field as a flag that the
message is unencrypted will not conflict with any future assignment.

2) Cite section 2.8 of that OASIS draft as an informative reference. I
understand we may not know what the final approved document will be
called as it is blocked on this one. An informative citation  will be
sufficient.

3) Move RFC 1964 to be an informative reference.

Does that work for everyone?

Russell, if you do not hear objections by the time the draft queue
reopens next Monday, please make a new submission including these
changes and any editorial cleanups.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 18 Jul 2011 20:00:53 +0100

>    http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-attribute-kerberos-csprd02.pdf 

Perfect. Adding that reference should make sure developers know what to do,
Ta,
S

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Jul 2011 15:13:00 -0400

Speaking as an individual not as a chair.

>>>>> "Stephen" == Stephen Farrell <[email-masked]> writes:

If we want to update the IANA registry, I think we should update it to
say that 0 is never a valid enctype.  In effect what we're saying here
is that the semantics of the krb-cred message are that if 0 is in the
enctype field it's not actually an enctype: it's a message specific
indicator that the content is not encrypted.

It's ugly to do that it that way: it would have been cleaner to omit the
EncryptedData sequence and to use an ASN.1 choice.  However back when
this was implemented that was a lot harder to do with the code so we
chose a different approach.

This is exactly the same sort of thing as IDNA 2008 making ideographic
full stop  an invalid codepoint so the question of what to map it to
could be left to a higher layer.
We're saying that 0 is not an enctype, so layers above the enctype layer
are free to use it as a sentinel value.

To me, reserved, never assign has that effect. However I could see that
we could clearly document the implications of that.

I'd argue that if we do that it should specifically be in a section
titled something like "Enctype 0 is not an encryption system"
That said something semantically similar to what I say above.

I'd specifically object to defining enctype 0 as "as an null crypto
system. Crypto systems are required to provide certain properties, which
you really can't get with null. Also, they're required to define certain
operations. So actually assigning 0 to null doesn't make sense.  But we
certainly could clarify the implications of what it means for something
to be reserved and not be assigned.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 18 Jul 2011 21:08:27 +0100

Hi Sam,

> Speaking as an individual not as a chair.

I'm not personally very exercised about this, so I don't want
to cause hassle, but I think its worth getting two things done.

First, other IESG members may jump on this if we don't get it
tidy, and second, there's a (maybe small) chance that some future
spec could give some other meaning to enctype 0, so avoiding
those will be good.

My suggestion is that getting some kind of reference to
this document in the IANA registry is a way to handle those.

But I'll go with any approach that the WG thinks will achieve
the above, and if it turns out we're wrong then we'll deal
with it when we need to - which won't be hard in any case, but
may be more tedious;-)

Cheers,
S.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Jul 2011 16:12:30 -0400

>>>>> "Stephen" == Stephen Farrell <[email-masked]> writes:

    Stephen> My suggestion is that getting some kind of reference to
    Stephen> this document in the IANA registry is a way to handle
    Stephen> those.

How do you feel about my approach of having a section in this document
that says that enctype zero is not an enctype and thus implementations
are free to assume that it is an invalid value and to assign
usage-specific meaning at an upper layer?  I think that should be
sufficient for both of your concerns if we have IANA refer to that.  I'm not very exercised about this
either and agree that IESG response and future specs are both valid
concerns.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 18 Jul 2011 22:14:18 +0100

On 18/07/11 21:12, Sam Hartman wrote:
> sufficient for both of your concerns if we have IANA refer to that.  

Sure, give it a try. I think so long as this RFC number ends up in the
IANA registry that'll do what's needed.

Cheers,
S.

> I'm not very exercised about this

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Jul 2011 17:47:18 -0400

Russel, can you put something together for this or do you need more
guidance?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Russell J Yount <[email-masked]>
Date: Wed, 20 Jul 2011 12:16:09 +0000

I think I can handle it.
-Russ