Bert, Steve, Eric, All,
Sorry for the late response. I just came back from an overseas meeting and
the other co-authors were on vacation.
Please see my comments/questions below.
Cheers,
Louis-Nicolas
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Monday, August 05, 2002 7:11 AM
> To: Rap-wg (E-mail)
> Subject: RE: draft-ietf-rap-rsvp-authsession documents
>
>
> OK, w.r.t. documents:
>
> draft-ietf-rap-rsvp-authsession-03.txt
> draft-ietf-rap-session-auth-04.txt
>
> it seems that the list of security related issues
> that I posted over a week ago now are the most serious
> items to address. Here are 2 more issues to take into
> account when you re-edit the docs:
>
> - When you talk about:
>
> 5 UNICODE_DN X.500 Distinguished name as defined
> in RFC-2253 as a UNICODE string.
>
> we assume you mean a UTF-8 string?
> Might be good to make that clear.
YES - That's what RFC-2253 specifies...I can clarify this in the draft.
>
> - The replay protection that was added to rsvp-auth depends
> on some clock synchronization (when there isn't a policy
> server). It would be good to specify that this requires
> that the system be using NTP or GPS.
No problem. We specified NTP...I will make this clear also.
>
>
> Thanks,
> Bert
>
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> > Sent: vrijdag 26 juli 2002 22:59
> > To: Rap-wg (E-mail)
> > Cc: Steve Bellovin (E-mail); Eric Rescorla (E-mail)
> > Subject: FW: draft-ietf-rap-rsvp-authsession documents
> >
> >
> > Authors/WG,
> >
> > The documents
> > draft-ietf-rap-rsvp-authsession-03.txt
> > draft-ietf-rap-session-auth-04.txt
> > were on the IESG agenda yesterday.
> >
> > I still have to collect some more feedback, so the below is
> > incomplete.
> >
> > But the security issues are the most serious concern, so here it is
> > for your response and corrections. I have added Steve Bellovin and
> > Eric Rescorla on the cc: list, so that when you respond, they can
> > also see the responses and react immediately/directly.
> Steve and Eric
> > (as you can see below) have worked on the comments together.
> >
> > Here we go:
> >
> > --- comment from Steve
> >
> > The new version is a lot better, and goes a long way towards
> > resolving
> > my objections. But I don't think it specifies the authentication
> > process clearly enough for people to implement from the spec.
> > I suspect
> > we can resolve this by email in the next couple of days.
I agree. Once we agree on the changes, I will provide an updated version. Hopefully,
we can resolve all issues this week.
> >
> > For shared secret and Kerberos, I *think* that the intent is
> > the key is
> > used only for an HMAC or similar algorithm such as a CBC-MAC. That
> > should be stated explicitly. It should also state that the
> expected
> > length of the authentication data is a preconfigured parameter, and
> > MUST match the data length in the message. (There's an
> attack if the
> > data length is taken from the message; details are left as an
> > exercise
> > for the reader.)
> >
> > Be more explicit about what HMAC-MD5-96 means -- I don't
> believe that
> > that string is defined in 2104. Why truncate to 96 bits?
I simply followed what was specified in the COPS RFC (rfc 2748 SECTION 2.2.16) to encourage
re-use of what has been specified already. But, as you suggest in the text below,
I am fine with 16 bytes.
> > It's secure
> > -- but it's done in IPsec because of boundary alignment
> > considerations.
> >
> > Anyway -- the text should say something like this:
> >
> >
> > If AUTH_ENT_ID is of types AUTH_ENT_ID IPV4_ADDR, IPV6_ADDR,
> > FQDN, ASCII_DN, UNICODE_DN or URI, the receiver should use
> > the identity to consult a table keyed by that identity. The
> > table should identify the cryptographic authentication algorithm
> > to be used and the expected length of the authentication data.
> > At a minimum, all implementations must support HMAC [RFC2104]
> > using the MD5 [RFC1321] hash algorithm with an output length of
> > 16 bytes. New algorithms may be added by the IETF standards
> > process.
> >
> > If AUTH_ENT_ID is of type KRB_PRINCIPAL, a similar algorithm
> > table is consulted. In this case, however, the key is taken
> > from the Kerberos ticket. At a minimum, all implementations
> > must support the same HMAC hash described above.
> >
> > Authentication is done as follows. The entire message is
> > constructed, excluding the length, type, and subtype fields
> > of the AUTH DATA field. Note that the message MUST include
> > either a START_TIME or a SESSION_ID (See Section 9), to prevent
> > replay attacks. The output of the authentication algorithm,
> > plus appropriate header information, is appended to the message.
> >
> > Verification is done by a similar process; however, the receiver
> > MUST verify that the indicated length of the authentication data
> > is consistent with the configured table entry.
> >
This text does clarify. I will input it your suggested text into the appropriate sections of the next revision.
> >
> > Much more needs to be said about generating signatures to
> be verified
> > via an X.509 certificate. I'm not 100% certain which RFCs
> need to be
> > cited -- ekr or jis, can you fill in some details? -- but
> > they probably
> > include PKCS 1 and 7 (published as RFCs -- btw, there is an
> obsolete
> > RFC cited for PKIX). I frankly don't recall if the preferred hash
> > algorithm is in the X.509 certificate, though the public key
> > algorithm
> > used is implicit in the key type in the cert. Similar
> > concerns apply to
> > PGP_CERT, but I don't even know what to cite for it.
PGP_CERT: Maybe Eric can help out here also? If not, I will dig deeper into
this and provide the references and needed text.
> >
> > --- here comes a response to the above from Eric
> >
> > I agree that this is unsatisfactory, on several fronts:
> > (1) It only appears to be possible to pass a single certificate.
> > What about certificate chains?
We should support certificate chains. We define it as follows:
8 X509_V3_CERT A chain of authorizing entity's X.509 V3
digital certificates.
I can simply state this also in section 4.3 and reference
the appropriate RFCs (see comment below).
> > (2) It doesn't actually SAY that a signature is what is present
> > in the authentication data field, though I suppose we're supposed
> > to intuit that.
I though this was sort of straightforward. I can add a sentence specifying that
a signature is present.
> > (3) It doesn't specify the digest algorithm.
> >
> > In answer to your questions:
> > (1) It's necessary to reference PKCS-1 [RFC 2437] since
> that describes
> > how to perform RSA signatures. (I'm assuming that they want to use
> > PKCS-1 rather than PSS or some other newfangled RSA padding
> > If DSS is to permitted they should also reference FIPS 186-2.
Will add a reference to RFC 2437.
> >
> > (2) It's not necessary to reference PKCS-7 unless you're using
> > it as a certificate chain container. (See my comment about
> > chains above).
Yes, should be supported. Will add a reference to PKCS-7.
> >
> > (3) In general, X.509v3 certificates do not carry preferred digest
> > indicators. Either the digest name should be manually configured
> > or contained in the message. While it's technically possible
> > to discover what digest was used from the signature (it's in the
> > DigestInfo), generally APIs and hardware assume that you already
> > know.
We would prefer to have this contained in the message. How should I specify this?
Should I simply state that the preferred digest name is contained in the certificate?
What do other applications using X.509v3 certificates specify?
> >
> >
> > Further more:
> >
> > (1) Section 4.1 talks about "shared private keys". This is confusing
> > since "private key" is generally used to refer to the
> private half of
> > an asymmetric key pair. I think this would be clearer if it talked
> > about "shared symmetric keys".
Agreed. Will make the change.
> >
> > (2) The Kerberos authentication mechanism doesn't appear to contain
> > authentication data but instead merely the principal name. The text
> > here suggests that the authentication is interactive:
> >
> > An authorizing entity is configured to construct the
> > AUTH_SESSION
> > policy element that designates use of the Kerberos
> authentication
> > method (KRB_PRINCIPAL). Upon reception of the RSVP request, the
> > router/PDP contacts the local KDC to request a ticket for the
> > authorizing entity (principal@realm). The router/PDP uses
> > the ticket
> > to access the authorizing entity and obtain authentication
> > data for
> > the message.
> >
> > That seems unusual. Wouldn't you want the authorizing
> entity to send a
> > ticket, thus avoiding a round trip? Is the problem that the
> > authorizing entity can't guess the principal name of the router/PDP?
> > If so, how does he know it's right when the router/PDP asks for
> > authorization? What are the contents of the "authentication
> data" that
> > the router/PDP obtains? This all seems quite hairy and
> underspecified.
This is explained in section 9:
"If shared private keys are not a valid option, the Kerberos
authentication mechanism is reasonably well secured and efficient in
terms of AUTH_SESSION size. The AUTH_SESSION only needs to contain
the principal@realm name of the authorizing entity. This is much
more efficient than the PKI authentication option. "
Does that answer your questions? Basically, since only the principal@realm name is needed
the AUTH_SESSION is smaller in size (as compared to if it contained the kerberos ticket).
> >
> >
>
>